[CSSWG] Minutes Telecon 2018-08-01 [css-inline] [css-text] [css-fonts-4] [css-scroll-snap] [css-grid] [css-contain]

  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 Inline

  - RESOLVED: Close this issue (#2926: Should dominant-baseline
              inherit?) with no change to CSS Inline
  - A new issue will be opened to determine how dominant-baseline
      should behave in the presence of a writing mode change and if
      there are other similar switches that may need to be examined.
  - RESOLVED: Publish updated WD of css-inline-3

CSS Text

  - RESOLVED: Try a new rule in UA stylesheet and see how it impacts
              rate of bugs for FF then come back to this (Issue #2951:
              Having overflow-wrap: break-word affect min-content size
              is not webcompatible)

CSS Fonts

  - RESOLVED: Have 'auto' follow platform conventions and add a new
              value called 'unicode' to follow unicode conventions [
              for font-variant-emoji] (Issue #1223)
  - RESOLVED: Defer this issue (Issue #1289: Problem setting up a
              "4-style family" with variable fonts) with issue #528
              from last week
  - RESOLVED: Add normative text describing this issue and being more
              clear about how this all works with an example for how
              things can go terribly wrong

CSS Scroll Snap

  - RESOLVED: Add an auto value as the initial value and for auto
              allow the agent to determine the padding size using a
              heuristic they want (Issue #2929)
  - Next week the group will resolve to republish CR once there is a
      DoC written and any test edits necessary are in.

Grid L2

  - RESOLVED: Accept the diff in the issue [to support automatic grid
              span for subgrids] (Issue #2565)
  - RESOLVED: Publish a new WD of Grid L2

CSS Contain

  - RESOLVED: Accept the PR that corrects this oversight [makes
              contain:layout establish a staking context] (Issue #2942)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jul/0041.html

  Rachel Andrew (IRC Only)
  Tab Atkins
  David Baron
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Chris Harrelson
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Cameron McCormack
  Xidorn Quan
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Eric Willigers
  Fuqiao Xue

  Angelo Cano
  Emilio Cobos Álvarez
  Tony Graham
  Vladimir Levantovsky
  Thierry Michel
  Geoffrey Sneddon
  Manuel Rego Casasnovas
  Sean Voisen
  Greg Whitworth

Scribe: dael

CSS Inline

Should dominant-baseline inherit?
  github: https://github.com/w3c/csswg-drafts/issues/2926

  fantasai: I don't remember if we resolved on this, but it's really
            the only reasonable thing. As spec in SVG this has an auto
            value that behaves like inherit but only on a text element.
  fantasai: Seems awk design that's a result of not thinking about
            inheritence. CSS inline L3 spec that dominant-baseline is
            inherited value
  fantasai: Wanted to ask for review and confirm
  chris: This isn't so much inheritence it was more that once you
         started a text run the font you set on that effected kinda
         like underline when it effects the children. But if you can
         make it work using inheritence that's fine, but that's why we
         did it originally

  fantasai: CSS modal I think we should use works that each element
            has a dominant-baseline property generally same as parent
            and that sets baseline to align own contents. When align
            to parent uses alignment baseline which is different
            property. I don't see need to inherit.
  <chris> ok, sounds good
  fantasai: If you want a baseline table that passes through changes
            in font size etc to descendants I can see case for more
            complex, but I don't think that's desired. I think you
            want a localized baseline grid and then that whole thing
            aligns to parent baseline table. Then you don't pass
            baseline through multiple elements
  chris: Fine to me.
  fantasai: Okay

  astearns: Any concern that 3 engines aren't making properties
  fantasai: In SVG context the inheritence will be arcane. I don't
            think most people will set on root SVG element. Once on
            text element it does inherit. I don't think anyone is
            changing OM value of dominant-baseline of a text element
            in SVG. In general case behavior is identical. Weird cases
            for a change and I don't expect them to be common
  fantasai: That's my expectation, could be wrong
  astearns: ericwilligers are you okay having dominant-baseline
  ericwilligers: Fine with it. It's what blink does. I can send a PR
                 for SVG spec to mention it's inherited.
  fantasai: Also need to change auto value so it doesn't pretend to

  astearns: Anything else on this?
  astearns: Prop: Close this issue with no change to CSS Inline
  astearns: Objections?

  myles: Reset what dominant-baseline is at writing mode change?
  fantasai: At writing mode change the dominant-baseline also changes.
  myles: Isn't that what auto means? If someone sets to another value
         you want to change at writing mode change
  fantasai: That is an interesting idea. Don't know that it's strictly
            necessary. I think you could argue you might want that to
            happen, but it depends on writing system.
  fantasai: If you have inline block with horizontal text you would
            want it not to have central baseline in a vertical document
  florian: Some kind of expanded version of dominant-baseline with two
  myles: No, not that. I think current behavior allows for this
  fantasai: Currently initial value is auto and doesn't resolve to
            anything. If you set to a different baseline it inherits
            through orthogonal flow. For default case, that's typical
            for Japanese or Chinese because it does the right thing
  myles: I'm not sure saying auto works correctly means property is
         correct. Maybe a new issue?
  astearns: I was thinking new issue, but now I'm thinking that if we
            do take from SVG that dominant doesn't inherit we can have
            auto do the right thing. We're taking on complexity of
            auto to solve a writing mode switch
  fantasai: But when you switch writing modes and you set something
            like mathematical baseline what do you expect at a writing
            mode change? If what you want is to have alphabetic in
            horizontal and central in vertical set to auto and it
            works. If you set to mathematical-baseline what do we
            propose to do other than mathematical. If it's the same as
            before the writing mode change that's inherit

  astearns: I suggest we define auto somewhat like SVG where auto
            takes dominant-baseline of parent unless writing mode
            change and if writing mode change auto takes standard
            baseline for writing mode
  myles: I was proposing something different. I was thinking that any
         value for dominant-baseline would apply to all descendants
         until a triggering condition makes it not apply
  fantasai: What does not apply mean?
  myles: On other side of trigger it resets to auto
  fantasai: I don't think that is necessarily what you want. I don't
            think it's worth the complexity to make this non-inherit.
            That would be confusing because auto would have to look
            deep in document trees if you set inside a root. You have
            to go up the tree every time.
  fantasai: And what would we gain? I don't think anything because I
            don't think switching is always the right call. When we
            want the writing mode to trigger a change in dominant is
            switch between alphabetic or central and auto will do the
            switch. Unless you set it to something else it will have
            that behavior. I don't think resetting it is necessarily
            the right answer
  fantasai: No one has given me a clear use case where writing modes
            should trigger a change in dominant-baseline except what's
            covered in auto. Unless there's another use case it's not
            worth doing.

  dbaron: Is normal for Hindi and other Indic languages that you'd
          want to set dominant-baseline to hanging?
  astearns: No because fonts don't support. Indic uses alphabetic
  myles: [missed] If you're using web fonts and you know it supports
         you should
  dbaron: If you're saying this works in auto and if for vertical
          Chinese in a Hindi doc it doesn't work then it doesn't.
  chris: To dbaron not all fonts support all baselines and it's more a
         case that an occasional one does support.

  chris: myles spoke about triggering conditions, which are other
         triggering conditions? If it's just that one perhaps the 2
         values florian suggested would be better?
  myles: I don't know on other triggering. I haven't done research.
         One property with 2 values seems a lot of added complexity.

  fantasai: dbaron your case when switching Indic to Chinese when you
            have a writing system change you want a baseline change.
            Horizontal Chinese in an Indic doc you'd want Chinese to
            have own dominant baseline. That's a writing system
            change, not a writing mode change. Writing mode isn't
            trigger you're looking for. Indic doc with hanging
            baseline and both horizontal and vertical text would you
            switch dominant-baseline for vertical Indic text would you
            switch? I don't think so.
  <dbaron> fantasai, that makes sense to me

  astearns: I haven't heard anything that makes me thing we would keep
            dominant-baseline from inheriting. I think we should open
            a new issue for these switches and what happens. Is
            everyone okay leaving this to another issue and close this
  myles: Fine
  astearns: Everyone was interested, but it would be good to have this
            as an issue.
  <fantasai> proposed resolution: No change to css-inline,
             dominant-baseline inherits and auto only switches between
             alphabetic/central (not synthesizing inheritance)
  florian: Fine. We can explore 2 value elsewhere
  astearns: Objections to Close this issue with no change to CSS

  RESOLVED: Close this issue with no change to CSS Inline

Publish updated WD of css-inline-3

  astearns: Sounds good. We should do it
  dauwhe: Approve
  astearns: Objections to Publish updated WD of css-inline-3

  RESOLVED: Publish updated WD of css-inline-3

CSS Text

Having overflow-wrap: break-word affect min-content size is not
  github: https://github.com/w3c/csswg-drafts/issues/2951

  xidorn: I put in the change to make overflow-wrap:break-word to
          affect min content. We immediately got 4 bugs. fantasai
          suggested we can make table reset the overflow-wrap to
          normal which fixes 2 of them.
  xidorn: I want to bring it to WG and see what we do next
  florian: What are remaining 2? PHP manual thing was one?
  florian: It looks like a strangely coded web page.
  florian: What's last?
  xidorn: I think fantasai and the [missed] said it was wrong use and
          we can ignore
  dbaron: We're talking about 4 bugs and it's on the nightly channel
  fantasai: I'm not sure what to do. I think alternatives are terrible
            but web compat is a problem
  myles: We don't have a choice. 4 bugs on a nightly. Web compat is
         more important
  florian: I suggest we try the UA stylesheet change and see. If the
           change on tables solves the general problem maybe we're
           back. If not we have to do something else
  frremy: My PoV I don't believe a quick change will fix. At MS we
          have other issues we're seeing where we'd like to reconsider
          word-break:break-word where we had websites change to
          break-all and Edge breaks in the middle. I know we supported
          not supporting it, but I'm becoming less convinced we can't.
          So supporting break-word is an option on the table. We
          should consider that as a part of this

  fantasai: We have someone from the PHP site engaging on issue.
            Example where table is not breaking, behavior they want
            ideally is that you have 2 types of min-content? They want
            table to wrap at normal word breaks but not in overflow
            wrap cases unless it's necessary. If you look at example
            there is text that could wrap more without breaking code
            words and they expect those breaks take priority.
  fantasai: Not sure where to go with that, but it occurred to me that
            we're not handling that type of prioritization correctly
            in general
  florian: So I felt we did find 4 bugs and if we fix UA we fix 2 and
           the other bugs were different

  dbaron: Does the fix break what the sites were intending?
  fantasai: Sites broken intended to not apply inside the table.
  dbaron: I think you need to be careful on intent. A lot of sites
          might have waned current behavior where it allows long
          content to break
  florian: Tables doesn't do that
  dbaron: Okay
  dbaron: because changes min-content
  florian: Right, so table won't shrink to where it could break
  fantasai: [sigh]

  florian: I'd like Mozilla to try the UA stylesheet fix and see where
           that gets us. Maybe not enough, but good to check.
  florian: If that doesn't break the web more it provides a clean path
           for new authors and maybe on top of that we still need
           word-break:break-word for frremy's reasons
  fantasai: Idea case maybe is that...One case was someone put content
            in a 0 width container and said I'd like you to
            word-break:break-word but shrink wrap took affect so it
            didn't. Other cases it seems there's multi levels of
            prioritization where we have 2 and authors would like 3.
            That's a big thing to think about.
  fantasai: Overflow-wrap breaks are de-prioritized in terms of when
            we accept the break. We're not able to de-prioritize in
            terms of min-content width.
  fantasai: For word-break:break-word it's awful ergonomics for CSS to
            add it. Authors are already confused on breaking prop and
            what called
  florian: That's why I think we should keep trying and maybe spec as
           a corner
  fantasai: If we have to revert this I'd prefer a keyword to
            overflow-wrap that's the same as break-word but also
            affects min-content like 'overflow-wrap-anywhere' that's
            the same as word-break:break-word but lets author consider
            like multiple properties. word-break:break-word and
            word-wrap:break-word can't be combined

  myles: Have we veered from original topic?
  fantasai: Going back to this one
  fantasai: I think it would be interesting to see if adding UA
            stylesheet rule would make it tolerably compat, but I'm
            not an impl so I'm not qualified to have an opinion for
            how that would be as an experiment.
  astearns: Given we don't have clear solution I think trying this in
            browser stylesheet and getting more data is reasonable
            next step
  florian: Might not be enough but good start
  astearns: xidorn and dbaron sound good to try?
  xidorn: I think we can try that. Easy enough to add it
  astearns: Objections to try a new rule in UA stylesheet and see how
            it impacts rate of bugs for FF?

  RESOLVED: Try a new rule in UA stylesheet and see how it impacts
            rate of bugs for FF then come back to this

CSS Fonts

font-variant-emoji property lacks an unopinionated, standardized
  github: https://github.com/w3c/csswg-drafts/issues/1223

  chris: Basically the thing with this is we describe auto which tries
         to do 2 things. User agents may follow unicode or ignore them
         and do what platform does. Seems like 2 use cases and you'll
         have UA and platform variations. Some people might want to
         say unicode is what we want, but you can't do that. You can
         say mostly I have text or mostly I have emoji. We lack a 4th
         value that says do what unicode does
  myles: I think the idea of a new value is fine. It's fairly
         important that our default matches platform so I agree can't
         be default, but a new value for follow unicode is fine
  chris: myles does that sound like it has impl complexity?
  myles: I don't think that much. Property has some complexity, but
         additional complexity isn't much bigger
  <chris> ok
  myles: Can't speak for other browsers
  <chris> other implementors?

  astearns: Do we also need a follow platform?
  myles: Isn't that what auto is?
  chris: At the moment auto isn't clear, but it I agree it should be
         do what the platform does. That's closest to current impl
  myles: Sounds good
  astearns: All engines or is there an engine that's been taking
            ambiguity in spec and it follows unicode
  myles: As far as I know there are 0 impl

  astearns: Proposal: Have auto follow platform conventions and add a
            new value to follow unicode conventions
  <chris> bikeshed the name?
  fantasai: Call it normal? The new one. Auto is more magic, normal is
            follow a convention. There's probably a better name
  myles: Unicode? Or resolve without name?
  chris: Let's not resolve unless we're stuck. I think unicode is
  astearns: Objections to unicode as the name?
  astearns: Proposal: Have auto follow platform conventions and add a
            new value called unicode to follow unicode conventions

  RESOLVED: Have 'auto' follow platform conventions and add a new
            value called 'unicode' to follow unicode conventions

Problem setting up a "4-style family" with variable fonts
  github: https://github.com/w3c/csswg-drafts/issues/1289

  florian: I think it's a duplicate of something we deferred last
           week. It was...
  chris: 528
  florian: Yes.
  astearns: Objections to deferring this with issue #528 from last

  RESOLVED: Defer this with issue #528 from last week

issues with font-family descriptor in @font-palette-values rule
  github: https://github.com/w3c/csswg-drafts/issues/1669

  chris: I think basic problem is spec says if you say font-family it
         will be unique IDed. Fine for fallback between different
         families. Composite font there is no guarantee there is the
         same palette with same palette values.
  myles: Proposal to solve? I think as-is is fine and authors should
         make composite fonts correctly.
  chris: Other cases where users can come up with their own values and
         map with @font-face, but that's a lot of complexity. Maybe
         allow it to be an @font-face and define it there...not sure.
         Worried about too complex
  myles: Agree. Worried about making this really complicated.
  myles: I think there are a couple different @rules that apply to a
         font-family by name. If this is a problem here it's for the
         other like font-feature-values
  chris: Yeah, exactly. That one too.
  myles: Another point, there can be different items in source list
         and you could want this specific to an item in the source
         list, but that's crazy. This is finding the right line in the
  chris: If you do silly things you get strange results.
  myles: That's my thought

  astearns: Proposal is to close this no change?
  myles: I could add normative text
  myles: that makes it clear each of these are applied to each
         @font-face that share a family name. There's 2 parts to this
         issue and part 1 is 'I'm confused' part 2 is 'is this
         valuable'. Part 2 we said no so let's describe
  astearns: An example of how things can go wrong would be good.
  myles: Sure.
  astearns: Proposal: Add normative text describing this issue and
            being more clear about how this all works with an example
            for how things can go terribly wrong
  <fantasai> sgtm
  astearns: Objections?

  RESOLVED: Add normative text describing this issue and being more
            clear about how this all works with an example for how
            things can go terribly wrong

CSS Scroll Snap

Different browsers implement keypress scrolling differently
  github: https://github.com/w3c/csswg-drafts/issues/2929

  TabAtkins: Right now scroll-padding initial is 0 indicating no
             special padding is applied. FF has heuristics where it
             tries to detect like a fixed header and subtracts that
             from its page scrolling operations. Suggested we should
             allow those and then adjust initial value to reflect that
             initial scroll padding may be impacted so change initial
             to auto
  fantasai: So set to 0 or anything else browser heuristics are set
            off as opposed to having heuristics + your padding which
            is not what wanted.
  florian: sgtm
  TabAtkins: Majid our implementor is fine, suggested by FF, so 2
             browsers say cool
  myles: Proposal is add an auto value?
  TabAtkins: Add an auto value, make it initial, and define as roughly
             0 but browser may impose heuristics with a description of
             sort of heuristics
  myles: Sounds great. Def do that
  fantasai: 100% to do this

  florian: Revisit in a few years
  myles: Not spec exact heuristics
  florian: Yes, if converge then standardize

  astearns: Proposal: add an auto value as the initial value and for
            auto allow the agent to determine the padding size using a
            heuristic they want
  astearns: Objections?

  RESOLVED: Add an auto value as the initial value and for auto allow
            the agent to determine the padding size using a heuristic
            they want


  fantasai: Approval to update CR one edits in?
  astearns: I expect tests need updating that are checking initial
  florian: Don't know if we have much test suite
  fantasai: Majid would have those tests

  astearns: No other scroll-snap issues?
  fantasai: One deferred, one close no fix, another was unclear as to
            if a feature request. There has been no response to my
            clarification question for months.

  astearns: DoC ready?
  fantasai: No, but can make one quick.

  astearns: Let's ask Majid about tests, someone does DoC and we
            resolve to update next week
  fantasai: Sounds good

Grid L2

support automatic grid span for subgrids?
  github: https://github.com/w3c/csswg-drafts/issues/2565

  fantasai: Suggestion was we used to have ability to have automatic
            grid span. In grid L1 that resolves to span is 1. When you
            have subgrid you can say it should resolve to number of
            tracks in subgrid. Mats suggested we do that. Do we want
  TabAtkins: I think it's a nice feature. You expressed span in
             subgrid so seems reasonable
  <florian> seems pretty reasonable. And there isn't really any other
            useful thing we should do. So yes
  astearns: Seems okay to me
  astearns: Anyone against?

  astearns: Proposal: Accept the diff in the issue
  astearns: Objections?

  RESOLVED: Accept the diff in the issue


  astearns: Objections to a new WD of Grid L2?
  <chris> +1 to grid 2 wd

  RESOLVED: Publish a new WD of Grid L2

CSS Contain

Is it ok that contain:layout is a CB for fixpos/abspos descendants but
    doesn't establish a stacking context?
  github: https://github.com/w3c/csswg-drafts/issues/2942

  florian: Contain:layout sets the element to be a containing block
           for lots of things, but didn't say it establishes stacking.
           This would be a first time we would have something like
           this that's not stacking, so let's do it as stacking.
  TabAtkins: And it wasn't intentional, accidental tying concepts and
             didn't realize.
  astearns: Not seeing objections in issue.
  astearns: Objections?

  RESOLVED: Accept the PR that corrects this oversight

  astearns: Talk to y'all next week!

Received on Thursday, 2 August 2018 01:26:52 UTC