[CSSWG] Minutes Virtual TPAC Meeting 2021-11-03 Part I [css-variables] [css-env] [css-writing-modes] [shadow-parts] [css-nesting] [css-masking] [media-queries [css-lists]

  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 Variables

  - RESOLVED: Publish an updated CR draft of css-variables (Issue
              #6783: Publishing css-variables)

CSS Environment Variables

  - heycam will create a list of all remaining env variables that need
      to be added to the spec so they can be resolved on and the FPWD
      can be published. (Issue #6729: Publish css environment variables

CSS Writing Modes & Shadow Parts

  - RESOLVED: Accept fantasai's proposal (
https://github.com/whatwg/html/issues/3699#issuecomment-951423468 ),
              get it written into spec, have tests updated to match
              (Issue #6609: Directionality inheritance into Shadow DOM)

CSS Nesting

  - RESOLVED: Change nesting draft to use open/close brackets, and add
              a note to show that syntax vs. what Tab would prefer
              (Issue #4748: Syntax suggestion)
  - RESOLVED: Our preference is for a single syntax for nesting (Issue
  - RESOLVED: Don't have nesting om using its own interface; instead,
              just allow style rule to contain a list of style rule
              (Issue #4748)

CSS Masking

  - RESOLVED: SVG clip-path bounding box units refer to CSS border-box
              of element to which applied (Issue #5786: "object
              bounding box" needs to be better defined for CSS boxes)
  - The spec editors were given an action to audit the spec for other
      ambiguities similar to the object bounding box one.
  - RESOLVED: clip-path and masking should follow same rules as
              backgrounds with regards to box-decoration-break (Issue
              #6383: Not clear how clip-path applies to fragmented

Media Queries 5

  - RESOLVED: Take all the "don't implement this" notes out of MQ 5
              (Issue #4834: Note/Issue on not shipping early proposals)
  - A note will be added to the video-* media queries to state that
      what is in the spec is likely wrong, but the group hasn't figured
      out the right approach yet.

CSS Lists

  - RESOLVED: Skip 0 increments when determining the starting value of
              a reverse counter (Issue #6738: Automatic start value of
              reversed list is affected by 'counter-increment:
              <counter> 0' nodes)


Agenda: https://github.com/w3c/csswg-drafts/projects/25

  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Oriol Brufau
  Daniel Clark
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Ian Kilpatrick
  Vladimir Levin
  Peter Linss
  Alison Maher
  Cameron McCormack
  Eric Meyer
  Tess O'Connor
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

Scribe: dholbert

CSS Variables

Publishing css-variables
  github: https://github.com/w3c/csswg-drafts/issues/6783

  TabAtkins: As Chris said, we already have a pretty good test suite
             for variables
  TabAtkins: I think changes list is reasonably up to date. If not all
             there, mostly-there
  TabAtkins: Got it mostly ready a couple months ago. Let's take it
             over the finish line

  astearns: proposed resolution: publish an updated CR draft of

  RESOLVED: Publish an updated CR draft of css-variables

CSS Environment Variables
  scribe: fantasai

Publish css environment variables fpwd
  github: https://github.com/w3c/csswg-drafts/issues/6729

  TabAtkins: As noted in the issue, the only real problem is that apple
             has a whole bunch of env variables that have yet to be
             submitted to spec
  TabAtkins: Don't want to publish fpwd without knowledge of all the
             variables that exist in the wild
  TabAtkins: both from a usability and a patent perspective
  astearns: Looked like 4 additional environment variables not in the
  TabAtkins: More than 4
  TabAtkins: Don't remember precise list...

  TabAtkins: Are we looking for a list to resolve on?
  astearns: Want to know scope of work to do to FPWD
  TabAtkins: Get that list in the spec, and have WG approve the list
  astearns: Anyone from Apple know whether list of shipping env
            variables are things that should go into the spec?
  heycam: Didn't look at the spec, so unsure how it matches WebKit
  heycam: but happy to take an action item to look into it

  ACTION heycam: Come up with list of WebKit environment variables for

  astearns: Open separate issue for adding the environment variables,

CSS Writing Modes & Shadow Parts
  scribe: dholbert

Directionality inheritance into Shadow DOM
  github: https://github.com/w3c/csswg-drafts/issues/6609

  emeyer: What the WG needs to do is look at the concrete proposal that
          fantasai put in the whatwg thread
  emeyer: and resolve whether that's how directionality and shadow dom
          interact with each other
  emeyer: It's fantastically clear, fantasai ++
  emeyer: whatwg wants to know how csswg thinks they should interact
  emeyer: fantasai has a proposal, we need to decide if that's what we
          want to sign on to
  <astearns> proposal:
  <florian> seems right to me, and I fully trust fantasai to get this

  TabAtkins: I have given this a read over, it's a slightly more
             detailed version of what I wanted to propose. Agree 100%
             with fantasai's proposal
  astearns: How does this proposal match existing tests
  emeyer: It may not; but existing tests were created based on the
          conversation in this thread. Need to update tests to match
          our resolution
  emeyer: I'll have some tests I need to change, not a problem
  astearns: Only problem could be if updated tests show browsers are
            failing in ways that keep them from being able to implement
            the proposal
  fantasai: They are currently failing to match the proposal; that's
            been known. Current behavior in browsers is not what we want

  astearns: We have looks like 3 reviews of the proposal which are
            thumbs up
  astearns: Proposed resolution is to accept fantasai's proposal, get
            it written into spec, have tests updated to match
  astearns: Objections?

  RESOLVED: Accept fantasai's proposal, get it written into spec, have
            tests updated to match

  astearns: Who is going to do spec edits?
  fantasai: It's a shadow dom spec issue, outside the scope of the csswg
  fantasai: Nothing we need to update in our own specs

CSS Nesting

Syntax suggestion
  github: https://github.com/w3c/csswg-drafts/issues/4748

  TabAtkins: I'll give initial presentation, and then others can argue
             for their preferences
  TabAtkins: leaverou and fantasai have some concerns about the
             currently-proposed syntax, particularly that it has two
  TabAtkins: The way it's written now, you can nest a style rule inside
             of another style rule
  TabAtkins: you need to use ampersand
  TabAtkins: Alternately, if you want it somewhere other than at the
             start, you use the @nest syntax
  TabAtkins: Two suggestions in the thread. one: always require
             wrapping set of curly braces, to syntactically distinguish
             rules from properties
  TabAtkins: few other variants on that
  <fantasai> see Miriam's comment at
  TabAtkins: I objected, don't like it; it means any nested style rule
             ends up being indented two levels from its parent
  TabAtkins: Any non-trivial amount of nesting really blows out your
             margin, gets far over in your code editor
  TabAtkins: What I settled on at the end is just to always require an
             @nest rule. Throw away completely unlabeled rule, always
             use @nest
  TabAtkins: Possibly be able to have @nest without a selector and nest
             style rules inside of that
  TabAtkins: Not sure I like that part, OM will get a little messy,
             similar to how layer has two representations for same rule
  TabAtkins: My initial proposal is that you remove the direct nesting
             and always make you use @nest rule

  fantasai: I think that I'd like to pick a syntax that's consistent,
            so there aren't multiple variations that are different.
            That's confusing
  fantasai: We should pick a syntax that's not noisy, since this is
            going to be used all over the place. This is a structural
            thing, and basic; I expect to see this a lot in the future
  fantasai: I don't have a problem with the extra indentation; that's
            an argument for not using very large indents, basically
  fantasai: leaverou raised some issues about how you'd handle the
            nested version of [...] mixed with selector lists, which is
  <TabAtkins> Lea's comment:
  fantasai: I think the curly-brace syntax is fine, I understand you
            don't like it, want to hear from other people

  astearns: I'm not a big fan of the pure-symbol syntax, whether it's
            braces or ampersand. More difficult to notice, search for
  astearns: If everything required @nest, that seems easier to read, if
            slightly more difficult to type
  fantasai: You have to balance that against how basic is the syntax &
            how often it will be used
  fantasai: e.g. we don't have @Style for style rules; we just have
  fantasai: We don't write begin/end; CSS syntax is built out of these
  fantasai: We have other selectors like @font-face which aren't used
            all the time, so they have to be clear
  fantasai: Nesting syntax is closer to the former case, so most
            stylesheets will have a lot of it. So we don't need to have
            a keyword to make it searchable; it'll just be an obvious
            way to structure your CSS
  fantasai: People have been using nested selectors in preprocessors
            without any kind of keyword
  fantasai: Maybe we end up with a keyword, but I don't know that we
            need to
  fantasai: Having it all over your stylesheet, in front of every
            single rule, would be terribly noisy. They're not important
  fantasai: The markup should fade into the background
  astearns: Is that an argument for only doing open/closing braces?
  fantasai: If we're insisting on a keyword, we could do @nest with
            braces. If we have it in front of every selector, that
            would be noisy
  fantasai: If we're going to have curly braces, you might as well just
            put them there. don't need a keyword
  fantasai: As long as we're not requiring it in front of everything,
            it's less of an issue
  <TabAtkins> https://www.irccloud.com/pastebin/HyBOx2gA/

  miriam: Not surprisingly, I agree with fantasai
  miriam: I like how clean and simple and unrepetitive it is
  astearns: Do you always get extra indentation, or is it possible to
            have a bare selector and then its decl block indented once?
  fantasai: It's up to your own indentation file & how you organize
            your code
  fantasai: The idea is, inside a selector, you put open and close
            curly braces in the same spot where you would put a
  fantasai: and that indicates you're going to put some style rules
  <TabAtkins> https://www.irccloud.com/pastebin/nakoTt1z/
  fantasai: and that's important for selector parsing [...]
  <miriam> the proposal we made in this comment:
  fantasai: At the top of the issue, there was a suggestion to use
            parenthesis, which is roughly what we're proposing here,
            except using curly braces
  fantasai: If you're not mixing declarations and style rules in the
            same selector block, you can just double-up your curly
            braces and indent one level
  fantasai: and that's pretty reasonable, but if you're mixing, you
            probably want to indent two levels for the case where
            you're including a selector
  <TabAtkins> (I find all the ways to avoid extra indents being easy to
              mess up, especially when editing later.)

  astearns: So we have two competing ideas
  astearns: I like the idea of having a single syntax, not an at-rule
            vs ampersand depending on syntax
  astearns: Sounds like either we use at-rule everywhere or open/close
            braces everywhere
  astearns: Not hearing consensus, I'm hearing "I could live with"
  TabAtkins: I really really don't like the double-indent
  TabAtkins: people can't easily adjust indentation files without
             messing with other code
  TabAtkins: [...]
  astearns: One argument for the bracketed version: it's easy to see
            what's being declared at each level of indentation
  astearns: You can read down a column and it's all the same sort of
            thing at a given level of indentation
  fantasai: If we don't just do curly-braces, you'll need to prefix
            every single selector with something
  fantasai: Don't want that to be @nest; that's too noisy
  fantasai: single symbol is not so bad, but then selector prelude in
            unnested style rules will be different from nested style
            rules which is also not great
  fantasai: nesting another block in there is the right way to go
  <florian> I'm mildly in favor of the braced syntax, but I don't feel
            terribly strongly either way

  heycam: Agree with fantasai
  heycam: Indentation is least important consideration of the things
          we're considering
  heycam: We often add @media or @supports rules and don't worry about
          additional indentation there
  heycam: I agree @nest syntax looks pretty noisy
  TabAtkins: @media usually isn't nested
  TabAtkins: I'm not worried about one level of indentation, but rather
             3 levels
  TabAtkins: That's enough to trigger lint warnings in many systems

  astearns: I have a terrible idea
  astearns: each nested selector could start with three colons
  astearns: we've only used 2 so far!
  astearns: [sarcasm, I think :D ]

  astearns: Anyone who wants to publicly argue against bracket syntax?
            (aside from TabAtkins )
  astearns: small number of folks on call, but let's try a small straw
  <miriam> {}
  <TabAtkins> @nest
  <smfr> {}
  <fantasai> {}
  <astearns> {}
  <florian> {}
  <vmpstr> {}
  <heycam> {}
  <hober> {}
  <dholbert> {}
  astearns: Are you ok with brackets, TabAtkins ?
  TabAtkins: I really want to show a normal stylesheet and how hugely
             indented it gets
  TabAtkins: Happy to take a provisional resolution for now

  astearns: What does SASS use?
  TabAtkins: Nothing, you just directly nest them in. Three deep =
             three indents
  astearns: And that's not possible for us?
  TabAtkins: There are certain selectors you can construct that look
             like property declarations
  TabAtkins: Requires too much lookahead for UAs to implement that
  <emeyer> +1 to seeing side by side code examples
  astearns: Should be a note in the spec
  astearns: proposed resolution: change nesting draft to use open/close
            brackets, and add a note to show that syntax vs. what Tab
            would prefer

  RESOLVED: Change nesting draft to use open/close brackets, and add a
            note to show that syntax vs. what Tab would prefer

  fantasai: We also should resolve to have a single syntax for nesting

  RESOLVED: Our preference is for a single syntax for nesting

  TabAtkins: One final question in this: right now, the spec defines
             the nested style rules to use a different OM class. the
             css nesting rule interface
  TabAtkins: If we're using a single syntax, then I don't think that
             makes a lot of sense?
  TabAtkins: They are in every possible way equivalent to a style rule
  TabAtkins: So my proposal is to just switch to use the existing CSS
             Style Rule interface in CSSOM
  astearns: So the only change is to change CSSOM to allow style rule
            to contain a list of style rules
  astearns: Proposed resolution: not have nesting om using its own
            interface; instead, just allow style rule to contain a list
            of style rules

  RESOLVED: Don't have nesting om using its own interface; instead,
            just allow style rule to contain a list of style rule

CSS Masking
  scribe: fantasai
  scribe's scribe: TabAtkins

"object bounding box" needs to be better defined for CSS boxes
  github: https://github.com/w3c/csswg-drafts/issues/5786

  astearns: Conclusion from IRC conversation?
  chrishtr: Chrome uses just the border box of the element only
  chrishtr: Firefox includes descendants
  chrishtr: So Chrome seems to implement what we want, which is to use
            border box and not bounding box of descendants
  smfr: This resolution would affect Gecko; WebKit already matches
  dholbert: Unsure what we're doing exactly, but proposal sounds pretty
  astearns: So proposed resolution is to use the border-box for masking
            in SVG?

  fantasai: Is this changing the interpretation of the fill-box
            keyword? Or just the interpretation of what we do by
            default, and in what properties?
  chrishtr: I think it's changing interpretation of "object bounding
            box" for clip-path
  <chrishtr> clipPathUnits="objectBoundingBox"
  astearns: Is there a way to change to use something other than object
            bounding box?
  astearns: Is that only the default behavior or ...?
  smfr: fantasai's point is valid, we need to resolve ambiguities
        between when object bounding box is applied to CSS
  smfr: Problem with fill-box and border-box being different
  chrishtr: Can specify various boxes
  iank: Also bug/ambiguity, when fragmented
  iank: Need to clarify applying to each fragment independently

  astearns: Proposed resolution as stated is not everything we need to
  fantasai: I think the fill-box keyword is mapped to the object
            bounding box, and also to the content box
  fantasai: So does that change, when fill-box is specified explicitly?
  fantasai: If it does get redefined, do we do so only for clip-path or
            for all places?
  fantasai: So we need to dig in and see if we were only affecting
            clip-path:<initial-value>, clip-path:fill-box, or
  heycam: For clip-path object bounding box, no way to switch to
          another box
  heycam: so if we are changing definition of 'fill-box', would need to
          consider in other contexts
  heycam: but at the moment, I don't think there's a way to explicitly
          select any of the other boxes
  astearns: There is in CSS, but maybe not in SVG
  heycam: I don't think those would affect how SVG clip path would be

  astearns: Do we have a simple resolution and then action to audit?
  chrishtr: Let's resolve, and then ask editors to audit and come back
            to group
  astearns: sgtm
  astearns: What's the proposed resolution?
  chrishtr: If you set 'clip-path' to use object bounding box units in
            an SVG-based clip-path, it refers to bounding box of the
            element to which clip is applied
  * fantasai assumes = border box in CSS?
  chrishtr: border box
  proposed resolution: SVG clip-path bounding box units refer to CSS
      border-box of element to which applied

  RESOLVED: SVG clip-path bounding box units refer to CSS border-box of
            element to which applied

  ACTION: Editors to check if any other related ambiguities

Not clear how clip-path applies to fragmented elements
  github: https://github.com/w3c/csswg-drafts/issues/6383
  scribe: dael

  heycam: There's nothing in the css masking spec that says how
          clippath interacts with box decoration
  heycam: Slight reference to break in section for mask image that
          implies it applies to masks on fragmented elements
  heycam: Did some testing with clip-path and found safari, firefox,
          and chrome different
  heycam: What I would expect is similar to what happens to borders
          where if you have background-decoration break slice you would
          slice up the clip and apply with different offsets
  heycam: break then evaluate size and position differently for each
  <fantasai> +1 to honoring box-decoration-break as heycam described
  heycam: FF and Chrome similar in that they apply the clip-path
          computed based on one fragment, but using different elements.
          Webkit computes bounding box of all and evaluate clip-path.
  heycam: I think none are exactly what we want
  heycam: Wanted to see if you think it's reasonable or if clip-paths
          are different enough

  fantasai: Agree with matching to way backgrounds and borders are
            handled. Makes a lot of sense
  astearns: Seeing head nodding
  florian: Agree. If in long run need to distinguish we could add
  iank: Note that you don't need fragmentation to trigger. Inline like
        a span with a clip-path triggers this
  fantasai: That's still fragmentation.
  iank: Sure
  astearns: Hearing consensus. Anyone against?

  chrishtr: iank do you have believe if this has impact on
            fragmentation in [missed] architecture?
  heycam: Basically behavior is same as box-decoration break. If you
          have box-decoration-break slice you compute box for
          unfragmented thing and slice clip-path and apply separately
  iank: What happens if you have a fragment that is varying
        width...this is the problem in...case is inline when you have a
        fragmented span. span can have different heights. What happens
  heycam: What happens with backgrounds?
  fantasai: Spans don't have different heights on different lines
            because set by first available font
  fantasai: As far as backgrounds and block level fragmentation it's
            defined in break. You recalc your size on each fragment.
            Maintain a concept of progress through element
  <fantasai> https://www.w3.org/TR/css-break-3/#varying-size-boxes
  astearns: Background is sliced...compute for unfragmented and then
            you slice it up. First fragment ends up shorter does the
            background resize per fragment after slicing?
  fantasai: For slicing you do layout first. Then you assemble it.
            You've accounted for the spacing. You have an oval
            clip-rect. You do the fragmentation, layout, and then draw
            background around that
  fantasai: It's not that you  layout as if there was no fragmentation.
            That would be different spacing

  chrishtr: Does the same problem, heycam, apply to other visual
            effects? masking, filters, and so on?
  heycam: Masking and clipping seem they should do the same. Filters I
          had not considered
  heycam: Gut feeling is that filters feel a little more different and
          it's not so obvious we should apply same rules. Maybe not the
  chrishtr: alisonmaher, thoughts?
  alisonmaher: I didn't work too much with this part of fragmentation.
               Keeping consistent feels like it would make sense

  astearns: Sounds like there are some complications to work out.
  astearns: General consensus that masking should follow same as
            backgrounds with regards to box-decoration-break
  astearns: Anyone objections to trying this out?

  RESOLVED: masking should follow same rules as backgrounds with
            regards to box-decoration-break

  astearns: Definitely clip-path. Masking should be the same

  RESOLVED: clip-path and masking should follow same rules as
            backgrounds with regards to box-decoration-break

  astearns: We can think on filters separately. Might be better to try
            and reason for clip-path and see if it would work first

Media Queries 5

Note/Issue on not shipping early proposals
  github: https://github.com/w3c/csswg-drafts/issues/4834

  fantasai: MQ 5 is peppered with this is not ready to impl but it's
            shipping. We shouldn't have notes saying don't do this when
            everyone is doing it. We shouldn't do that because makes it
            more likely people will ignore the notes
  astearns: Proposal: Take off all the notes?
  fantasai: That's my starting proposal.
  fantasai: If there's anything not shipping we can argue to have it
  astearns: Anyone argue for notes to keep?
  astearns: If there are any we should have that people not on the call
            want we can add
  astearns: Proposed: Take all the don't implement this notes out of
            MQ 5
  astearns: Objections?

  RESOLVED: Take all the don't implement this notes out of MQ 5

CSS Lists

Automatic start value of reversed list is affected by
    'counter-increment: <counter> 0' nodes
  github: https://github.com/w3c/csswg-drafts/issues/6738

  TabAtkins: This is...set up is weird
  TabAtkins: Some time ago we told html it was okay to style the
             disclosure triangle on a details using list item. That way
             they can use marker pseudo
  TabAtkins: The definition in html spec says it's a display list item.
             because it auto increments the counter it also says
             counter-increment list-item 0.
  TabAtkins: This means a page with a whole lot of summaries they're
             incrementing an unnamed counter
  TabAtkins: Came up here with a reversed item counter. Question was
             what value to start at and there was performance issue in
             FF with an element named summary and there was a hang
  TabAtkins: The question was how we could make this work better. Only
             reason summary interacts with list-item counter is
             anything with display: list-item must interact
  TabAtkins: The way algorithm was written to calculate the starting
             counter value for reversed list counts the 0 increments.
  TabAtkins: Mats suggests we skip those because it would avoid weird
             performance and if you are ever explicitly 0 increment a
             counter you must set as 0 so if you do it you are probably
             indicating the is not something that should interact
  TabAtkins: He concludes best to have 0 counters not count. I suggest
             we adopt this. For purpose of list skip 0 increment when
             calc starting increment
  TabAtkins: oriol has some comments this is a little weird but once
             Mats pointed out perf issue we thought it wasn't a big deal
  TabAtkins: So we're fine with the change. Unless anyone has an
             argument they should count we'll accept that

  astearns: Opinions?
  astearns: If Mats and oriol agree I'm inclined to agree too
  astearns: Prop: Do what Mats says? Or summary?
  TabAtkins: Skip 0 increments when determining the starting value of a
             reverse counter
  astearns: Objections?

  RESOLVED: Skip 0 increments when determining the starting value of a
            reverse counter

  TabAtkins: Pointing out, Mats pointed out it's weird we told HTML
             list it's okay to use display list-item here. He would
             have preferred to use marker without making it a
             list-item. Separate issue linked to be able to do that.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6781
  TabAtkins: If you have interest in that, reference that issue
  oriol: Another note, when discussing this I found other issues in the
         algo. I can file them as different issues since they're
  astearns: Yes, please do that

Media Queries 5

Note/Issue on not shipping early proposals
  github: https://github.com/w3c/csswg-drafts/issues/4834

  florian: As far as I'm aware the video-* MQ are not implemented and
           they do have an existential issue so maybe warning should
           stay there. Unless they are shipping? I think the warning is
  astearns: Yes and no. Have other things in other specs with issues
  florian: This is a it may be completely wrong issue. If it's
           shipping, fine, but if it's not shipping
  astearns: I'm inclined to not put the warning in so we could get
            implementation experience. If resolution of issue is this
            was bad people can take it out. That's the risk of impl
            something in a spec not in CR
  florian: Useful to highlight we don't know what's right but think
           this is wrong
  fantasai: I think that's fine. But also if someone is shipping
            something with the warning people should talk to the WG
            before shipping, shouldn't just leave the spec and impl
  astearns: I think it makes sense to have a note in the spec saying we
            have an issue and this may change
  florian: Okay. I'll take that into account

Received on Sunday, 7 November 2021 22:08:52 UTC