Page MenuHomePhabricator

Content without spaces in <pre> should wrap and break words
Closed, ResolvedPublic

Description

Author: poovenm

Description:
When setting the 'enclose' to 'div', wrapping is applied. In some cases, the wrapping causes the text to render smaller (adding the line numbering resolves this). Regardless, if the text that needs to be wrapped does not contain a space, wrapping does not take place. Instead, the horizontal scrolls appear and the text is rendered outside the syntax highlighting box.

It appears that there aren't any symbols to naturally breakdown the text so that it may be wrapped. In my case, if ASCII symbols like the ampersand were used for wrapping, the issue would be resolved. However, for cases when the text only contains alphabets, perhaps it would still be good to wrap regardless.

Details

Reference
bz73282

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:49 AM
bzimport added a project: SyntaxHighlight.
bzimport set Reference to bz73282.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle renamed this task from Word wrapping without spaces to Content without spaces in <pre> should wrap and break words.Jun 25 2015, 10:27 PM
Krinkle updated the task description. (Show Details)
Krinkle set Security to None.
Krinkle edited subscribers, added: matmarex, Legoktm; removed: wikibugs-l-list.
Krinkle added a subscriber: Krinkle.

This is still an issue.

See for example:
https://www.mediawiki.org/w/index.php?title=Project:Sandbox&oldid=1693007

Perhaps we should add word-break: break-all in MediaWiki core?
https://developer.mozilla.org/en-US/docs/Web/CSS/word-break

Krinkle moved this task from Backlog to Accepted on the SyntaxHighlight board.

I strongly oppose to make any line breaking as default.

In general, existing usage (e.g. infobox template examples) is relying on the line structure. They use indentation and put equal signs below each others.

I get mad if someone is wrapping the end of the previous line between the indentation structure, even more a superfluously appended comment I don’t want to read now.

The word break feature will insert hyphens within computer code, therefore users look for a page mw:Extension:Syntax-Highlight even if c&p might gracefully ignore the hyphen.

If in extraordinary cases someone needs line automatic line breaking or even word breaks, they might add a style= attribute theirselves; same for overflow:auto isue which is sometimes helpful.

Basically, source code should be provided as-is always, since new lines might have a syntactical meaning and might detoriate the interpretation of the code.

This comment was removed by matmarex.

I think line breaking on spaces, which we just added per T2260, is am improvement over not wrapping or using scrollbars, especially for longform code (and all my text editors are configured to wrap lines); it would be better if we could display some kind of symbol at line wrap points, but what we have will also do.

But breaking very long strings anywhere might not be a good idea. We don't even do that for regular text, why do it for code?

@PerfektesChaos Just one clarification, word-break: break-word doesn't insert hyphens on its own. Therefore you would need to use hyphens property and currently still it's vendor-prefixed versions and would still just get about 34% browser support.
It also doesn't matter what property you are using, if it's [[ https://stackoverflow.com/a/1795878/1696030 | word-wrap or word-break ]] or the newest overflow-wrap.

From my perspective wrapping extra-long lines with force-breaking words would make sense in edge cases when clearly visually notified as it doesn't trigger scrollbars. And forced using of vertical scrollbars slows down reading & understanding code snippets -- for me personally, without having research data backing that.
But with current support of CSS in this field we're not there to give good visual hints. I would therefore put this task on status "Stalled".

TheDJ claimed this task.
TheDJ added a subscriber: TheDJ.

This was fixed by https://gerrit.wikimedia.org/r/561285 as part of T237190