W3C home > Mailing lists > Public > www-style@w3.org > March 2018

[CSSWG] Minutes Telecon 2018-03-21 [css-text] [css-text-decor]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Mar 2018 20:14:33 -0400
Message-ID: <CADhPm3tN-Zv0Qv2gPN5-5CPiwHXOmV-ojMiTg1DL=pq5FbX3zA@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Text

  - Issue #1997: white-space collapse at end of line: test case and
      - RESOLVED: Spec Gecko's behavior at the ends of lines in
                  display text
      - Gecko's behavior is summarized as white space trimming at the
          start and end of the line operates through any inline box
  - Issue #2003: overflow-wrap: break-spaces can effect behavior even
      when there are previous breaking opportunities in the line
      - RESOLVED: Simplify the definition of break-spaces as in this
  - Issue #1484: letter-spacing computed values don't reflect reality
      - Originally the proposal was to have normal compute to normal
          but behave as 0 as this was how browsers were believed to
          currently behave.
      - AmeliaBR created a codepen
          which showed getComputedStyle returning normal for 0 with
          several browsers, so the spec text would need to accommodate
          this behavior since it's already interop.
      - RESOLVED: We have the spec say computed value of
                  letter-spacing is absolute length. There's a quirk
                  to getComputedStyle where 0 serializes to normal and
                  that doesn't extend to the computed style map.
  - Issue #785: Hyphenation usages in CJK
      - RESOLVED: No change on issue #785
      - Florian will file bugs on browsers to fix/support the
          break-all keyword for the word-break property which
          minimizes the issue reported in this bug.

CSS Text Decor

  - Issue #2376: Add use-font keyword for text-decoration-width &
      - RESOLVED: Add a use-font (name to be bikesheded) keyword for
                  these text decoration metrics.


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0038.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Garrett Berg
  Tantek Çelik
  Benjamin De Cock
  Elika Etemad
  Dael Jackson
  Myles Maxfield
  Thierry Michel
  Anton Prowse
  Liam Quin
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Lea Verou

  Dave Cramer
  Alex Critchfield
  Peter Linss
  Melanie Richards
  Greg Whitworth

Scribe: dael

  astearns: Let's get started.
  astearns: Is there anything extra for the agenda today?
  astearns: I have one.
  astearns: We have a F2F soon. Please add things to the agenda by
            tagging them in github or adding them to the wiki.
  astearns: As I find things in the issues list and add them to the
            wiki I will remove the tag from the issue.

CSS Text

white-space collapse at end of line: test case and queries
  github: https://github.com/w3c/csswg-drafts/issues/1997

  florian: I can try and cover for fantasai.
  florian: If she's not here.
  fantasai: I'm here.
  fantasai: There's inline box boundaries that prevent the whitespace
            from collapsing at the end of the line for certain impl.
  fantasai: You can see from the example in the issue.
  fantasai: Question is will we collapse all consecutive spaces and we
            have the end of the line and after the space the inline
            tag closes. Does the space at the end collapse even though
            there's an inline box boundary. I say yes for the reasons
            in the comment.
  astearns: Looks like we will have interop with Gecko, upcoming
            Blink, upcoming Edge.
  fantasai: I don't remember the Blink testcase, but we will have some
            engines that do that.
  fantasai: An important reason to do this is authors will expect
            this. When closing tags aren't tight against the last it
            just hangs out and it's unexpected. having a space hanging
            out inside be different then outside doesn't make a whole
            lot of sense.

  astearns: Any concerns with trimming the trailing space?
  florian: Agree
  myles: I don't quite understand the test case. I thought spec was
         all trimmed except the first. So the space shown isn't from
         inside the span? Maybe I should take this offline.
  fantasai: Space is after the first. If you have a series of
            collapsible spaces the first is preserved.
  myles: It's before the span with the border-left in the firstline.
  fantasai: Test cases have checks for before the text and after.
            Whitespace does 2 phases, one go down to one space and
            then go through the line and any space adjacent to start
            or end is trimmed.
  myles: Let's take this offline. Resolution is fine.
  Rossen: You're okay to resolve on current behavior and continue to
  myles: I'm a little confused about the test case, but in the issue
         there was a proposed resolution to use the Firefox behavior.

  Rossen: I would point out that even though you'll get similar
          renderings with at least our current work in progress as
          well as what I'm assuming the NG layout is aiming for in
          Chrome. I can't speak to webkit, I don't have a device near.
          As soon as you start interacting with this particular test
          case in contenteditable or you select it, you get very
          different behavior.
  Rossen: I'm not sure how much this resolution captures this.
  florian: I think the problem of having more divergence as to what
           happened to spaces when you select them goes way beyond
           this test case. We probably should tackle that separately.
  Rossen: My point is we should either, ideally have a note for this
          or test cases that involve selection. Something that allows
          us to proceed forward more interop. I think we've discussed
          extensively in the past and made some progress.
  Rossen: I want to point out this issue doesn't address any of that.
  florian: That's fair and this is something I'm interested in looking
           into. I'll try and see what the spec says about when
           selecting and editing. It's separate, but I want to look
           into it.
  astearns: Setting contenteditable and selection aside, it sounds
            like we're converging on Gecko's behavior for trimming at
            the end of lines for displayed test

  astearns: Objections to spec Gecko's behavior at the ends of lines
            in display test?

  RESOLVED: Spec Gecko's behavior at the ends of lines in display text

