- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 7 Nov 2021 17:08:08 -0500
- 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 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
fpwd)
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
#4748)
- 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
elements)
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)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/25
Present:
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
css-variables
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
spec?
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
standardization
astearns: Open separate issue for adding the environment variables,
please
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:
https://github.com/whatwg/html/issues/3699#issuecomment-951423468
<florian> seems right to me, and I fully trust fantasai to get this
right
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
variants
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
https://github.com//issues/4748#issuecomment-924118287
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
name
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
awkward
<TabAtkins> Lea's comment:
https://github.com//issues/4748#issuecomment-940160175
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
selectors
fantasai: We don't write begin/end; CSS syntax is built out of these
symbols
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
declaration
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:
https://github.com//issues/4748#issuecomment-924118287
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
poll
<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
reasonable
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
fix?
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
<any-property>:fill-box
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
positioned
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
fragment
<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
longhands
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
there?
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
case
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
orthogonal.
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
right
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
disagreeing
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