Consider removing text-overflow:<string> construct (in css-overflow-4, but only implemented in Gecko)
Categories
(Core :: Layout: Text and Fonts, task)
Tracking
()
People
(Reporter: karlcow, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
64.04 KB,
image/png
|
Details |
WebKit top, Blink middle, Gecko bottom
The CSS Overflow spec defines two values for text-overflow:
clip(default)ellipsis
https://drafts.csswg.org/css-overflow-3/#text-overflow
Firefox has an additional constructs which is only available in Gecko and not in WebKit or Blink.
text-overflow: <string>.
Test case:
data:text/html,<!doctype html><p style="text-overflow:'HUH?'; width: 20ch;white-space: nowrap;overflow: hidden;">This is an example text showing nothing interesting but the truncated content via text-overflow shorthand property.</p>
|
||
Comment 1•4 years ago
|
||
That would allow us to remove the hack introduced in bug 1769580. I guess we'd need to give it a try. It comes all the way back from bug 312156.
|
|
||
Comment 2•4 years ago
|
||
However text-overflow: string is in the overflow-4 spec. So maybe not? https://drafts.csswg.org/css-overflow-4/#text-overflow
|
||
Updated•4 years ago
|
|
|
||
Comment 3•4 years ago
|
||
Yeah, bug 312156 has notes about no other browser implementing text-overflow:<string>.
I imagine this feature is nice to provide more appropriate behavior for content in languages where an ellipsis isn't the right character? (If there are locales that use something other than an ellipsis to indicate text overflow... which I would imagine there are but I don't actually know.) But if we've been shipping it for over a decade and other browsers (whose text-overflow implementations predated ours) still haven't added support for the <string> syntax, then it probably makes sense to experiment with putting it behind a pref.
|
|
||
Comment 4•4 years ago
•
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)
That would allow us to remove the hack introduced in bug 1769580.
(in a spitballing side-conversation, emilio also pointed out that we could also remove that hack if we simply unsupported text-overflow: "" i.e. unsupport literally-the-empty-string, which seems to be the precise syntax that the cargo-culted & now-unnecessary web-content in question uses, per the testcases there and the link in bug 1769580 comment 22.)
@karlcow: hi! :) -- may I ask what prompted you to file this bug? (Did you run into content that was broken in WebKit and/or Gecko due to using this feature?) Ideally this behavior from css-overflow-4 is something that all browser engines would implement, though I don't know how likely that is at this point. Anyway: I'm curious what brokenness you hit, assuming you hit some brokenness.
|
||
Comment 5•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #3)
Yeah, bug 312156 has notes about no other browser implementing
text-overflow:<string>.I imagine this feature is nice to provide more appropriate behavior for content in languages where an ellipsis isn't the right character? (If there are locales that use something other than an ellipsis to indicate text overflow... which I would imagine there are but I don't actually know.) But if we've been shipping it for over a decade and other browsers (whose text-overflow implementations predated ours) still haven't added support for the <string> syntax, then it probably makes sense to experiment with putting it behind a pref.
Yeah, there are locales/writing systems where a different character or string would be appropriate. I suppose it could be argued that text-overflow: ellipsis could/should be sensitive to the content language and resolve to the proper ellipsis for that language rather than always rendering as U+2026 (which the spec allows: "Implementations may substitute a more language, script, or writing-mode appropriate ellipsis character"), but it's also arguable that browsers cannot be expected to be aware of the appropriate rendering for every possible locale, and in some cases there may be multiple conventions that could reasonably be chosen, so allowing the author to specify their own string gives them the ability to escape any limitations of the browser's implementation.
From a quick glance, it looks like WPT coverage here may be inadequate. I think we should add WPT tests that cover text-overflow: <string> so that it becomes clear where implementations are lacking.
|
Reporter | |
Comment 6•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #4)
@karlcow: hi! :) -- may I ask what prompted you to file this bug? (Did you run into content that was broken in WebKit and/or Gecko due to using this feature?)
Hello Daniel. :)
None. I should have put low priority.
I was looking at implementation differences around text-overflow: ellipsis and friends, and fell upon this one.
Description
•