CSS Text Decoration

Add use-font keyword for text-decoration-width & text-decoration-offset
  github: https://github.com/w3c/csswg-drafts/issues/2376#issuecomment-371376593

  fantasai: Suggestion to have a keyword to use metrics in font.
            Proposals were use-font and from-font. We're open to other
            ideas. Resolution I'm looking for is a keyword for this
            thing. I vaguely recall another property with a similar
            keyword, but I couldn't find it.
  astearns: I don't recall.
  myles: I think having a new keyword is fine. Point I raised in the
         issue is that impl may want UA dependent fixup if font has
         ridiculous values.
  fantasai: That's fine.
  florian: Do you plan that for a known list?
  myles: It's done automatically so I can't comment on a specific
         algorithm, but it's impl detail on how we perform the fixup.
  florian: Okay.
  astearns: Spec would say use-font would use metrics from first
            available font if they are reasonable?
  myles: Or just say it would similar metrics to the font...that's
         bad...I'm not sure exact text.
  myles: You could have a second sentence saying UA MAY synthesize
         values. I'll defer to fantasai. She can do a good job.

  astearns: Question is if we add this keyword. Does anyone have
            concerns about adding a use font keyword for these text
            decoration metrics.
  astearns: Objections?
  astearns: I'm assuming use-font is what we should use.
  fantasai: Use-font and from-font are the top two.
  astearns: Use sounds better to me.
  <liam> i prefer from-font
  <liam> since the font's glyphs aren't used.
  fantasai: We're not dead set on this if there's a better idea.
  <florian> +1 to from-font, but no objection to the other one

  RESOLVED: Add a use-font (name to be bikesheded) keyword for these
            text decoration metrics.

CSS Text

overflow-wrap: break-spaces can effect behavior even when there are
    previous breaking opportunities in the line
  github: https://github.com/w3c/csswg-drafts/issues/2003#issuecomment-370652901

  florian: myles noticed a complication in a corner case of the
           handling of break-spaces. Initially intentionally
           introduced, but it is a complication. Since
           line-break-anywhere exists this brings nothing to the
           platform. All variants remain possible.
  myles: Background, we are interested in using icu breaking
         iterators. There's a bunch of modifiers for breaking
         including overflow-wrap which should only kick in if a
         breaking opportunity wasn't in the line until the end.
  myles: Corner case is where we couldn't look at all properties and
         create icu breaking iterator because breaking opportunities
         depending on earlier in the line. It would be great if this
         corner case could be removed.
  myles: I believe the commit fantasai made satisfies that constraint
         so it's okay now.

  astearns: Concerns with this simplification?
  Rossen: Trying to wrap my head around what it means for impl that
          impl the corner case.
  florian: No one impl yet.
  Rossen: I think not in a shipping form.
  myles: As I understand if I impl what was in there before I need
         special handling and an if statement. I think after there's
         no if or special handling. I don't know how the Edge impl
         works but I would imagine it would be simpler.
  florian: There was also a slight error in the wording for the spec.
           [reads] If we remove the normative requirement there's
           independence where there was interference before the change.
  florian: For the details of what and why we're need a whiteboard.
  Rossen: If we can attach the JS to exemplify that would be great.
  myles: I couldn't fiddle but I did mockups in pngs inside the thread.
  myles: Proposed resolution is to accept fantasai's commit.
  Rossen: I did review. I won't object. I'm just trying to work
          through ramifications.
  astearns: So Rossen are you okay to resolve now or do you want time?
  Rossen: We can resolve now. I will play with the behavior and try to
          come up with the test cases myles was trying to exemplify. I
          don't think it'll be a problem.

  astearns: Obj to simplify definition of break spaces?
  Rossen: What is the technical version of that resolution?
  astearns: We have the commit. Simplify the definition of
            break-spaces as in this commit.
  <florian> url to the commit:
  Rossen: great

  RESOLVED: Simplify the definition of break-spaces as in this commit:

  * florian intends to write a test case for that

