- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Jan 2022 05:43:46 -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 Conditional
---------------
- RESOLVED: Make conditionText readonly (Issue #6819: Setting
.conditionText interop is terrible)
- RESOLVED: Add an `at-rule` function with syntax `at-rule(@keyword)`
or `at-rule(@keyword; descriptor: value)` (Issue #2463:
Feature detection for descriptors)
CSS Backgrounds
---------------
- There were concerns about the parser complexity and inefficiency
that would come from the proposal in issue #4431 (Make box-shadow
a Shorthand Property). However, there was also strong support
expressed for the properties. Discussion will continue in the
issue.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/29
Scribe: emilio
Scribe's scribe: fantasai & TabAtkins
CSS UI
======
Define how to compute the kind of widget to use for an element
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/6537
florian: Haven't looked into this recently
astearns: I think we should accept the edits and file issues if there
are remaining problems
fantasai: I'd like that to be conditional on florian's approval
florian: Can we defer this to next week? Need to check changes were
made
Rossen: yeah, that's fine, don't want to get that landed and then
review it
CSS Conditional
===============
Setting .conditionText interop is terrible
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6819
fantasai: There's a lot of failures when I was testing this. Firefox
was the most correct on @media but fails on @supports.
WebKit / Blink doesn't support either
fantasai: Do we want to file impl bugs or call them readonly?
TabAtkins: I know setting media attributes on link is useful
TabAtkins: and used by some tooling
TabAtkins: So I think it's useful to continue supporting it
TabAtkins: but I wouldn't shed too many tears if we call it readonly
emilio: I'd like to say that making conditionalText in the OM is
different from what tooling does changing media of link
emilio: latter depends on ... stylesheets
TabAtkins: I was talking about toggling an @media rule
emilio: But not supported by WebKit and Blink
TabAtkins: Toggling *conditionText* isn't supported. But toggling
mediaText *is*, though essentially a synonym
emilio: The media attribute on link or style element toggles the DOM
attribute
TabAtkins: Not talking about that
TabAtkins: talking about @media rule
emilio: ah, ok, that's weird
TabAtkins: Jonathan Neal has exploited that to toggle entire sets of
rules before
Rossen: So if we move to resolve on making this readonly
Rossen: Would there be any objections to it?
fantasai: I suspect in either case we need changes in implementations
fantasai: just a question of which way we want to go
Rossen: Forcing a normative change here would be encouraging
something to change
fantasai: I have a PR adding tests, just haven't merged because
opened this issue
oriol: conditionText seems analogous to selectorText for style rules
and that's not read-only
oriol: In the past it was not interoperable but it got fixed
oriol: so counter-examples in both directions which is not a great
state of affairs
emilio: Counter-example, we made layerName readonly
emilio: and generally leaning towards making OM readonly
Rossen: So options are leave as-is and hoping tests cause browsers to
change
Rossen: or resolve on making read-only
Rossen: Should we do a straw-poll?
TabAtkins: I'd prefer to make stuff consistently mutable, given this
is analogous to existing things which are mutable
<bradk> +1 As is, but encourage browsers to change
<futhark> Existing issue for Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=1210073
emilio: Making @supports mutable would be a change
emilio: @media dynamically changes but @supports doesn't currently
emilio: so that might be why Firefox doesn't support mutating it. In
general readonly is going to be easier to get interop on
emilio: but not super-strong feelings either way
bradk: I think it should be mutable
smfr: from an implementor perspective we'd like to CSSOM be more
readonly, we don't have many incentives to fix these bugs
<TabAtkins> I suppose the fact that @media *does* have the .media
mutable means it's okay for the .conditionText to be a
readonly version that covers everyone
Strawpoll: A - as-is, B - read-only
<bradk> A
<fantasai> 0
<oriol> A
<florian> 0
<emilio> B
<smfr> B
<TabAtkins> B
<futhark> B
<miriam> 0
<dholbert> 0
<jensimmons> B
<astearns> 0
<jfkthame> 0
<bradk> I don’t feel super strongly about it
<lea> Α
<delan> 0
<TYLin> A
<Morgan> 0
<rachelandrew> B
<tantek> B until there's a use-case described (didn't see it)
<Rossen> B
<castastrophe> A
<chris> 0
<lea> Reasoning: Readonly puts undue burden on authors when they need
to modify these rules to make things easier for implementors
RESOLVED: Make conditionText readonly
Feature detection for descriptors
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2463
TabAtkins: Seems reasonable to ask for this given we can do it for
properties
TabAtkins: as @rules grow you might want to be able to test for given
descriptors
TabAtkins: There's a suggestion that we add a new @supports query to
test for descriptors
TabAtkins: I'd describe the two that I think we should add
TabAtkins: and lea has other ideas
TabAtkins: I think we should test for general @-rule support
TabAtkins: so "can you identify this rule at all"
TabAtkins: The other one should be a more complex one for testing for
a whole @rule
<TabAtkins> @supports (@rule) {...}
<TabAtkins> and @supports (@rule { desc: value; }) {...}
<fantasai> TabAtkins was summarizing
https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1015709662
right?
<TabAtkins> yes
lea: I think the only additional thing I proposed is that we
shouldn't have to add random descriptors to see if the browser
supports particular descriptors or what not
lea: so test for support for e.g. @property or so
emilio: Regarding testing the whole rule
emilio: It's a bit weird, because we don't track parse errors, we
just drop
emilio: We could do that potentially, but it goes against the
principle
emilio: I think it would be nicer to do something else, but not sure
what else could be
emilio: Don't have a generic idea for it
emilio: Like would great for `font-face-descriptor(desc: value)` but
then you'd need it for each
emilio: Just scares me if it gets out of sync
chris: Wanted to check where we are in nested at rules
emilio: Another related concern, some rules are related
emilio: So if you parse an at-rule in an @supports block ...
emilio: Should we consider position in the style sheet?
oriol: It seems strange to me the including-the-whole-at-rule
oriol: because parens would accept a weird set of syntax
oriol: and this seems a bit inconsistent / confusing to authors to me
<TabAtkins> (I'm fine with an `at-rule()` function, fwiw.)
oriol: because they might want to test for style rules
oriol: but we're not supporting that, so I'd prefer another function
oriol: or an option for testing general rules that could be an
at-rule() or general rule
oriol: but mixing some but not all rules, and also
property-declarations in parens would be a strange mix
TabAtkins: emilio's point about the whole rule testing is a very
reasonable point and I don't want to do this if it
requires special cases
TabAtkis: I'd like to instrument the existing parser if possible
emilio: Even with instrumentation, it can still get out of sync
emilio: e.g. someone forgets to propagate the error
emilio: so even if set just a boolean that indicates parser error
emilio: if don't set it at the right time, is a problem
emilio: It wouldn't be a whole new parser, just concerned about sync
TabAtkins: Connected to that, there's chris' question about nesting
TabAtkins: if you have per-at-rule descriptor function then you don't
get nested at-rules for free
TabAtkins: The other question was about context
TabAtkins: I'd say we should specify what the parsing context is for
this
TabAtkins: which would be the generic top-level stylesheet context,
so @import would fail
TabAtkins: and re oriol's point I'm totally fine with `at-rule()` or
something if you think it's less fair
<oriol> Yeah it think that's better
dbaron: I think when I wrote the @supports proposal the way I had
envisioned extending them is that we'd add new functions for
other points where CSS drops things
dbaron: so at the point where the CSS parser says "oh, that is
invalid so we drop it as a unit", that seems sensible to add
a function for
dbaron: and I think it's a bit weird to put a whole rule inside
@supports
dbaron: That said I think TabAtkins' argument about nesting is
interesting, because the approach I was thinking of at the
time doesn't allow you to test for such things
dbaron: so I have mixed feelings about it
fantasai: Regarding the TabAtkins' generic top-level context I think
that'd be confusing to authors, I think it'd be more
understandable and useful to authors if we allowed both
that or anything that's in the prelude, so that e.g.
@import would count as supported
fantasai: I think it'd be less confusing to authors
fantasai: and I can see use cases for doing that if you want to do
something conditional in whether some extended at-import
syntax is supported
fantasai: I also wanted to say about dbaron's comment that it would
be better to have the nested syntax rather than having many
custom functions per at-rule
fantasai: I'd prefer parenthesis rather than a function, I think it'd
be a little bit cleaner and easier to type
<TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo,
desc: value) {...}
TabAtkins: Thanks dbaron for all that context. If we follow those
premises we also avoid emilio's concerns. In that context
perhaps we could do something like what I typed above in
the chat
TabAtkins: it doesn't address nesting right now but we can extend it
if needed
TabAtkins: We also don't and probably won't have many at-rules that
are inconsistently nested
<faceless> Surely @supports (@import) should always fail, as @import
must be the first rule? So if you precede it with
@supports, it's not valid?
<fantasai> faceless, I don't think @supports queries should be
sensitive to position
<lea> faceless: is there a use case for @supports(@import)? Literally
every browser supports @import, no?
<TabAtkins> Not as a positive test, as a negative test.
emilio: @supports(@import) { } and then not put an @import inside
TabAtkins: My proposal is not parsing, just is this at-rule in your
list of recognize at-rules
emilio: fantasai it might be useful to test e.g. @supports(@import ""
layer) or something
emilio: though for layer you could check to @layer
emilio: I think having a generic at-rule() function is better than
having function per at-rule
TabAtkins: The downside is it wouldn't allow testing the prelude of
an at-rule
miriam: That was my question, because preludes seem important for
many things, such as @layer and @container
miriam: Prelude seem important for several things like layers and
container
miriam: so it seems odd to leave it
fantasai: I see that at-rule() as an improvement to having a function
per at-rule
fantasai: but I don't see how that is better than just dropping the
whole css syntax
<TabAtkins> If we wanted to add it, could have the form `at-rule(@foo
prelude stuff)`; when there's >1 token there we test full
prelude parsing
fantasai: It'd cover handling the prelude / descriptors / nested
at-rules / etc
fantasai: so I don't understand why we'd go for the function rather
than the proposal that was on the issue
TabAtkins: emilio and dbaron explained why that wasn't great
TabAtkins: You'd need to detect whether there's a parse error
somewhere in a rule needs instrumenting the parser
TabAtkins: Whether testing whether something is dropped entirely or
not is easy and can be done with no possibility of missing
things
TabAtkins: because we definitely drop things that are invalid and is
detectable, but detecting whether an inner descriptor
failed to parse inside an at-rule requires special-casing
Rossen: Does that answer your question Elika?
fantasai: yes
<TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo,
desc: value) {...}
TabAtkins: Proposal is having the at-rule function with two syntax
variants: `at-rule(@keyword)` and `at-rule(@keyword,
descriptor)`
fantasai: Not against that but I have a question about how do we
extend to the prelude
TabAtkins: Posted that up as well, we could have it drop the whole
prelude in there or something
fantasai: But prelude might include commas
fantasai: if you want something not in the prelude you're going to
need a semi-colon
TabAtkins: alright let's use semi-colons
emilio: Meant to write descriptor:value
lea: Would there be a way to test for @rule <name> or so?
TabAtkins: That's the prelude extension we were discussing above
<TabAtkins> at-rule(@keyword; desc:value)
dbaron: So to clarify you wouldn't extend it to put the whole at-rule
inside right?
TabAtkins: Right, or we just drop it and if we drop descriptors
inside then it'd test true
TabAtkins I think we should resolve on the keyword and descriptor
variants and we can extend to support the whole prelude
RESOLVED: Add an `at-rule` function with syntax `at-rule(@keyword)`
or `at-rule(@keyword; descriptor: value)`
CSS Backgrounds
===============
Make box-shadow a Shorthand Property
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4431
TabAtkins: We've discussed about this in the past
TabAtkins: People want to animate one bit of a shadow, like
increasing the spread etc
TabAtkins: You can always use custom props and so on and it seems so
straight-forward that I think we could try
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613
TabAtkins: Sebastian proposed a grammar (link above)
TabAtkins: (describes linked proposal)
lea: I want to express support, this is a very common thing. It's one
of the first examples I use for custom props
lea: Is there an inset prop?
TabAtkins: yeah
<fantasai> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613
lea: Can we do it for text-shadow too?
TabAtkins: yeah, also in the proposal
dbaron: I guess one of my reactions is that the stuff that background
does is one of the most complicated parts of implementing
value computations on CSS
dbaron: The code for dealing with that was a significant part of the
old parser
TabAtkins: For this there is one controlling property
dbaron: True for backgrounds as well (for background-image)
dbaron: and you need to keep the whole list because you might inherit
it somewhere where it matters
TabAtkins: Isn't this a common pattern like animation?
dbaron: Yeah, but it's special code every time
smfr: Should box-shadow-offset be further broken down into x/y
offsets?
TabAtkins: [meh reaction]
emilio: Regarding what dbaron said, not just about parsing complexity
but also efficiency
emilio: You need to store 5 different arrays rather than one
emilio: so it's also a bit more inefficient
emilio: maybe OK if we consider these to be relatively uncommon
emilio: The parsing complexity is real. Background is the worst by
far, but need to check also transitions/animations. It's not
super amazing
TabAtkins: Question is, is linked list-valued properties something we
want to add generally, or not
TabAtkins: The main question is whether adding more list-valued
shorthands is ok, and if it's not we should not do it
consistently
dbaron: I wouldn't say never do them but it's more expensive than you
might thing
TabAtkins: Curious, is the opinion different depending on "there's
one length-controlling property vs. shortest wins"
dbaron: I don't think it makes a huge difference
dbaron: only if you truncate computed values perhaps
TabAtkins: That seems fine
Rossen: Let's follow-up in the issue
Received on Thursday, 20 January 2022 10:44:27 UTC