[CSSWG] Minutes Sydney F2F 2016-02-02 Part III: Behavior of contains:paint and overflow:clip, text-overflow and resize properties; CSS Text; Exclusions and bidi [css-containment] [css-text] [css-exclusions]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Behavior of contains:paint and overflow:clip, text-overflow and
    resize properties
---------------------------------------------------------------------

  - RESOLVED: Remove any mention of overflow:clip from the
              containment spec and change section 3.3 to define that
              clipping happens (just not by affecting value of
              'overflow')

CSS Text
--------

  - RESOLVED: In order to prevent overflow or wrapping of invisible
              white space, spaces at the end of a line must either
              be visually collapsed to fit within the line or must
              hang outside the line (as in hanging punctuation)
  - RESOLVED: Add 'word-break: break-spaces'
  - RESOLVED: Drop pre-wrap-auto
  - RESOLVED: text-wrap: balance evaluation works off of remaining
              space in the line, not average line length.
  - The changes to text-decoration (in this e-mail:
      https://lists.w3.org/Archives/Public/www-style/2016Jan/0195.html)
      need to be explained further before a resolution can be reached.
  RESOLVED: Add word-break: break-word to spec if Edge/Firefox
            find it critical enough to Web compat to implement it.

Exclusions and bidi
-------------------

  - RESOLVED: When a line is split by an exclusion, each side is
              its own line box for the purposes of bidi algorithm
              (i.e. they are effectively separated by a soft line
              wrap). Which line box is first depends on the block's
              directionality.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: fantasai

Behavior of contains:paint and overflow:clip, text-overflow and
    resize properties
=====================================================================

  leviw: Position that I have is that we do not want to conflate the
         notion of having a resize handle and text-ellipsis with
         paint containment,
  leviw: keep that just a performance thing
  leviw: Want to support clip as overflow: clip
  leviw: But not have it as part of paint containment.
  leviw: Florian has different position.
  Florian: If we look at how we came to this, the reason clip was
           introduced and depended on
  Florian: Was that it wouldn't make sense to have resize handler
           and text-overflow: ellipsis containment on the other hand
  Florian: but not be able to have both at the same time,
  Florian: or the full effect over both at the same time.
  Florian: By the full effect of both at the same time, I mean, if
           you wanted both and didn't have 'clip', you'd need to
           have 'overflow: hidden' which may be less performant
           because of possibility of scrolling.
  leviw: We don't allocate the buffer but okay.
  Florian: If you support overflow: clip and you support
           containment, and authors can use both they can do
           everything they want to do.
  Florian: I would prefer one step less, but preference not a
           requirement.
  esprehn: If you trigger too much behavior, you break the
           multi-actor situation.
  esprehn: Two libraries: spreadsheet library that turns ellipsizing
           on/off.
  esprehn: Separately you have an animation library, which adds
           'contains: paint" when it runs animation for performance
           reasons.
  esprehn: All of a sudden your ellipsis triggers.
  esprehn: I like idea that they are separate concepts.

  fantasai: Historical interesting point here,
  fantasai: which is that text-overflow:ellipsis should have always
            triggered, regardless of 'overflow', but for historic
            reasons due to WebKit's implementation, had to make it
            depend on overflow; not an intentional design.
  fantasai: Designing things architecturally around this concept
            seems awkward.

  Florian: For other implementers implementing containment, do you
           either also plan on implementing 'overflow: clip' *or*
           have an implementation of 'overflow: hidden' that has no
           performance cost?
  Florian: If that's the case, I'm okay with the plan.
  dbaron: We have more-or-less overflow: clip. Trivial to adjust it
          to current spec.
  Florian: Do you allocate a buffer for potential scrolling for
           overflow: hidden?
  fantasai: There's a different frame tree if it's scrollable.
  Florian: So there's a performance downside to hidden.
  dbaron: There is, but not graphics memory.
  <dbaron> (I don't think)

  Florian: I'm convinced by the multi-actor story.
  leviw: The change is that 'contains: paint' doesn't compute
         'overflow: visible' to 'overflow: clip'
  ojan: This is section 3.3., delete item 1
  ojan: Remove "must convert to clip"
  <leviw> https://drafts.csswg.org/css-containment/#containment-paint
  fantasai: "used value is clip" ?
  dbaron: Used value is messy
  <dbaron> (used value isn't really a general concept)
  <ojan> Proposed resolution: Remove any mention of overflow:clip
         from the containment spec and change section 3.3 to define
         that clipping happens (just not via used or computed values)

  RESOLVED: Remove any mention of overflow:clip from the containment
            spec and change section 3.3 to define that clipping
            happens (just not by affecting value of 'overflow')

CSS Text
========

white-space: pre-wrap / pre-wrap-auto
-------------------------------------

  Florian: I want a resolution on this, in my head it's done.
  Florian: No idea how to get rest of group to agree.
  Florian: We discussed this in NYC, came to a resolution
  Florian: Which I'm happy with, but koji isn't.
  Florian: Being a co-editor of that spec, his point of view is at
           least somewhat relevant :)
  Florian: At a very high level my position is simple:
  Florian: 1. Interoperability is desirable
  Florian: 2. whitespace: pre-wrap should preserve and wrap.
  Florian: We don't have these things today.
  Florian: Browsers all do different things.
  Florian: Relevant question is what happens to white space at the
           end of a line.

  gregwhitworth: What was the resolution in NYC?
  Florian: Resolution at NYC was that white-space: pre-wrap would
           preserve white space, and break between spaces.
  Florian: This is not what is happening today.
  Florian: In Chrome and webkit, all white space is preserved *if it
           would not overflow*.
  Florian: The bit that would overflow is compacted to zero width
  Florian: which makes it very confusing when you're trying to edit.
  Florian: The Microsoft behavior does the white space, but the
           white space at the end of the line is allowed to overflow
           (like hanging-punctuation).
  Florian: Firefox behavior, which is what's specced, is preserved
           white space is non-breaking and break opportunity at the
           end of the run.
  Florian: Doesn't overflow, doesn't compact.
  <gregwhitworth> http://log.csswg.org/irc.w3.org/css/2015-05-18/#e553590
  <gregwhitworth> resolution from NYC^.
  Florian: NYC resolution made the default behavior good for the
           case I care about.
  Florian: Koji is right to point out that this behavior is not
           great for other use cases.

  Florian: I'm okay to have default behavior that's not that.
  Florian: Whatever we resolve, the default behavior to be, we also
           need a mode where:
  Florian: 1. All white space is actually preserved.
  Florian: 2. It does not cause overflow, it does wrap.

  Florian: After that I have preferences on how it should wrap, but
           these are only preferences.
  Florian: Prefer that asking white space to wrap should not
           simultaneously allow arbitrary breakpoints in the middle
           of words.
  Florian: Fairly strong preference.
  SteveZ: Clarification, you have to pick some breakpoint at the end
          of the line.
  SteveZ: You're saying that breakpoint is the end of the line
          whether in a word or not, at least for one option, and you
          don't like that option.

  fantasai: I have a proposal.
  fantasai: My proposal is maybe in level 4 or possibly right now.
  fantasai: We define Microsoft's behavior as the default behavior
  fantasai: Because I think that makes the most sense.
  <tantek> is that Microsoft Word behavior?
  <koji> tantek, no
  fantasai: Add value to word-break property "break-spaces"
  fantasai: which allows breaks between white space characters.
  fantasai: I think that would be the best end result.

  koji: First, I'm not sure if we officially revert NYC resolution.
  Florian: I don't want to revert resolution and then close the
           discussion. I'm okay with reverting resolution in order
           to replace with better solution.
  SteveZ: I think a number of us willing to revert resolution if
          there is a replacement but not without one.
  SteveZ: So can't break it down like that. Let's agree on the
          replacement first.

  koji: For fantasai's proposal, agree on 2nd point add value to
        word-break property.
  koji: For first point, I would prefer of Word behavior over IE
        behavior.
  koji: It works better for me if default behavior is IE or Word
        (same as Chrome/WebKit).
  Florian: I prefer IE behavior, but okay with allowing both,
  Florian: On the condition that Chrome will break and wrap the
           extra spaces, not collapse them at the end of the line
  Florian: when word-break: break-spaces is specified.
  * fantasai agrees with Florian
  SteveZ: I'm getting confused, if the spaces disappear if I don't
          say "break-spaces", but they're visible if I say "break-
          spaces"
  SteveZ: Seems like that would be confusing to a user.
  Florian: This is why I prefer the IE behavior over the Chrome one.
  Florian: I think it's weird that in a mode called "white-space:
           preserve and wrap" it's not preserved.
  Florian: But given what's out there, I think it makes sense to
           allow it.
  [...]
  <gregwhitworth> http://jsbin.com/zudatozoqi/1/edit?html,output
  Florian: From 5-sec check, looks like Chrome is doing the IE
           behavior.
  ojan: My guess is that this was an accidental change, but maybe
        we'll keep it ^_^
  Florian: In a quick demo, it looks like Chrome does what we've
           been calling the IE behavior.
  Florian: So I'm happy.
  Florian: Safari probably didn't accidentally do the same thing at
           the same time.
  Florian: So we probably still need the same exception.
  Florian: Unless Apple wants to align on the IE behavior for this?
  [...]
  fantasai: I think we should just allow both for now.
  Florian: Agree.
  ...
  dbaron: The IE behavior is that you're allowed to have white space
          hang outside the edge of the line box.
  Rossen: and it's scrollable space, I know :) :) :)
  tantek: It's scrollable!?
  tantek: You can scroll to see nothing?
  Florian: You should be able to scroll to see your caret when you
           are editing.
  tantek: We have so many problems with editing, we shouldn't solve
          this one either.

  <fantasai> Proposed resolution: Spaces at the end of a line must
             be either visually collapsed if they would either
             overflow or cause wrapping, or they must hang outside
             the line.
  <fantasai> In order to prevent overflow or wrapping of invisible
             white space, spaces at the end of a line must either be
             visually collapsed to fit within the line or must hang
             outside the line (as in hanging punctuation)
  <fantasai> (better wording)
  <fantasai> In order to prevent overflow or wrapping of invisible
             white space, spaces at the end of a line must either be
             visually collapsed to fit within the line or must hang
             outside the line (as in hanging punctuation)
  koji: This looks good to me
  koji: I still don't understand conversation over there (waves at
        gregwhitworth).
  koji: Seems there was some miscommunication, I think I'm fine if
        current Canary behavior is fine.

  fantasai: Proposed resolution has a second part: adding a
            break-spaces value to word-break
  fantasai: ... details to come later.
  fantasai: Definition is that breaks are allowed between whitespace
            characters. (to satisfy Florian's concern)
  SteveZ: Which means white space at the end of the line can wrap to
          the next line.
  tantek: You could resolve that independently.
  Florian: I want to resolve together, because replacing the NYC
           resolution means we lose what I want, unless we add this
           behavior.
  [tantek argues process stuff]
  <tantek> no I objected to tying too many things together.

  koji: One issue, NYC allowed breaking before spaces?
  Florian: Not doing that break is okay with me.
  [More arguing over process]

  dbaron: I'm not happy adding more stuff here.
  astearns: Are you objecting?
  dbaron: Not really.
  astearns: What we have sketched out seems like it'll get us better
            interop today, and will not close off functionality.
  dbaron: We should talk about functionality that exists today as
          functionality that we have interop on.
  tantek: I'm happy with NYC and happy with today's change that
          gives us more interop.
  tantek: I'm not okay to committing to new functionality,
  tantek: okay with leaving the door open.
  tantek: I'm not okay with committing to it, it's a separate
          discussion.
  Florian: If we have identified the way to solve a problem, let's
           put it in the spec and mark it at-risk.

  astearns: We've literally spent hours on this. Would you object to
            resolving to adding the new value to Text Level 4?
  astearns: Then we are resolving both, because I've heard nobody
            objecting to both.
  RESOLVED: In order to prevent overflow or wrapping of invisible
            white space, spaces at the end of a line must either be
            visually collapsed to fit within the line or must hang
            outside the line (as in hanging punctuation)
  RESOLVED: Add 'word-break: break-spaces'

  Florian: As part of that discussion, we added pre-wrap-auto, do we
           need it?
  fantasai: I'm strongly in favor of dropping it.

  RESOLVED: Drop pre-wrap-auto

text-wrap: balance and fragmentation
------------------------------------

  astearns: When you have text-wrap: balance, and the element
            fragments across fragmentainers, do you continue to try
            to balance?
  astearns: I think the answer is yes.
  Florian: Question is also what does balancing mean?
  fantasai: The goal is to minimize the sum of the squares of the
            extra space left in each line in the element across all
            fragmentainers.
  astearns: If I have a 2-line heading that fragments, then don't
            want to have one word on the second line.
  astearns: Bad enough on one page, it's worse if it's fragmented
  SteveZ: Balance means that every line in a given fragment has the
          same ending point, and there are an integral number of
          lines.
  SteveZ: If the second fragment is shorter than ... ?
  [Florian reads from the spec]
  Florian: You want to minimize the variation overall, but you want
           to do the averaging over the fragment.
  Florian: If your first fragment is 10em and the second is 4em
           don't want to balance at 7.5em.
  ...
  SteveZ: fantasai said it correctly. You want to minimize the extra
          space to the line, it's not the length of the text in the
          line you care about.
  SteveZ: If you say it that way, then you don't run into the issues
          Florian said.
  astearns: I'm happy to make that change.

  RESOLVED: text-wrap: balance evaluation works off of remaining
            space in the line, not average line length

text-decoration
---------------

  koji: Topic is by Masayuki at Mozilla
  <astearns> https://readable-email.org/list/www-style/topic/css-text-decor-doesn-t-example-3-in-text-underline-position-break-current-ua-behavior
  koji: There was some conversation with fantasai and me.
  koji: Current text decoration assumes we have a UA style sheet to
        determine underline position based on language.
  koji: What Masayuki and myles and I prefer is that it be more
        automatic,
  koji: rather than UA style sheet to define.
  koji: Second point is that current syntax is extensible but more
        complicated than necessary today.
  koji: So prefer simpler syntax,
  koji: Good enough for now.

  fantasai: I don't think I understand why we are putting magic into
            auto instead of relying on UA style sheet.

  koji: Two value syntax is more complicated than single-value syntax
  koji: When single value can do the work, prefer single value for
        now.
  fantasai: I still don't understand the issue here, really, so I
            can't comment.

  dbaron: We didn't do text-emphasis the way the spec said.
  xidorn: What we did for text-emphasis-position was to implement it
          as a presentational hint.
  fantasai: So identically to UA style sheet, but it's at the wrong
            level of the cascade [which is mostly unnoticeable,
            unless you're in a user style sheet rather than author
            sheet]
  xidorn: ...
  xidorn: text-underline-position has specific concerns
  xidorn: text-underline-position is something authors are more
          likely to change.

  <koji> https://lists.w3.org/Archives/Public/www-style/2016Jan/0195.html
  [From the e-mail above:
      Clarify when "under" alone is used, its position in vertical
        flow is automatic (the behavior isn't defined today.) The
        value syntax could be one of: a. No change: auto | [ under
        || [ left | right ] ] b. Full options: auto | [ under ||
        [ left | right | auto ]] c. Simpler: auto | under | left |
        right
      So now my proposal is above 1 and 2, and:
        3. Clarify when "under" alone is used, its position in
        vertical flow is automatic (the behavior isn't defined today.)
        4. The value syntax could be one of: a. No change: auto | [
        under || [ left | right ] ] b. Full options: auto | [ under
        || [ left | right | auto ]] c. Simpler: auto | under | left
        | right
  ]

  fantasai: I agree with 4, I don't agree with 3.
  fantasai: I don't think we should have auto be language dependent,
            use the UA style sheet for that.
  fantasai: UA style sheet would assign CJK languages to left or
            right as appropriate
  fantasai: and everyone else would get auto.
  fantasai: left/right implies either auto or under, don't really
            care.
  fantasai: I think that auto should never switch the underline to
            the over side.

  koji: I don't know how Gecko switches between two underlines, but
        with this spec if the page has lang=ja, page would use
        automatic switching.
  xidorn: I don't think we've implemented that.
  xidorn: So we haven't supported text-underline-position yet.
  koji: Gecko changes underline position without property, depends
        on fonts or whatever.
  koji: Having this spec will force the underline position to be
        under.
  fantasai: Different fonts have different underline positions anyway.
  koji: Font information has alphabetic position.
  koji: If Japanese, most ignore that and draw at correct position.
  koji: When the page has lang=ja, this spec forces that underline-
        position is under.
  koji: What gecko does, or what I guess gecko does it regardless of
        language, using font or whatever information, they would use
        auto.
  koji: I actually agree that that's better behavior for CJK.
  koji: If the page has lang=ja, but still the underlined text is
        only alphabet, then underline should be drawn at baseline
        position.
  fantasai: I still don't understand what you're proposing so I
            can't comment on it...

  Scribe: Bert

  koji: I need to talk to Mozilla people and see if I can better
        understanding.
  astearns: Can that be on the www-style list instead?
  koji: Yes.
  koji I'll take it back to mailing list.
  astearns: OK, break now.

  <break duration=15min>

word-break: break-word
----------------------

  [This discussion shifted here from the end of the day.]

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0010.html
  koji: I replied to mailing list about non-standard property to
        remove from blink and WebKit.
  koji: "word-break: break-word"
  koji: Should we add 'break-word" to the spec?
  koji: Historical from webkit.
  koji: It was historically added to WebKit for web compat despite
        being non-standard.
  BogdanBrinza: 9 years ago, change in webkit references IE7
  BogdanBrinza: The usage is fairly high.
  BogdanBrinza:  Used in yelp, stack overflow, fairly big sites
  koji: It's very similar to word-wrap: break-word except it doesn't
        expand the containers.
  koji: The use case is imagine normal word wrap where the text
        contains a long URL.
  koji: word-wrap: break-work expands the container while
        word-break: break-word will break the word to maintain the
        container size.
  <gregwhitworth> they add it to content editable by default, here's
                  a testcase http://jsfiddle.net/pfe9mj4o/10/

  koji: fantasai: Is Microsoft implementing this?
  BogdanBrinza: We are considering it, the web depends on it.
  BogdanBrinza: We will consider implementing it for web compat.
  fantasai: The naming is very confusing.
  Florian: These names are already confusing, adding this makes it
           worse.
  astearns: That's a good question, if there's a typo do you
            standardize it for web compatibility?
  fantasai: I think the better solution would have been to let the
            author set the minimum size of the table cell.
  Florian: Regarding this it sounds like you're considering this for
           web compat, I don't think the working group is best for
           this decision.
  Florian: Decide and if you do send us the spec of what you
           implement.
  fantasai: I don't object to adding this if implementers decide
            it's necessary for compat.

  RESOLVED: Add word-break: break-word to spec if Edge/Firefox
            find it critical enough to Web compat to implement it.


Exclusions and bidi
===================
  Scribe: zcorpan

  koji: The issue is CSS exclusions when exclusions split a line.
  koji: bidi defines that after linebreak was determined.
  koji: bidi algorithm is applied to the line
  koji: so when the line is spread my multiple by css exclusions.
  koji: Does each part of the line apply to bidi algorithm?
  astearns: My understanding is that exclusions will fragment the
            linebox and each line will be individually considered
            for bidi.
  koji: That answers my question but it's not in the spec.
  shane: Is this the easier behavior?
  koji: Yes.
  astearns: An exclusion can intrude in the middle of a line box,
  astearns: when that happens two line boxes are created.
  astearns: Each is individually considered for bidi.
  Florian: Need to elaborate on the last part.
  Florian: Is it just like line breaking?
  astearns: Everything that would happen with regular line breaking
            would happen here also.
  dbaron: I agree this makes sense.
  dbaron: You need to specify which half of line goes where.
  dbaron: Depends on block's directionality.
  <shane> it's the reordering part that would be impacted by the
          decision of whether there is one line or two lines.

  Bert: If the exclusion is very small, might look better to do the
        reordering as if it were a single line.
  astearns: This is an error case, it's better to make it so lines
            are not split
  Bert: [describes edge case]
  Florian: it's not a problem for LTR-only or RtL-only
  <zcorpan> Proposed resolution: lines split by exclusions is
            equivalent to a regular linebreak for the purposes of
            bidi algorithm
  <zcorpan> Proposed resolution: lines split by exclusions is
            equivalent to a regular linebreak for the purposes of
            bidi algorithm, where which half of the line goes where
            depends on the block's directionality.

  RESOLVED: When a line is split by an exclusion, each side is
            its own line box for the purposes of bidi algorithm
            (i.e. they are effectively separated by a soft line wrap).
            Which line box is first depends on the block's
            directionality.

Received on Wednesday, 23 March 2016 21:32:48 UTC