letter-spacing computed values don't reflect reality
  github: https://github.com/w3c/csswg-drafts/issues/1484

  fantasai: Property has a normal keyword that's the initial and takes
  fantasai: normal is effectively 0 except in 2.1 we said normal you
            could adjust inter-letter spacing for justification
            purposes. In text L3 I decided that was unnecessary
            restriction and we shouldn't distinguish normal and 0.
  fantasai: Spec says they're 100% equivalent. Since impl do normal to
            normal for computations we can say normal computes to
            normal and means 0. I don't see a significant difference.
            Reason to compute through it you don't have to set a value
            to animate. normal to normal advantage is it's impl.
  myles: Making sure I understand. If I animate from -5 to 5 I'll get
         visual flash?
  fantasai: No, if you animate from initial value to 1em it won't
            animate correctly because it's a keyword.
  myles: So that's why you unified 0 and normal?
  fantasai: I did it because we might as well have computed value
            reflect what's in the engine. So at the end when you get
            computed you can't tell there's a normal. In terms of
            computed value the only observable difference is
            animations and transitions.
  myles: okay
  astearns: It's work for each engine to change from computing to
            normal to compute to 0. Seems like we have at least 3
            engines computing to normal. I'm not sure there's enough
            value to justify the work.

  <AmeliaBR> FYI, In Chrome, letter-spacing: 0 computes to "normal".
  <fantasai> AmeliaBR: that's a *problem*
  <AmeliaBR> (In Edge & Firefox, it computes to 0px)
  fantasai: AmeliaBR points out a test case where Blink computes 0 to
            normal and that shouldn't happen.
  astearns: That's a bug.
  dbaron: May be a sign that the animation thing works.
  <Rossen> Edge computes to 'normal'
  astearns: And if anyone depends on that working in Chrome it might
            be worth the effort.
  astearns: We'd have to see if any other engine has a bug.
  fantasai: So make the spec match impl and if people come back with
            use cases we can change back.
  astearns: Change spec to say normal computes to normal.
  astearns: Obj?
  Rossen: We resolved on this 2 weeks ago. I'm fine resolving again.
  fantasai: Might have been a different property.

  myles: Are we trying to change semantics or computed value?
  astearns: Just computed. We're changing the spec for the computed
            value to match impl.
  Rossen: And what AmeliaBR points out that chrome...edge computes to
          normal as well.
  florian: Why?
  Rossen: The web needs to work.
  fantasai: noooooo...that's bad.
  astearns: 0 computing to normal seems like you'd lose information.
  florian: They do the same thing so not really...
  Rossen: I can fix the bug if there's a similar fix in other engines.
  Rossen: I'm all for resolving here. I just want to point out what
          the irc states about Edge is not correct.
  myles: I tested in webkit you set 0 and computed returns normal.
  Rossen: There's a codepen from AmeliaBR.
  florian: So only FF does normal to normal and 0 to 0?
  Rossen: Yes.
  florian: Why????
  astearns: Probably they matched another engine.
  <AmeliaBR> In my testing, Edge v16 is returning 0px. So they must
             have changed for v17, if that's what Rossen is seeing.
  florian: If we've got 3 engines doing it there might be a reason. A
           compat reason.

  fantasai: Gecko hasn't changed to do this thing. That's good enough
            reason to say the spec doesn't want that.
  astearns: Edge made the change recently so Rossen you might be able
            to find out why the change was made.
  Rossen: I would guess interop issue. I could go through finding the
          bug. We're not going to go back to be 0 and break interop to
          comply to the spec if the web doesn't do that.
  Rossen: You need to lobby with Chrome and Webkit and then we'll fix.
  <fantasai> Computing zero to 'normal' makes *no sense*
  astearns: The question of what normal computes to I can see the
            value of computing to 0 for animations. I don't think it's
            worth it. I don't see the value of 0 computing to normal.
            That seems like matching for matching.

  liam: Is normal required to be 0? You can't do smaller spacing?
  florian: That would be a violation.
  fantasai: You could change spec to allow that. If normal computes to
            itself it can be different then 0. It could do what liam
            says and take into account optical sizes and adjust
            inter-letter spacing if font says that for example.
  fantasai: I don't think we have fonts that do that or impl that do
            that so normal and 0 are eq. but could be different.
  florian: We've got what does normal compute to and lots of people
           compute to normal. 0 computing to normal is a separate
  dbaron: The 0 computing to normal might happen at level of
  myles: Exactly. In our impl when we represent letter spacing it's a
         float. We don't store extra information to know if it was
         normal. It's one float until we produce the getComputedStyle
         and if it's 0 we write normal.
  Rossen: I think same for us.
  <AmeliaBR> So "normal" would be the "used value" for a computed
             value of 0?
  fantasai: That makes sense. If they want to store as a float that's
            fine. Computed value of 0 should be 0 and have normal
            compute away. Turning into a keyword in the middle makes
            no sense.

  florian: Should we say in addition to normal compute to 0 resolved
           value may or must be normal?
  florian: If everybody does it...
  fantasai: Gecko isn't. If this is an impl issue where they're not
            storing enough information to know if it's was normal or 0
            they should output 0. It just requires no special case in
  florian: There may be a set of scripts expecting it.
  fantasai: If that script exists we can reconsider. Gecko doesn't do
  dbaron: More likely is a script that looks at getComputedStyle to
          know if it's the initial value. It looks for normal and says
          'oh, that's the initial value'
  florian: If Gecko hasn't heard it's not that bad.
  dbaron: All browsers agree is if you set nothing getComputedStyle
          returns normal.

  astearns: This has taken a lot of time.
  astearns: I suggest we resolve on computed value of normal, change
            the spec to say normal is the computed value of normal.
  florian: computed value of normal is 0 [missed] for animation it's 0.
  <dbaron> I think the best option may be to leave the spec as it
           is... if one of the non-Gecko browsers is willing to change.
  astearns: Do we want impl detail of how this is stored?
  fantasai: You can tell if you're doing that based on how it
            animates. It's about what computed style is. We're down to
            the spec if fine to say letter spacing normal computes to
            0. Now we need to know if getComputedStyle value of zero
            becomes the string normal and that's a web compat question.

  <myles> dbaron: what different behavior does gecko have for normal
          and 0?
  <dbaron> myles, IIRC, none
  <dbaron> myles, but letter-spacing and word-spacing represent their
           values the same way
  <myles> dbaron: so you just have the extra bit just for
  <dbaron> myles, I think so

  Rossen: Take the two issues separately. First one I think is easier.
          getComputedStyle value of letter spacing spec as normal
          should be normal. I think that's the original thing we
          wanted to resolve.
  fantasai: The question was the computed value which isn't the same
  fantasai: All impl currently if you spec letter-spacing:0 they store
            computed value of 0. They may or may not return
            getComputedValue of 0. It may convert to normal during
            that call.
  fantasai: Several impl store it as a number. Gecko makes a
            distinction between specified as normal and specified as 0.
  fantasai: All impl if you spec 0 they store 0. Gecko stores normal
            if you spec normal. During getComputedStyle API call there
            are several impl that convert 0 to report at normal. Gecko
            returns the keyword or 0 depending on what spec.

  florian: Ideally what we want is everyone to converge to computing
           normal to 0 but there may be web compat issue on that.
           Maybe have people that recently changed figure out why and
           we can see if the web compat is manageable or not.
  myles: If we're going to resolve we should resolve on what 3 or 4
         browsers do.
  florian: It's insane
  myles: But 3 of 4 do it.
  florian: But 4th doesn't so it's not required.
  Rossen: Are you going to try and spec text that will set right
          expectation for authors or write academic papers.
  florian: If we have a dependency we write that. We have a browser
           that doesn't do it.
  Rossen: Let me give an example. If you recall the flexbox percentage
          for top and bottom padding it was done only for web compat.
          We want the web to work and applications to use the web.
  fantasai: No one disagrees.
  Rossen: If we spec something not in any browser but FF do you expect
          anyone will change?
  florian: You're making 2 arguments. The web compat I agree. The fact
           that FF doesn't do it we're not locked on. I would prefer
           doing the sane thing if we're not locked.
  florian: It's not necessarily a web compat problem because not
           everyone does the same thing. Given that we may not be
           stuck I'd prefer to try and do the sane thing.
  <fantasai> Specifying 'letter-spacing: 0', having it behave as zero (
             observable from animations), and having getComputedStyle
             returning 'normal' is very weird

  astearns: I'd like to go back to dbaron on IRC where he thinks best
            option is leave spec as is where computed value should be
            absolute lengths. I believe that would require Gecko to
            change to leave off the normal value, but he mentioned
            non-Gecko browsers would need to change.
  astearns: I think what florian said is we need to find out if this
            is a web compat thing.
  florian: Someone will have to change any way.
  hober: Absent compat data engines won't change.
  hober: Absent compelling data that one is preferable three engines
         win. It doesn't matter if it makes sense.
  hober: I don't see why we're still arguing.
  <tantek> can't even find a bug in bugzilla on this for compat reasons
  <tantek> does this affect transitions?
  <tantek> tangentially related:
  astearns: I think we're arguing because it's a hard pill to spec
            behavior that we think has no value.
  florian: We have to add things to the spec to add the special case.
  fantasai: I think it's not a benefit to authors that if they spec
            letter spacing 0 and get back normal.

  dbaron: I think the other thing that makes sense it spec the
          computed value is a number. In getComputedStyle a computed
          value of 0 serializes to normal and not extend that to
          computed style map.
  fantasai: If we spec this that's how we have to spec this. When you
            spec 0 computed is 0. It's only the getComputedStyle call
            that is normal. This is a resolved value quirk we have to
            put in. If it's not required by web compat I'd rather not
            do that. If this is just how people just cheated it in I'd
            rather not.
  dbaron: I think hober is right. It's not worth the energy we'd need
          to deal with the compat changes to fix this.
  astearns: You're willing the expend the energy to match?
  dbaron: Yeah.
  astearns: Proposal is we have spec say computed value of
            letter-spacing is absolute length. There's a quirk to
            getComputedStyle where 0 serializes to normal and that
            doesn't extend to the computed style map
  astearns: Objections?

  RESOLVED: We have the spec say computed value of letter-spacing is
            absolute length. There's a quirk to getComputedStyle where
            0 serializes to normal and that doesn't extend to the
            computed style map.

