[CSSWG] Minutes Telecon 2019-03-20 [css-scroll-snap] [css-pseudo-4] [css-overflow] [css-inline]

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

Reviewing PRs

  - The queue of PRs that need review has gotten long so group members
      were asked to review PRs and reduce the queue.

TPAC 2019

  - The CSSWG has requested to meet on Monday and Tuesday of TPAC. An
      email will be sent to determine if a Houdini meeting should also
      be scheduled.

Scroll Snap

  - RESOLVED: Accept the edits for
              (Clarify that scroll-padding and scroll-snap-type on
              root propagate to viewport)

CSS Pseudo 4

  - RESOLVED: text-shadow:none in UA style sheets are override-able by
              authors for selection (Issue #3605: Specify better
              handling of text shadows for ::selection)

CSS Overflow

  - RESOLVED: Accept adding -webkit-discard value to continue
              properties to represent line-clamp that only applies to
              webkit flex boxes and make it shorthand expansion for
              -webkit-line-clamp (Issue #2847: Convert
              -webkit-line-clamp alias requirement into a spec issue)
  - RESOLVED: Accept the edits in
              (Allowing (or not) alternate ellipsis behavior for

CSS Inline

  - There was no agreement about changing the used value for
      line-height:normal to return the keyword 'normal' instead of a
      value (Issue #3749:A question for the procedure to compute the
      used value of "line-height").
  - Chromium returns the keyword but Webkit and Firefox return a
      value. The value returned may not be correct because
      line-height:normal calculates per fragment of the element and
      any value returned would not be able to capture the multiple
      possible values of 'normal'.
  - Given that Webkit and Firefox return the value the concern is that
      there is content on the web depending on this value. People
      planned to look more into the possible implications of the
      proposed change.
  - Discussion will continue on the github issue and this will be
      added to next week's agenda to try and reach a conclusion.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Mar/0004.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Dave Cramer
  Elika Etemad
  Javier Fernandez
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Nigel Megitt
  Anton Prowse
  Florian Rivoal
  Jen Simmons
  Lea Verou
  Greg Whitworth

  Dirk Schulze

Scribe: dael

  Rossen: Good morning and good evening. Happy first day of spring
  * AmeliaBR or first day of autumn…
  Rossen: Wanted to start with a call for additional agenda items you
          want to add or changes?

Reviewing PRs

  Rossen: Before we get going I wanted to draw your attention to PRs
          open against our draft repo
  Rossen: There are a number of people doing a great job at making
          changes and updating specs and drafts, but we also need
          review so we can get merged
  Rossen: Please help out and drain the queue

TPAC 2019

  Rossen: Next extra topic.
  Rossen: I have gone ahead and signed us up for Mon and Tues of TPAC
          which is in Japan Sept 16-21. We meet Sept 16 & 17 which is
          Monday and Tuesday
  Rossen: Question to that topic, should we have a Houdini meeting?
  Rossen: I can book half a day or a day room on Thursday, but I need
          a signal on if needed
  <AmeliaBR> FYI, the SVG group has asked for meeting on the Thursday
  Rossen: Think about it and I'll start an email thread on private list

Scroll Snap

Clarify that scroll-padding and scroll-snap-type on root propagate to
  github: https://github.com/w3c/csswg-drafts/issues/3740

  Rossen: fantasai are you on?
  fantasai: Yeah. I think it was assumed by all of us scroll snap
            property applied to viewport but we don't say so in the
            spec. I copied overflow draft and scrollbar draft to say
            propagates from root but not body element
  <fantasai> https://github.com/w3c/csswg-drafts/commit/b5afa1086cf344046ea87013f0c48b3800eaacd7
  fantasai: Edits ^
  florian: The way overflow propagates from body is weird. Not doing
           weird is good, but isn't a consistent good so can set both
           on body and the property together
  fantasai: Could set both on root instead. Don't propagate scrollbar
            width or color
  AmeliaBR: I haven't looked at edits, is it clear wording? Author
            expectation is if overflow on the body does scrollbars I'd
            expect that's where I put scroll snap. Maybe educate
            authors how that's weird and problematic but it's an extra
            level of lack of intuition
  Rossen: Agree. If body propagates background color and overflow prop
          back to viewport and canvas it would make sense to have
          scroll property. But as fantasai pointed out we want to stop
          all that legacy quirk behavior expansion of properties.

  Rossen: Couple ways forward- continue adding them because this is
          what authors expect. Or not do it and teach people by making
          explicit test cases and educational material and that they
          will face that it doesn't work, ideally find and article and
          see body stuff is a quirk there to keep legacy web working
          but don't do that
  Rossen: Kinda more leaning not add to body css
  Rossen: I do agree it makes sense to be explicitly pointed out apply
          to viewport
  AmeliaBR: Skimming edits it looks quite sensible. There is a note
            about not propagating from body but I don't know if we
            need to make that more author focused
  florian: I guess that's enough. fantasai mentioned this is also the
           case for scrollbar width. If we keep new stuff consistent
           and none work on body we have a fighting chance of getting
           people to set on root. I'm okay with edit as is if we make
           that the policy we follow

  Rossen: Other opinions?
  Rossen: Sounds like we're okay with the edits where scrollsnap
          properties propagate from root. Objections to accepting

  RESOLVED: Accept the edits for https://github.com/w3c/csswg-drafts/issues/3740

CSS Pseudo 4

Specify better handling of text shadows for ::selection
  github: https://github.com/w3c/csswg-drafts/issues/3605

  Rossen: Discussed once and the discussion was cut short. Who wants
          to resume that discussion and catch up the group?
  fantasai: The question was really the text shadows spec on an
            element and highlight element with background should text
            shadows show through
  Rossen: On element or on text?
  fantasai: On text.
  fantasai: Shadow is set on the element on DOM and you have
            highlighted that element. Are you seeing the shadow or
            not? The highlight has a background and generally paint
            text over background but that means text might not visible
            because have changed both text and background color and
            there's no assurance shadow color is appropriate to
            preserve contrast
  fantasai: Highlight colors come from elsewhere then dom element. I
            think it makes most sense to suppress text shadow unless
            author explicitly says what it should be
  florian: If an author explicitly considers shadows so they'll set it
           to the right thing. Most of the time they won't think about
           it and inherit and it probably will be wrong. I agree

  AmeliaBR: Complication I brought up last time is that there's no
            easy way to just say use whatever text shadow is on
            surrounding because weirdness of how selection inherits.
            Not just suppressing by default, but taking away option
            for author to say keep text shadow as is
  florian: Could do custom properties but that's a bit of a cudgel
  AmeliaBR: In contrast if we leave it as is which is keep drawing
            text shadow it's easy for author to override with
  fantasai: But most won't
  florian: Robust by default is important
  fantasai: I think cases where author will want text shadows and
            showing when highlighting will be less common then when
            author sets text shadow and not highlight or setting
            highlight colors and not thinking about it when setting
  AmeliaBR: That's true. I think as far as whether text shadow looks
            good or bad is 50/50
  fantasai: Not good or bad, this is about readable. This is a11y
  AmeliaBR: Reasonable to say default selection remove text shadows.
            Not reasonable to override user set selection styles. But
            if others disagree I've made my statement and won't object

  nigel: Makes sense. If have default selection color for background
         and foreground they apply and all the defaults make it
         readable that's fine. If someone overrides text shadow for
         selection they should look out. Other is if they override
         text shadow for selections we try and push a color change,
         but that's a pain to try and do to only modify the color if
         it's overwritten
  fantasai: I want to keep this not crazy complicated. We should try
            and use cascade as much as possible
  <nigel> +1 to not crazy complicated!
  fantasai: Probably simplest is add a text-shadow:none to UA default
            style sheet. If you want more complicated we can consider
  AmeliaBR: Do have some complications since default UA sets
            background and foreground but if author sets either,
            neither value applies. Set text shadow in same group where
            if author sets any we ignore whole set of UA rules
  <bradk> +1 to just being in UA stylesheet. Allowing footguns is
          better than being author-nanny.
  fantasai: Could do that. Additional weirdness. Not concerned with
            just UA but that author that sets selection is not the one
            that puts text shadow on this specific heading. They just
            want the header to look good on the page when it loads but
            not in this case. Will be difficult if want text shadow to
            show up in selection but not impossible. We should bias
            toward readable page
  AmeliaBR: Sure. As you say selections are about a11y not fancy

  AmeliaBR: So you are saying UA style sheet would have
            text-shadow:none but if author sets it in their selection
            styles that's fine?
  fantasai: Yes
  AmeliaBR: Okay
  Rossen: Nearing consensus. Any other feedback on this or is everyone
          getting around the same page. text-shadow:none in UA style
          sheets are override-able by authors for selection
  Rossen: Objections?

  RESOLVED: text-shadow:none in UA style sheets are override-able by
            authors for selection

CSS Overflow

Convert -webkit-line-clamp alias requirement into a spec issue
  github: https://github.com/w3c/csswg-drafts/issues/2847

  florian: Talked at F2F. Had follow up meeting afterwards.
  florian: We went through what was needed for supporting
           -webkit-line-clamp in contrast with spec. Concluded can't
           be a straight alias because there are quirks we don't want
           to propagate.
  florian: Defined a shorthanding mechanism, added to the spec to the
           satisfaction of all present.
  <florian> https://github.com/w3c/csswg-drafts/commit/2cc319448f4732c127fa43213ce7cf7d96de04ac
  florian: Commit ^
  florian: Given non-prefixed line-clamp works for some properties the
           prefixed version also would but setting weird values for
           weird behavior. Other than necessary bits it's all same.
  florian: I think people who cared were in the room and agreed, but
           if anyone else wants to say something...

  AmeliaBR: You could explain all the weirdness in terms of longhand
            it's just that prefix sets different defaults compared to
            regular version?
  florian: Most are normal, but the one that takes discard takes a new
           -webkit-discard value
  fantasai: There's a lot of weirdness in -webkit-line-clamp and spec
            makes most of the weird go away. There's one that would
            not be web compat where line-clamp is all boxes and
            -webkit-line-clamp applies to old style flex container and
            propagates to flex items. That's a little weird. Other
            differences between spec and webkit like where ellipsis
            goes we don't think are issues
  fantasai: This is because they're properties people are complaining
            about and working around already
  Rossen: Okay. Not because there will be no issues for rendering but
          because people expect better behavior so expectation people
          will adapt
  fantasai: Expectation is it won't cause pages to break in major ways
  florian: Small differences that are mostly improvements
  Rossen: I would only worry if changing line height in significant
          way. Some sites with tight layout like news sites they
          produce containers that have weird overlap and looks odd
          with as little as 1px line height difference
  Rossen: If this is mostly an improvement we'll have to see how it
  florian: Mozilla has looked and to the extent they found sites using
           it this won't be a problem. Won't know for sure until we
  Rossen: I think overall approach and alignment between legacy and
          new sounds great

  Rossen: Any additional thoughts or feedback before we resolve to
          move forward with proposal in
  Rossen: florian what is summary of resolution?
  florian: Accept the edit that's in the spec.
  fantasai: Accept adding -webkit-discard value to continue prop to
            rep line-clamp that only applies to webkit flex boxes and
            make it shorthand expansion for -webkit-line-clamp

  RESOLVED: Accept adding -webkit-discard value to continue properties
            to represent line-clamp that only applies to webkit flex
            boxes and make it shorthand expansion for

Allowing (or not) alternate ellipsis behavior for block-overflow
  github: https://github.com/w3c/csswg-drafts/issues/2905

  florian: Mats complained about previous state of spec and way we
           insert alternate ellipsis. One problem was spec defined
           that we insert ellipsis text as normal run of text on last
           line. Unfortunate side effect of that is it could grow line
           height it could introduce loops
  florian: Left undefined how to break the loop. But because this is
           hard we included a may that if you can't solve that you can
           just do it at paint time and not effect layout
  florian: Complaint is that main logic is undefined and alter log
  florian: Edited into spec is a solution for both. Main is simplified
           and may removed. Still insert at layout but text inserted
           has line-height 0 so it removes content due to
           fragmentation so if you remove a tall inline it gets
           smaller, but it can't shrink the line. Could change, but no
           loops. Therefore don't need simpler alternative as a may
  florian: Request is approve edits in place in the spec
  florian: This too was discussed in after F2F meeting

  Rossen: I'm assuming Mats is okay with edits?
  florian: Mats wasn't looped in. Had previous resolution half a year
           ago to go in this direction but specifics not written until
           recently. Since heycam is running with this that's whose
           feedback we focused on
  Rossen: Makes sense
  Rossen: Any additional feedback before resolve to accept the edits?
  Rossen: Objections to accept the edits?

  RESOLVED: Accept the edits in https://github.com/w3c/csswg-drafts/issues/2905

  florian: Thank you

CSS Inline

A question for the procedure to compute the used value of
  github: https://github.com/w3c/csswg-drafts/issues/3749

  dbaron: Isn't this talking about value for gCS which is another term?
  florian: Resolved value, you're right

  florian: This is raised by chromium because cssom spec says resolved
           value is used value and they were trying to find a way to
           return number of pixels but line-height:normal doesn't
           resolve into a single height
  florian: line-height has 2 sets of values. All values other than
           normal resolve to a single height, normal resolves in
           different value per text run. You ask for gCS for element,
           not for text run so we can't return
  dbaron: Chromium returns normal as a keyword?
  florian: Yes

  nigel: Reviewed this and was confused by spec with resolved value
         because line-height just takes you to css2 line height and
         doesn't way what resolved value is for line-height. Doesn't
         seem spec says what it should be
  florian: Kind of does depending on how you read it. For line-height
           it's in the sublist where it says resolved value is used
           value. It's unclear for line-height:normal that can be
  nigel: I think you're explaining how to read the sublists. That
         probably needs reformatting. Thank you

  florian: line-height:normal can only be preserved as normal if we
           want something meaningful
  nigel: You want to move line-height to computed value category?
  florian: Not necessarily. There is another subgrouping of values for
           line-height: length and percent are turned into absolute
           values at computed but numbers are numbers and computed. At
           used numbers become lengths. Do same thing but inherit
  florian: Normal, regardless of computed or used time can't become a
           single number.
  AmeliaBR: Are you asking us to say normal exists at used value time
            or are you asking to create a special category to figure
            out resolve value for line-height being normal if computed
            value is normal?
  florian: I think difference between those 2 is editorial because
           used can't be observed unless we say gCS returns it. In
           terms of what's observable it's same. I don't care how we
           phrase, just don't turn normal into a number
  nigel: Happy to have a unitless number for line-height converted to
         a used value?
  florian: Unitless stay as unitless at computed. At used value I
           suppose it's categorized that way because web compat
           requires it. That's usually why properties whose resolved
           is mapped to used value instead of computed mapping. I'm
           not trying to change values other than normal, want to
           avoid normal being cast to a length when it can't be

  florian: Who is CSSOM editor?
  florian: Emilio
  Rossen: Right
  Rossen: You can make a PR and emilio can merge
  florian: Happy with a resolution we keep normal and work with emilio
           on phrasing

  nigel: You talked about what is returned when it's normal. Do we
         have data on UAs for unitless numbers?
  florian: I have not looked. I assumed spec wasn't wrong, but can
           look separately.
  AmeliaBR: Working on a test case. Chrome does what florian is asking
  <AmeliaBR> Test case: https://codepen.io/AmeliaBR/pen/bZmgqJ?editors=1011

  myles: We're talking about return on gCS?
  florian: Yes
  myles: That's scary, line-height has been around forever
  florian: Changing spec to match chrome
  myles: FF and webkit return pixel value
  florian: Can you define what value you return?
  myles: This issue has a snippit of code that describes how we compute
  florian: [looks at it]
  florian: I'm not terrified about web compat given chrome does it
  myles: On the other hand FF and webkit don't return keyword
  florian: You think this is kind of code websites could have
           specialized on to deal with browser difference?
  Rossen: I think the assertion made was line-height has been there
          forever and many sites depend on it. Predicting what will be
          broken or not is difficult. I agree Chrome market share
          probably dictates some behavior on desktop, but not sure on
  florian: I wouldn't say chrome dictates behavior, but chrome doing
           it this way is strong evidence that doing it this was
           doesn't break the web
  florian: And length value you would return doesn't match layout so
           why return that?
  fantasai: Also computed value is the normal keyword. We use used
            value where there's a compat reason to do so
  myles: I won't object but we wouldn't be able to make this change
         without more research into how this would break
  Rossen: Can always defer to next week if you want to get some time
          and come back to use myles

  florian: I guess...the question is what's alternative? Spec being
           wrong is bad. Chrome returning a length that's unrelated to
           actually used length seems weird
  AmeliaBR: Is it really wrong? It's based on font of element. The
            text spans inside might have different fonts but doesn't
            the parent element have a line height even if it's not
            used for anything?
  <fantasai> AmeliaBR, the line height for normal is calculated per
             fragment, not per element
  florian: From the code snippit I don't know which font metrics we're
           talking about
  myles: Primary
  florian: Which metric of that font?
  myles: Ascent+descent+line gap
  florian: I'm not good enough at fonts to phase this, but I believe
           in the past we discussed there isn't a single ascent or
           descent and the one we use aren't always the same
  myles: For a particular font there are different values, but every
         browser picks one and uses it throughout. At least for the
         browsers I know
  florian: You return line height of the strut?
  myles: I don't know the term strut
  florian: Strut is the css2.1 term for the thing that keeps the line
           height from collapsing to 0
  myles: Sounds right to me

  fantasai: Line height used value is calculated per fragment of
            element so it's not necessarily the line height from first
            available font. Can also include fallback
  myles: Correct, also includes things like child elements
  fantasai: That's about height on line-box. There's difference
            between line-box and fragment we're looking at. For an
            element when calc line-height which is what's used when
            calc height of linebox in most cases it's definite nmber,
            but varies by fragment with normal
  fantasai: The position of that length on the line is used in
            combination with other elements on the line to get the
            line box. We're trying to calc the line-height value that
            factors into line box calc and that varies by fragment if
            you have normal. You can't get that answer w/o doing layout
  florian: I guess this boils down to that number from webkit isn't
           entirely meaningless, but if we're saying this is the used
           value it actually isn't
  fantasai: Example: have line-height:normal and all text is using
            second font in list that's what would set the line height,
            but you'd return the first font. Given the intention of
            gCS is reach the computed value and we don't have a web
            compat reason to not it seems to me returning normal makes
            a lot of sense.

  Rossen: We're at the top of the hour. I don't want to force a
          resolution. What's captured is compelling enough for WK and
          FF team to noodle on this for a week and we'll put it in
          next week's agenda.
  <dbaron> I think there's value in allowing the discussion to proceed
           a little further in the issue before bringing it to the
           call; might be more likely to take less than 20 minutes.
  florian: Sounds reasonable.

Received on Wednesday, 20 March 2019 19:18:23 UTC