- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 29 Oct 2022 18:38:01 -0400
- 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.
=========================================
Publications
------------
- RESOLVED: Advance css-box-3 to PR
- RESOLVED: Accept the above changes
Changes:
- Statement about font-relative lengths and text shaping:
https://github.com/w3c/csswg-drafts/commit/f69413e37d0fe066de4042a299c860e3e938e540
- Adding a definition of the device pixel:
https://github.com/w3c/csswg-drafts/commit/66178f3022fbc1d14c801bf296f25f47eab656fc
- RESOLVED: Publish updated CSS Values and Units L3 CR snapshot
- RESOLVED: Republish CRD of CSS Color 4
View Transitions
----------------
- RESOLVED: Use "snapshot viewport" for root element snapshot and UA
CSS to size and position ::page-transition at snapshot
viewport (Issue #7859: Define transitions over changing
viewport)
Nesting
-------
- RESOLVED: Allow relative selectors for both nesting and @scope
(Issue #7854: Allow relative selector syntax in @nest
rules)
- The group revisited the four proposals to address issue #7834
(Syntax Invites Errors) which are detailed here:
https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
- The original debate was between options 1 and 3 and in the last
conversation there was also discussion that option 4 may get
better results. Discussion first focused on option 1 vs 3.
- RESOLVED: We're taking option 3 over option 1 (Issue #7834)
- It was not clear if option 3 or 4 was better and more examples need
to be added as well as further developer engagement around this
pair of options.
- RESOLVED: Change the spec to reflect option 3 (Issue #7834)
- RESOLVED: Open issue for further discussion of 3 vs 4 (Issue #7834)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/34
Present:
Jake Archibald
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Daniel Holbert
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Chris Lilley
Peter Linss
Eric Meyer
Morgan Reschenberg
Khushal Sagar
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Rachel Andrew
Chair: Rossen
Scribe: emeyer
Publications
============
CSS Box 3
---------
fantasai: CSS-box-3 has been in CR for a while, everything in it is
defined in CSS2 and CSS writing modes L3
fantasai: Any objections?
<chris> +1
<lea> +1
RESOLVED: Advance css-box-3 to PR
Republish CSS Values and Units L3 CR
------------------------------------
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0033.html
<fantasai> https://drafts.csswg.org/css-values-3/#changes
fantasai: We made a bunch of updates to Values & Units, we did
publish level 4 as requested but level 3 needs a WG
resolution
<fantasai> https://github.com/w3c/csswg-drafts/commit/f69413e37d0fe066de4042a299c860e3e938e540
fantasai: First is an addition statement about font-relative lengths
and text shaping
<fantasai> ->
https://github.com/w3c/csswg-drafts/commit/66178f3022fbc1d14c801bf296f25f47eab656fc
fantasai: Second is adding a definition of the device pixel
fantasai: If the WG approves both changes, then we can approve
republishing a snapshot
Rossen: The first change you posted, for the font-relative lengths,
any opinions or objections?
(silence)
Rossen: Let's call the first change approved
Rossen: Second is the device pixel definition. Any opinion or
objections?
(silence redux)
Rossen: That is also approved
Rossen: Any objections to advancing to CR?
(silence retrois)
RESOLVED: Accept the above changes
RESOLVED: Publish updated CSS Values and Units L3 CR snapshot
CSS Color L4
------------
github: https://github.com/w3c/csswg-drafts/issues/6900
chris: There's been a bunch of updates since June, I'd like to keep
it up to date and publish current state
Rossen: As of this state, any feedback or reasons why we shouldn't
republish?
chris: Any objections?
RESOLVED: Republish CRD of CSS Color 4
CSS Nesting
===========
Discussion on option 4 of CSS nesting
-------------------------------------
github: https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
fremy: This proposal says there can be a group of rules, no need to
change parsers and it's easy for developer tools
fremy: You can have a selector, a declaration, then a group of rules
fremy: Why would we do this? Three main advantages:
fremy: 1. You can copy and paste without making changes
fremy: 2. This is parsing as it's done today
fremy: 3. This is exactly what CSSOM will do
fremy: Because there's nothing special, if you're writing normal CSS,
this is as easy as writing your first rule, and just have to
tab things over
fremy: This is exactly the same thing you do for @scope
fremy: With this proposal, because everything uses the same syntax,
you can reuse your CSS
fremy: It's CSS as you've always written it
fremy: You don't have to change the style declaration type
fremy: Here, the declaration and rules are exactly the same, no need
to change
fremy: If you're a tool developer, this is much easier
fremy: You don't have to switch between parsing modes based on
changes of syntax
fremy: This also avoids CSSOM incoherence
fremy: This is what the Blink people want to implement
fremy: The pattern also has similarity with XML structure
fremy: I don't think this proposal is weird, it's something web
people are used to
Rossen: We won't take a decision just yet, but want to get through
the queue
lea: Inline styles are in scope for nesting for the future, so it's a
disadvantage of this proposal that nesting doesn't support
inline styles
fremy: I don't think it's really that much easier for tool developers
fremy: If this fits with CSSOM, the CSSOM design may not be ideal
Rossen: thanks to fremy for the introduction
View Transitions
================
Define transitions over changing viewport
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7859
bokan: This relates to view transitions
bokan: The issue is that when you're performing a transition, the
viewport size could change during the transition
<TabAtkins> +1 to this proposal
bokan: For example, the mobile navigation bar or virtual keyboard
could appear/disappear during transition
bokan: Proposing a “snapshot viewport” that's a rect which stays
stable in all cases
bokan: We could position and size this so it goes under all the UI
bokan: On desktop, we can have similar issues with scrollbars
bokan: We would position this viewport under all that as well
bokan: The coordinate space comes from ::page-transition
bokan: When we capture elements, they're all positioned relative to
that rect, so it doesn't matter if UI is shown or not
bokan: The root snapshot is extended to fill the entire rectangle
bokan: We don't want page content to stretch because scrollbars
appeared or disappeared
bokan: There's pretty good consensus among those working on this, but
looking for feedback
astearns: Can things be padded with background rather than background
color?
bokan: Yes, agreed.
argyle: This sounds a little hectic with things appearing and
disappearing during a transition
argyle: Should we define things appearing or disappearing to come
before or after the transition?
argyle: Second question: what if I want to keep UI elements in place
until after the transition?
bokan: The URL bar in particular isn't under author control for
security reasons
bokan: It is tricky with the URL bar coming in and being animated,
the browser will have to coordinate things
bokan: Idea is that when the URL bar comes in, it slides over content
rather than pushing it around
bokan: We thought about whether you can wait for UI elements to
disappear before starting the transition
bokan: We don't want to delay animations, though
<iank> for the cross origin case - is it ok that they might be at
different (page) zoom levels?
argyle: What do Android apps do?
argyle: Are there patterns we can look at there?
bokan: That's a good idea, but if you're doing an SPA, you can keep
the keyboard up, but the URL bar is most out of authors'
control
<jensimmons> Please do research on iOS as well, not just Android.
ydaniv: You're talking about the sizing of the viewport, it doesn't
matter if you have to scroll during the transition?
bokan: I don't think we have to consider scroll here
ydaniv: Say I'm at the bottom of a list, and on the new page I need
to scroll to the top
Rossen: Another example would be an anchor navigation
bokan: Normally we'd take a screenshot of where you are and another
for where you're going and then allow crossfade
flackr: Overall I think this looks good, one comment: whether we can
show content behind the keyboard will depend on painted
content
flackr: The page has laid out to the size with the keyboard showing,
so content underneath the keyboard was never intended to be
exposed
flackr: You can't scroll to it or otherwise access it as a user
bokan: You can consider it's as if you scrolled it up
bokan: I think it's fairly rare for pages to rely on height like that
flackr: I don't think it's that rare for application-like interfaces
flackr: The other thing is that offsets will be relative to top left
of the new viewport; what if those change during the
transition, say by hiding the URL bar
bokan: Input is blocked while transitioning, so you can't hide the
URL bar
bokan: The three things affected are scrollbar, virtual keyboard, and
URL bar
flackr: Maybe it's a non-issue then
bokan: I think if that becomes possible we'd have to have a way to
fix the rect
jensimmons: Since we're designing for the web, we need to look at all
the mobile OSes, so please do also look at iOS and other
mobile OSes
<astearns> if we can do better than Android and iOS, then we
definitely should (rather than matching current app
behavior)
bokan: As far as we know, things work similarly between Android and
iOS
bokan: We are by default trying to make things more consistent
PaulG: A Bluetooth keyboard connected to a mobile device can
immediately hide the virtual keyboard, so make sure you're
testing that case
<fremy> +1, this sounds good to me
khush: I put up a proposed resolution
<astearns> proposed resolution: Use "snapshot viewport" for root
element snapshot and UA CSS to size and position
::page-transition at snapshot viewport.
Rossen: What does the WG think about that proposed resolution?
fremy: I think this is a solid proposal and adjust as we find problems
Rossen: Any objections?
RESOLVED: Use "snapshot viewport" for root element snapshot and UA
CSS to size and position ::page-transition at snapshot
viewport
CSS Nesting
===========
Allow relative selector syntax in @nest rules
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7854
fantasai: We had talked about adopting relative selectors as a way of
writing nested selectors
fantasai: Thus is you have a combinator, you could just write it
without prefixing with an ampersand (&)
fantasai: I believe all proposed syntaxes can accept having relative
selectors
fantasai: I propose we allow that for all of them
fantasai: In option 1, one proposal is you can only put a relative
after @nest, but you wouldn't need an &
<lea> +1 for relative selectors, +1 for not requiring @nest (the less
@nest the better...)
fremy: We can also do this for @scope
fantasai: I believe that's correct
miriam: I don't remember if we clarified that, but I agree it should
work
fantasai: I'll break this down
fantasai: Do we want to allow relative selectors for nesting and
@scope?
Rossen: Feedback or objections?
flackr: It's a bit odd that we support all selectors except
descendant because of the parsing ambiguousness
Rossen: Still not hearing objections, so will call this resolved
<miriam> scope spec says :scope is assumed at the start of selectors,
which is similar to allowing this (but not entirely explicit)
<argyle> I like the relative selector feature as nesting 2
<fantasai> Note: @scope already has this
RESOLVED: allow relative selectors for both nesting and @scope
fantasai: The next piece is that for option 1 syntax, where you have
to start with an ampersand, do we require it @nest?
<fremy> proposal is we allow `@nest > x` == `@nest & > x`
lea: The less @nest, the better
TabAtkins: I don't think it's useful to discuss option 1 syntax since
we don't know if we're going to use it
fantasai: Whether descendant selectors are allowed to be written as
relative selectors in nesting will depend on a following
discussion
astearns: Because of the weirdness about descendant selectors, should
we define an actual optional syntax for descendant
selectors in nest and @scope situations?
TabAtkins: I think we should but that should be a different discussion
Rossen: Please open an issue on that if we don't already have one,
Alan?
Rossen: Anything else on this topic?
(no)
<br dur=12m>
Syntax Invites Errors
---------------------
github: https://github.com/w3c/csswg-drafts/issues/7834
scribe: ydaniv
<Rossen> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
lea: If you followed all this and have an opinion but haven't
recorded a vote, please do so!
astearns: Who wants to present summary
TabAtkins: We've got 4 options covering all the possibilities
TabAtkins: option 1: either start with @nest or &
TabAtkins: option 2: you have a parser switch and afterwards only
style rules, so they're unambiguous and don't need special
prefixing
TabAtkins: option 3: your selector has to start with anything but an
ident
TabAtkins: in a rare case where you do need to start with ident you
can either use an & or wrap it up with :is() or :where()
TabAtkins: option 4: what FRemy presented either as separate block or
separate block following an &
astearns: We've had a poll. I wonder whether there's another
combination of starting with 1 and relaxing later to 3.
TabAtkins: Not sure it's a good idea to change syntax
<fantasai> ->
https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md#twitter-polls
fantasai: lea did a couple of twitter polls which are also helpful
fantasai: we have a significant majority that people prefer not
requiring & at all times
fantasai: we have a large number of authors who are not going to be
satisfied with option 1
argyle: There are many other projects with different syntax who are
using different syntax and are not considered in the polls
argyle: just wanna make sure they're included in this conversation
<TabAtkins> (Though note there are even larger ecosystems that are
using nesting syntaxes without a required & prefix.)
lea: Authors are not complaining, they just accept it is what it is.
But I have seen authors complaining that current syntax is too
noisy
<fantasai> lea++
<argyle> var(--foo) got the same response
lea: This is why we brought this up
lea: they really need nesting, but they will use what they have, even
if it could be better
jensimmons: I really like option 4 the best. It's really simple.
Other options are really complicated. I feel like CSS
should be fun and simple
jensimmons: option 4 captures that
<florian> +1 to jensimmons
fremy: I agree with what lea said. At the end of the day you have to
ship something.
fremy: people use what they have
fremy: I would not object to option 3. It's not the best I think. I
like 4 better.
<fremy< https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1292196313
fremy: one point I want to highlight, option 4 is the least complexity
fremy: we define 3 different syntaxes for nesting. It may change...
fremy: You have to consistently switch between syntaxes. I think this
is a big weakness
fremy: why add ambiguity when we can keep it simple. But if other
people prefer other options and are comfortable with tradeoffs
then we might as well do it
ericmeyer: I like option 4. Makes the most sense as an author.
argyle: May pick whatever syntax via any tool they choose.
argyle: when you reason option 1 has the least things to remember.
The least ambiguous
argyle: feels like a win win win across the board
argyle: you don't have to remember what you can/can't use. Not need
to teach what's an ident
argyle: all options eventually rely on &
<fantasai> Option 4 is the most unambiguous, and quite likely the
easiest to implement.
<fantasai> Whether it's the best, idk, but it's the most unambiguous
<lea> Not sure where it's founded that other options would take
longer to implement. We only have one data point here.
fremy: not true, option 4 does not
jensimmons: I don't really like the idea of us coming up with syntax
now and changing later.
jensimmons: as someone who's taught authors, I don't think it'll go
well if we change syntax 3 yrs down the road
jensimmons: our best shot is now
<TabAtkins> Big +1 to Jen's point - adding new *functionality* later
is fine, adding new syntaxes for no new functionality is
bad.
<fantasai> +1
<lea> +1
jensimmons: we should plan on our very best solution and be done
with it
jensimmons: I also believe strongly that nesting is important for
people to code better and easier
jensimmons: if they have to remember many rule with a lot of mental
complexity it's an overhead
jensimmons: not assume that using other tools is something everyone
will be okay with
jensimmons: I want nesting to be easy and fast to use, I want it to
be elegant, and if there's a bug it's a typo and not
because you're using the wrong variant of syntax
jensimmons: option 4 we haven't talked much about before. I haven't
heard others talking about it much
TabAtkins: I'd like to say what I don't like about option 4
TabAtkins: I'm very strongly opposed to 4. 1. it is not nested,
feels unnatural
<bramus> +1
<JakeA> +1 to the it's-not-actually-nested issue
TabAtkins: the idea that it's chained after and not inside the block
<bramus> authors already know how to nest, from at-rules, markup, etc.
TabAtkins: option 4 is the only that's not compatible with current
state. It doesn't mix with the rest.
<fantasai> wrt style attributes, we could just allow the rule block
to be placed inside the style attr, if we don't want to
add a new attribute. This has the same parsing properties.
<lea> +1 to everything TabAtkins is saying
TabAtkins: if you want nest existing rules into other rules you have
to go to bottom and add there
TabAtkins: in general having things in a sibling-wise way is not a
great idea
TabAtkins: in parent-child relationship things are always nested.
other options do that, 4 does not
TabAtkins: I also want to stress that this is not harder to parse
TabAtkins: 1 & 3 are identical. 2 is a bit harder
TabAtkins: 4 isn't difficult in any way, simply new
flackr: we mentioned in option 3 that it's possible to relax further.
flackr: it may be, but not a good idea
TabAtkins: not a possible idea ^_^
TabAtkins: Selectors just have fundamentally infinite overlap with
property:value declarations
miriam: I agree generally with what Tab said. option 4 is weird. It's
all trade offs. 3 is the one I voted for.
miriam: there's one rule to learn, always start with a symbol
miriam: I like the idea that both allow for forgiving parsing
bramus: I think nesting without nesting is also inventing weird things
dbaron: I think that 4.iii variant is somewhat different than others.
Having look at it more, looks like you have a selector and
bunch of things after it
dbaron: after looking it while doesn't feel like a un-nested rule
astearns: I was on the queue to say something similar
astearns: we also had another similar proposal of nesting a new block
inside
astearns: which gets rid of the weirdness
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1282700284
<fantasai> Conceptually, style rules would now have three parts:
<fantasai> a selector
<fantasai> a declaration block
<fantasai> a style rule block (optional)
<TabAtkins> that extra indent is very significant!
<TabAtkins> just do some RCV with instant runoffs
fantasai: My suggestion we have a lot of options
fantasai: pick between 1 or 3 and then continue
astearns: we're not picking a winner, we're choosing which avenue
to take
TabAtkins: I suggest we take binding votes
<bramus> +1 on binding vote
fantasai: I think the problem is that people are trying to implement
and we should be trying to resolve today
fantasai: suggest polling between 1 and 3
<fantasai> POLL: Option 1 vs Option 3
astearns: taking 2 votes: whether to continue with 1 or change to 3
please put your vote
<TabAtkins> 3
<lea> 3
<fantasai> 3
<argyle> 1
<oriol> 1
<miriam> 3
<JakeA> 1
<flackr> 3
<dbaron> 3
<patrickangle> 3
<futhark> 1
<bramus> 3
<jensimmons> 3
<astearns> 3
<fremy> 3
<Sebastian_Zartner> 1
<emeyer> 3
<ydaniv> 3
<florian> 3
astearns: Looks very much in favor of 3
fantasai: We're taking option 3 over 1
RESOLVED: We're taking option 3 over option 1
fantasai: anyone want's to add anything to the discussion of option 3
versus option 4?
astearns: I think that option 4 may get us to a better place
fantasai: option 4 has two viable options...
fantasai: ... two adjacent blocks, or some punctuation between them (
which would allow omitting the first block)
fremy: There's one thing I dislike, the idea that this is usability
against "I don't like it"
TabAtkins: I think this is a bad characterization
jensimmons: I heard people say that option 4 doesn't feel like
nesting because they're not nested inside. Not like SASS.
jensimmons: but I feel like I get that, I hated it, but then thought
what it opens up, it became my first choice
jensimmons: it lets me write more simply without repeating
jensimmons: feels like we're trying to solve reality where instead we
could choose a different way to accomplish more
<TabAtkins> Big objection against 4 is the inconsistency with other
syntaxes or planned future syntaxes. At-rules - do they
have to go in the property or the rule block? Nested
@media - how do we do properties directly inside of it
with option 4 syntax? This is common and popular in Sass,
for example.
TabAtkins: I said before that option 4 is inconsistent with current
syntax and others
TabAtkins: introducing a new postfix syntax will cause us problems in
may ways
TabAtkins: instead of using current syntax which works nicely
<lea> Oh great point, +1 TabAtkins
<TabAtkins> My dream would be to accept the "arbitrary lookahead"
option and just mix everything directly. It avoids all
issues *except* parsing perf. :/
fantasai: I agree with Jen about portability between contexts
fantasai: I have reservations against, options 3 has more rules to
learn but portability troubles me
fantasai: we can make changes to syntax
fantasai: there are ways around nesting media rules
astearns: shall we take 3 vs. 4 poll? please vote
<TabAtkins> 3
<JakeA> 3
<bramus> 3
<lea> 3
<argyle> 3
<fremy> 4
<astearns> 4
<oriol> 4
<jensimmons> 4
<flackr> 3
<florian> 4
<dbaron> 4
<andreubotella> 3
<patrickangle> 4
<Sebastian_Zartner> 3
<ydaniv> 4
<fantasai> probably 4
<jensimmons> ericmeyer isn't here, but he said 4 before
<dholbert> 4
TabAtkins: Editors choice
lea: Which editor?
astearns: Slightly in favor of 4
astearns: if we want to take a binding resolution 4 wins
TabAtkins: I would object, it's very annoying.
argyle: I agree
<JakeA> Poll developers for 3 vs 4?
astearns: We could change the draft to 3, and leave this question open
florian: It's effectively making a decision
astearns: If we're conflicted then we should not ship
<argyle> its just a prototype, no intent to ship
lea: It's already implemented behind a flag
astearns: Then their shipping shouldn't affect our decision
jensimmons: I would be disappointed if Google ships and this affects
our process
argyle: Google never intended to ship
argyle: no one was intending to ship
jensimmons: Pressure is good
<florian> Sorry for my earlier comment about lack of decision being a
decision. I had mistakenly understood that this was about
to ship anyways. Happy I was wrong.
fantasai: I think we should take suggestions to put options in front
of developers and get more feedback
fantasai: we could get more collaboration
fantasai: Would be reasonable to update draft to 3 since we like it
better than option 1
fantasai: Get more feedback about 4 and come back when we're more
confident
fantasai: We have to get it right, this is going to fundamentally
change how we write CSS for ~80% of style rules for the
rest of the life of CSS
<JakeA> The future is longer than the past :D
jensimmons: What Tab said about syntax sounded interesting would like
to see example
argyle: I suggest writing many examples and see how it comes up
argyle: with option 4 & 3
<fantasai> +1
astearns: Proposed resolution to change draft to 3 and leave 4 to
another talk
astearns: I don't think it's useful anymore
RESOLVED: Change the spec to reflect option 3
astearns: Who will take this to developers?
lea: Together with someone else
fantasai: I can help
miriam: Me too
fantasai: We should also mark issue into the draft for people to see
astearns: done with this issue
astearns: 10 mins break
RESOLVED: Open issue for further discussion of 3 vs 4
Received on Saturday, 29 October 2022 22:38:45 UTC