Hyphenation usages in CJK
  github: https://github.com/w3c/csswg-drafts/issues/785

  florian: In Japanese it uses mixed writing systems. Just because
           there's Latin characters it doesn't mean it's English. It
           won't get language tagged as English, but they do expect
  florian: My take is it should just be in the hyphenation dictionary
           for Japanese. If people want a hyphen the hyphen property
           does that if it's in the dictionary. For the rare word that
           isn't in the dictionary it should be language tagged.
  myles: Is this just Japanese?
  florian: If you're going to use German words, not tag them, and use
           them in English I'm going to assume it's common in English
           or the author did it wrong. English does not contain all
           words of all languages.
  <tantek> Schadenfreude for non-English languages?
  florian: It is somewhat common in Japanese to have words like that,
           but if they're common they should be in the dictionary. I
           don't want a property to hyphenate words not in the
           language they're in.
  florian: tantek's example is good.
  florian: Trick with Japanese where you can't tell it by the script
           in English and German, you can tell it by the script. But
           if a Japanese person wrote schadenfreude you can't tell
           it's not English.
  florian: If it's common put it in the dictionary. If it's not known
           it's not known.

  astearns: So florian you suggest don't do anything?
  florian: Other then fix bugs in some browsers. In the case where the
           author doesn't want hyphens, but just breaks between all
           characters, there's word-break:break-all it's only going to
           give you places except where there should never be a line
           break. 2 browsers break absolutely everywhere.
  fantasai: Initial complaint is solved by browsers fixing impl of
            break-all keyword to conform to the spec and include words
            commonly used in Japanese that use latin characters. For
            words that aren't common and won't be in Japanese
            dictionary authors will need markup to be appropriate.
  fantasai: General conclusion is no change to the spec, but initial
            problem is solved by the three things florian outlines.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/785#issuecomment-370366049
  myles: Spec doesn't say which hyphen opportunities exist. I guess I
         agree with florian. Impl have a lot of leeway on how to
  astearns: I'm a little concerned about resolving without koji but
            I'm personally convinced about no change.
  astearns: Objections to resolving no change on this?

  RESOLVED: No change on issues #785

  hober: florian do you have links to the bugs?
  florian: I have not. I only wrote the test an hour ago. I'll make a
           proper test and submit bugs.
  <dbaron> I think the relevant Gecko bug is
           although I might be wrong
  <dbaron> (and that was filed by fantasai)
  florian: koji found this and he said he can't do it because it
           didn't work in some browsers. dbaron asked if it was some
           or all and I wrote this test and it's some. It was an ad
           hock test so I'll write a proper one.
Received on Thursday, 22 March 2018 00:15:35 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:06 UTC