[css3-ui] overflow-text and scrolling (related to issue 24)

Issue 24 of css-ui basically says we should add something like this:

http://www.xanthir.com/etc/text-overflow.html

as an example to illustrate this section http://dev.w3.org/csswg/css-ui/#ellipsis-scrolling

Before I go ahead and prepare that example, I’d like to point out that we have 2 interop issues here, possibly fuelled in part by some apparent contradiction in the spec.

Note that this section is the result of fairly extensive debates (follow the link in the issue recursively for minutes, replies to minutes, and irc discussions).

=== #1 ===
Spec says:

"When an element is scrolled more of the element’s content is shown. The value of text-overflow should not affect whether more of the element’s content is shown or not. If a non-clip text-overflow is set, then as more content is scrolled into view, implementations should show whatever additional content fits, only truncating content which would otherwise be clipped (or is necessary to make room for the ellipsis/string), until the element is scrolled far enough to display the edge of the content at which point that content should be displayed rather than an ellipsis/string.”

Only gecko and presto behave this way (tested Opera 12, latest firefox, latest chrome, latest safari, IE11).

=== #2 ===
Spec says:

"As some content is scrolled into view, it is likely that other content may scroll out of view on the other side. If that content’s block container element is the same that’s doing the scrolling, then implementations should render an ellipsis/string in place of the clipped content, with the same details as described in the value definition above, except that the ellipsis/string is drawn in the start (rather than end) of the block’s direction (per the direction property).”

No browser currently behaves this way for the value ‘ellipsis’ (tested Opera 12, latest firefox, latest chrome, latest safari, IE11) or the single <string> value (only supported in gecko).

In gecko (which is the only engine to support the 2 value syntax), this behaviour is applied when 2 values are provided. I suspect the reason for gecko to fail to do it on the single value case, is due to this text, higher up:
"If there is one value, it applies only to the end line edge. If there are two values, the first value applies to the line-left edge, and the second value applies to the line-right edge.”

I believe that it is meant to be interpreted in light of "implementations should render an ellipsis/string in place of the clipped content, with the same details as described in the value definition above, except that the ellipsis/string is drawn in the start (rather than end)”, and apply to both ends, but it is a bit hard to tell.

=========

The specified behaviour, as I understand it, reflects the result of the long discussions mentioned earlier, and sounds perfectly reasonable to me, so I would like to keep it as is, and only rephrase the sentence about the single value case to avoid ambiguities.

At the same time, specifying something only makes sense to the extend that implementations do it or are willing to align. 
Therefore, I’d like browser vendors to comment on there intentions here.

 - Florian

Received on Tuesday, 18 November 2014 14:16:01 UTC