- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 12 Nov 2009 15:15:34 -0800
- To: www-style@w3.org
text-overflow: ellipsis
-----------------------
RESOLVED: Only horizontal overflow triggers for text-overflow:
ellipsis. Add a new keyword for handling ellipsis due
to vertical overflow where the ellipsis appears on the
last line
Discussed other issues with 'text-overflow', including:
- interaction with 'overflow', whether it prevents overflow, whether
it requires 'overflow: hidden', what happens with 'overflow: scroll',
how that makes sense with floats, etc.
- where and how the ellipsis is drawn, how it interacts with
surrounding text
- what happens with overflowing blocks in the vertical ellipsis case
- whether the ellipsis is an indication of content you can't see or
content you can't reach
- what happens when you scroll, does the ellipsis get drawn on the
other side, too? both sides?
- interaction with bidi, whether the ellipsis causes logical clipping
in place of visual clipping
- whether the behavior you want for ellipsizing text you can scroll to
is different from the behavior for ellipsizing text you can't get to,
and other potential reasons for different behaviors
No conclusions on these, other than Mozilla would prefer having a spec
for all of this rather than adding a 4th incompatible interpretation.
====== Full minutes below ======
http://www.w3.org/2009/11/02-CSS-irc
http://krijnhoetmer.nl/irc-logs/css/20091102#l-281
text-overflow
-------------
Scribe: Sylvain
fantasai: there have been comments re: text overflow in the vertical direction
fantasai: the feature was originally aimed at single lines; what about
multi-line items ?
<fantasai> http://krijnhoetmer.nl/irc-logs/css/20090805#l-303
TabAtkins: there is no useful distinction between line boxes overflowing
vertically vs. blocks overflowing vertically
smfr: a use case involves wrapped song names in the iTunes store that only
need an ellipsis at the end of the last line
(there are only two lines of space for the song titles)
tantek: what we're saying is that this really is an inline overflow
smfr: does this property cause overflow though ?
plinss: it seems orthogonal since its aim is to prevent overflow
tantek: agree
fantasai: do implementors agree on what the sensible behavior should be ?
smfr: We'd like to drop the requirement for overflow: hidden to trigger
text-overflow
peter: Seems like this property prevents overflow
Alex: You can have other content that triggers overflow even in the
presence of text-overflow
Alex: e.g. if you have a float that overflows and triggers scrollbars,
and then also have text truncated by text-overflow
...
Scribe: fantasai
Tantek: could say that 'text-overflow' always forces 'overflow' to
'hidden'
dbaron: Or you could say that it forces 'overflow' values other than
'visible' to 'hidden'
<hyatt> don't you mean forces only visible to hidden?
<dbaron> hyatt, no... but why do you suggest that?
* tantek agrees with dbaron's proposal.
<hyatt> you wouldn't want to turn overflow:scroll into hidden just
because you set text-overflow after overflow
<dbaron> hyatt, I think the issue Alex raised was complications
crossing "whether to have scrollbars" and "whether to
have ellipses"
<dbaron> hyatt, or was that not the reason for the restriction in the
first place?
<dbaron> hyatt, so, in that case, why do we want to change 'overflow'
at all?
<dbaron> hyatt, or is it because otherwise nothing else in the spec
actually hides the text that overflows?
* fantasai is not capturing this discussion between Tab and Alex...
TabAtkins: Anytime I'm using overflow: hidden for anything other than
making the block overflow: hidden, I run into problems
... block formatting context ... etc
Alex: How about floats?
TabAtkins: If I want my floats to get cut, I want to put overflow:
hidden on them. They're not text
Alex: If there is a float in the text beyond the ellipsis cut-off point,
<hyatt> can't text-overflow just be completely independent of overflow
Alex: Where would be the hypothetical position for that float?
(or something with abspos)
<hyatt> like it would truncate even if overflow is visible
Tab: Good question
<hyatt> but doesn't imply overflow:hidden
Tab: I think it would try to position itself at the end of the line
Alex: Or pretend overflow: visible and just refuse to render the text
<hyatt> i don't see why text-overflow has to really care what the
value of overflow is...
<fantasai> hyatt, what happens if you have overflow: scroll and a
float that overflows and text-overflow won the text and
then you scroll down?
...
<hyatt> i can't tell what you mean exactly
Alex: If there is a paragraph that fits perfectly, but there is a
paragraph that does not fit
<hyatt> (sorry i don't want to derail remotely, so just ignore me if
it is convenient) :)
Alex: Do we append an ellipsis to the paragraph that fits because of
the paragraph that didn't fit?
...
plinss: yes, you want to truncate enough of the first paragraph to
fit the ellipsis
Alex: In the process of measuring one block of text, you have to
consider text that comes later
* hyatt is just looking at the really simple case of text overflow
where you have a single line label... it's a bit inconvenient
to have to explicitly say overflow:hidden in that case...
although it's not the end of the world
Peter: You finish the first paragraph, start the next paragraph,
then go back and truncate the earlier paragraph
smfr: It's like the first-letter problem
Tantek: Like the first-line problem
<tantek> ::first-line
Alex: As you are formatting the line ... later you find that we have
to go back and stick an ellipsis up there
...
Steve: The critical thing is to say that there's content you're not
seeing
Tantek: Write up the testcases
<TabAtkins> www.xanthir.com/etc/text-overflow.html
Tab: Pull it up in Safari or IE8
Tab: If you do, you see as expected the ellipsis
Tab: But if you start scrolling, you don't see anymore of the text
<fantasai> hyatt, this is what I was talking about :)
<fantasai> or something like it
<hyatt> of course you also said nowrap
Peter: In this case I would argue you shouldn't have a scrollbar
Peter: It should behave as if there is no content to scroll
<hyatt> yup that's a bug in webkit that it showed a scrollbar
<hyatt> an enabled scrollbar rather
dbaron: dsinger made a comment to me which throws another comment in
here
dbaron: If it's wrapped and you're doing text-overflow ellipsis, you
get the ellipsis on the last line
<hyatt> that is definitely a bug in webkit
dbaron: and it scrolls, and you scroll, you get something different
dbaron: Should these really behave differently?
...
Peter: I implemented a control with this in 93. When you have a
filename and it doesn't fit, it has an ellipsis.
Peter: If I'm editing the field, the ellipsis goes away
Peter: and it scrolls
Tantek: Sounds like :focus selector
Peter: For Tab's case, I can see a case for having ellipsis on both
sides as we scroll until we get to the end, and then the
ellipsis is on the left side.
Peter: In the vertical case, as I'm scrolling down, I'd want an
ellipsis at the beginning
Peter: I can imagine wanting that for e.g. a DVR
Peter: And not all UAs have a scrollbar for scrolling
fantasai: roc's interpretation was that the ellipsis is a render-time
thing: you lay out everything and then just draw the ellipsis
Peter: I get roc's point that you want it laid out and compute the
scroll region as if there's no ellipsis
Peter: but when you render the text on that line you need to actually
put the ellipsis in the text flow
Peter: Otherwise you don't get proper ligatures, etc.
* dbaron imagines a font with a ligature for "hello..."
Peter: It should look as if someone typed an ellipsis on the line
Steve: I'm confused in this particular case because I was thinkin the
ellipsis would show me there's content that wouldn't fit
Steve: but if I put scrollbars there all the content fits
Steve: So there's no need for an ellipsis there
Steve: But I do understand the example that Peter mentioned, that the
ellipsis is a second hint
...
Tab: You're seeing the ellipsis as an indication of content you can't reach
Tab: I see it as an indication of content you can't see
Peter: We all agree that the behavior in Tab's example is not wanted
(showing scrollbars indicating lots of content, but not being
able to scroll to it because it's truncated by the ellipsis)
Alex: What I see here is interoperable behavior that can't be explained
easily and doesn't have much use cases
fantasai: given that there *is* interoperable behavior, are implementors
OK with changing it ?
<fantasai> to make more sense :)
Tab: I honestly can't see anyone depending on it working this way and
not be happy with it changinge
...
Alex: There are two questions here. Are we going to change quirks
behavior? No.
Alex: Other question is what do we want to happen here, and this
scenario is really questionable to begin with.
Alex: We've created something and we're trying to figure out what we
would want to happen
Alex: We have wrapped text, and it may not fit in horiontal direction
and it may not fit in vertical direction
Alex: ....
Alex: I like that it does not affect layout
Alex: And just at render time we insert the ellipsis
Alex: I don't think there are cases where we have ellipsis in the middle
Peter: There's a use case for ellipsis in the middle
Peter: URLs
dbaron: We have a middle option for ellipsis in xul, too.
dbaron: Also in bidi you might have cases for ellpisis in the middle
dbaron: I think having a spec for bidi cases was one of the issues
we're waiting on for implementing this
smfr: What happens with selection? What happens when the user selects
the ellipsis?
dbaron: We don't define selection right now. We probably should at
some point
Steve: I have one concern with what you said Alex, which was focusing
on text
<tantek> fantasai, feel free to capture the selection question(s) as
outstanding questions/issues for CSS3-UI
Steve: What if I'm using images to create lines of symbols, what happens?
* fantasai tantek, put it in Tracker
* fantasai is trying to keep up with minutes
Alex: You wouldn't get an ellipsis with floats, because then you don't
have lines
Steve: no, I have lines
<TabAtkins> At the moment, both webkit and ie allow you to highlight
the ellipsis, but then put only the visible text on the
clipboard. Ellipsis doesn't carry with the content.
<tantek> fantasai, I'm not familiar with Tracker, so I'll action you ;)
... something about a pseudo-element
<fantasai> http://w3.org/Style/CSS/Tracker/ go for it
<fantasai> it's really straightforward
<fantasai> make product
<fantasai> add an issue
<tantek> ACTION fantasai: capture the (text) selection question(s)
related to text-overflow as outstanding questions/issues
for CSS3-UI
<post-edit: action transferred to Tantek>
Alex: I would like resolution to keep ellipsis a render-time thing.
I'm open to extending it
Alex: Let's figure out what we need to do to have vertical overflow
create ellipsis. that seems sensible and doable
Alex: We're not talking about existing ellipsis bheavior proeprty to
change behavior to include overflow, right?
fantasai: that is what we're talking about
Alex: We've had this behavior for 10 years
Alex: We usually don't change behavior like that
Alex: I think we should come up with a new value
Alex: .. it's probably not helping that I can't come up with a better term :)
Tab: ellipsis-block
Steve: too long, but content-overflow-indication :)
...
Alex doesn't see the point in changing the behavior in Tab's example.
Alex: Maybe if you show me a use case for a different behavior
Brad: I would expect that as you scroll to the right, the ellipsis
moves to the right revealing more and more words
Tab: Putting an ellipsis in mind is not about "don't render anything
past this point ever"
Tab: I don't want it to be visible all the time, but I still want to
be able to scroll to it
Peter gives examples from his DVR and channel guide
Peter: This is a common UI in places other than web content, and it's
something that people want to do with CSS
Peter: More and more people are using XML+CSS
Peter: for UI
Peter: We're using it in our printer UIs. There's no scrollbars,
it's flick mechanism
Peter: You can envision your channel guide, but imagine a table
Peter: For the table cells that are incomplete, they show ellipsis
Peter: and as you scroll to the right, the ellipsis shift and the
content is revealed
Peter: I want an ellipsis on the right if there's content to the right,
or an ellipsis to the left if there's content on the left
<glazou> You want to apply width to ::ellipsis and a filter
dbaron: Are there cases where the behavior you want for ellipsizing
text you can get to is dfferent from the behavior for
ellipsizing text you can't get to?
Peter: I don't think so.
dbaron: Maybe crop in the middle case for URLs
dbaron: The other case is the bidi cases, which might be different
Peter: My position is that the ... ellipsizing is ortogonal
* fantasai is getting confused
dsinger: I don't agree with you on the bidi case
* tantek has lost ability to visualize the abstract overflow cases
without diagrams.
Peter: .. I want to be able to specify an ellipsis that says "put
an ellipsis wherever text is cut off"
Peter: and another one that just cuts off the text
dbaron: Currently it's the doesn't fit case, not the cut off case
dbaron: My position is that I'd like to see a spec based on what
everyone else does
dbaron: otherwise we'll be adding a 4th implementation not based
on a spec
dbaron: because people want this
Steve: that goes back to fantasai's original question: are we forced
to live with the current situation, or can we change things?
Peter: hyatt thinks the existing behavior in webkit is a bug
...
* fantasai is losing attention span
Brad: Doesn't seem like it would need a separate property. The way
it is now doesn't make any sense
Steve: The question isn't about does it make sense. The question is,
is it so cast in stone right now that we can't change it
Tab: I greatly prefer presentation: it just shows you stuff you can't
see
<dsinger> OK, if ellipses are visual, and the text is bi-di, then
FIRST layout the entire text, then SECOND scroll to that
visual position, and then THIRD if there is more text in
the text-advance direction, replace the last character(s)
in the text-advance direction with an ellipsis (and note
that this/these character(s) might be visually in the
middle of the visible area)
RESOLUTION: Only horizontal overflow triggers for text-overflow:
ellipsis. Add a new keyword for handling ellipsis due
to vertical overflow where the ellipsis appears on the
last line
<bradk> text-overflow-x (current text-overflow behavior) and
text-overflow-y (vertical ellipsis)?
discussion of whether ellipsis is visual or logical in the order of text
<dbaron> http://dbaron.org/css/test/2009/text-overflow-bidi
fantasai: I think it should just behave as clipping. That is the
easiest to understand. Maybe in bidi cases you get the end
of the sentence and the beginning of the sentence and the
middle off-screen
fantasai: But at least you can understand what is happening
(we are looking at actual behavior for bidi cases)
(it seems very weird)
Steve: If it's a rendering behavior, and affects no layout, then what
Daniel is saying makes sense
Daniel: It's extremely simple, and understandable
<dsinger> choice B: layout as a long visual element. scroll to where
you want to go. show an ellipsis at the visual left and/or
right edges, if there is more to be seen in that direction
dbaron: How does this deal with chopping a character or ligature in half?
Peter: I want to clarify the point about two ellipses
ACTION daniel: check for examples in Hebrew books
<br type=lunch>
Received on Thursday, 12 November 2009 23:16:19 UTC