RE: [CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: text-overflow

Some of the discussion on ellipsis in bidi has continued later, and it seemed to be a general consensus that "physical" clipping (removing text as if it was scrolled beyond the ellipsis) is preferred to "logical" (removing text that wouldn't if remeasured in reduced width -- this may remove text from the middle of the line). Most existing implementations do "physical" clipping; IE8 does "logical".

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of fantasai
Sent: Thursday, November 12, 2009 3:16 PM
To: www-style@w3.org
Subject: [CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: text-overflow

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:31:43 UTC