- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 Mar 2019 22:28:26 +0300
- 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.
=========================================
Selectors
---------
- RESOLVED: Drop individual invalid selectors from selector lists in
*all* selector functions that take such lists, *except*
for :not() (Issue #3264: Let :is() have better
error-recovery behavior than normal Selectors)
- RESOLVED: Open up a new WICG project for this selector and it's
sub-issues. (Issue #2296: Selectors for textish and
buttonish elements)
- RESOLVED: Push this out to Level 5 (Issue #397: <label> elements)
Pseudo-Elements
---------------
- RESOLVED: Return null provisionally and open a TAG review issue.
(Issue #3603: Should Element.pseudo("unknown") be an
error or return null?))
- Issue #2960 (New generated content pseudo :between/:separator)
seemed to be a small use case of a larger problem of developers
looking to style things on the page that don't exist in the
content. The group will continue to think on this broader issue.
URL modifiers for image loading
-------------------------------
- RESOLVED: Unknown <url-modifier>s get silently ignored (rather
than invalidating the function).
- The group will look to solve several issues (#1603, #2095, #2994,
#3659) around image loading by aligning CSS's support with
HTML's image loading support, via url modifiers.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Scribe: TabAtkins
Selectors
=========
Error recovery for :is() and :not()
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3264
ewilligers: We resolved we'd like to have error-recovery for :is()
and :where(), but unsure about :not().
ewilligers: I have use-cases showing that :not() is used frequently,
so we probably don't want to change the meaning.
ewilligers: Do we want :nth-child() or :nth-last-child() have
error-recovery?
fantasai: :nth-child() should probably have the same error-recovery
as :is()
[...]
fantasai: I think it would make more sense with compound, not
complex selectors
fantasai: The big question for :nth-child() was compound vs complex
selectors.
fantasai: people want :nth-child(An+B of <selector>)
fantasai: If dropping support for combinators makes it easier,
would be good to get it implemented faster. Things like
zebra-striping non-hidden rows is a major use case that's
not currently solved otherwise.
ewilligers: I think webkit already shipped complex selectors in
:nth-child()
dydz: I'm looking in the WK code
fantasai: Emilio asked why we need selectors in :nth-child()
fantasai: Say we have a list of items, I want to color their
backgrounds alternately
fantasai: But some of them are hidden; they're display:none
fantasai: Counting is based on sibling list. If you hide 3rd one,
2nd and 4th will both have the same color
fantasai: So want to count after filtering
emilio: Whew, that's gonna be slow. We have a lot of caching already
to make :nth-of-type() fast.
ewilligers: I confirmed that Safari supports :nth-child(even of
div+div)
fantasai: My main concern is if other impls are more likely to
implement without complex selectors, getting even
compound-selector interop would still be great.
emilio: I think impl-wise, not supporting complex selectors is
easier.
TabAtkins: Unless we recursively pass down the compound-only
restriction into :is()/etc, you're at full power anyway.
fantasai: Maybe that's reasonable to have that sort of restriction.
fantasai: We'll just say Safari supports L5 of selectors, and L4
doesn't accept combinators
<tantek> agreed. reasonable restriction
emilio: Did we decide on how the new error recovery behavior
serializes.
emilio: Did we decide about serialization of invalid selectors in
:is()?
TabAtkins: I didn't think we were doing anything in particular?
ewilligers: I thought we'd just drop them.
emilio: What if they're all invalid?
ewilligers: You just get :is(). A little weird with
:nth-child(even of), tho.
ewilligers: What about parsing of weird stuff? Extra close brackets,
what happens?
TabAtkins: Syntax already handles brackets correctly. We just split
the tokens on top-level commas, then interpret each chunk
as a selector.
fantasai: So back to the issue, :is() and :not() take a list of
selectors
fantasai: Currently any invalid selector invalidates the entire
selector list.
fantasai: Because we now have these functional notations that
creates some scoping, within :is() we can just ignore in
the invalid selector, but still process the rest.
fantasai: So we're gonna resolve that within :is(), we ignore
invalid selectors.
ewilligers: And :where(), :nth-child(), :has(), etc.
fantasai: But not in :not() - the whole thing will invalidate if any
are any invalid.
gregwhitworth: I think it's weird to have :not() work different. I
get the percents making it hard tho.
AmeliaBR: I do use :not() as an @supports for new selectors...
AmeliaBR: e.g. :not(:valid) means you support :valid, and this
selector selects things that are not valid
TabAtkins: I was going over the boolean logic for :not()
invalidating just parts too this morning, and was getting
really confused...
RESOLVED: Drop individual invalid selectors from selector lists in
*all* selector functions that take such lists, *except*
for :not().
Selectors for textish and buttonish elements
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2296
fantasai: Use-case seems quite reasonable
fantasai: People wanna style things that look like buttons as a set
fantasai: But that set isn't clear, and it's a long list that
changes over time, maybe across OSes, etc.
fantasai: So having a selector that classifies inputs as "buttonish"
and "text inputish", so when you style buttonish you can
style them all at once to look the same
fantasai: That seems reasonable to want.
<bkardell> aliases would help here, but also they wouldn't cover
'new' things that get/got added
TabAtkins: I've been in favor of this for a while.
emilio: textarea counts as inputish?
fantasai: Yes
AmeliaBR: Complex things - where text and button are both *parts* of
it...
AmeliaBR: Pseudo-element to target pieces, maybe?
AmeliaBR: And other issue is which groupings makes sense.
AmeliaBR: I think there is consensus on textish and buttonish, and
maybe popup-ish
fantasai: I think for popups UAs typically categorize those one way
or the other, depending on whether it's styled to look
fundamentally like an input or like a button
TabAtkins: What's popup?
AmeliaBR: Like <input type=color>, raising a popup.
fantasai: The UA has to categorize, but for those with some options,
UA should classify according to how they in particular do
things.
fantasai: Compound things are complicated.
TabAtkins: I think for things like file input, when it's a
text+button combo, it just matches neither.
hober: How does a custom element say it's buttonish or textish?
TabAtkins: DOM is just now discussing API for custom elements to
hook into forms, we should get into that convo.
bkardell: Was fantasai suggesting an ARIA role=button is buttonish?
fantasai: That's a possible way to handle the style mapping for
custom things, yes.
fantasai: Unsure if it's a good idea, but it's a source of input.
AmeliaBR: I would say don't do that. If the purpose is to target
elements with a certain set of default browser styles,
then the aria-role doesn't apply.
AmeliaBR: And it goes against the thing that ARIA is for custom
widgets that don't fit into the browser default stylings.
<astearns> +1 to role=button isn't buttonish for this discussion
bkardell: Yeah, what's the intent is the question.
fantasai: One of the big things is getting styling that author
doesn't know, because it's from the UA. For custom
elements the author should know.
AmeliaBR: Another issue for this is verbosity, plus it's not forward
compatible. If a new type gets added it could be
buttonish, but it won't be in your selector today.
fantasai: And platform conventions can vary.
tantek: I realize there's a point you can argue either way, but I
think this is styling according to the browser's default
styling, not the semantics.
tantek: I think the instances AmeliaBR and fantasai pointed out are
key here.
tantek: One input could be texty or buttony on different browsers,
that's presentation, not semantic.
astearns: Does that suggest the name should be :browser-button, etc?
tantek: Not gonna bikeshed, just contributing to narrowing what
we're solving
bdc: I find the intent pretty obscure to be honest.
bdc: The fact that we're avoiding a few selectors, or classes, isn't
super compelling.
bdc: Forcing browsers to make the decision on whether it's buttonish
or textish is weird.
[discussion on whether an input exists that could be ambiguous
between the two categories]
bkardell: I think if you look around 2008ish in the archives, you'll
find discussion about this sort of thing.
bkardell: I think maybe Selectors, when it was still in CSS main,
included some of these things? A button pseudo?
bkardell: jQuery definitely supported these things, I think because
it was in the spec at the time.
<AmeliaBR> jQuery `:button` selector: https://api.jquery.com/button-selector/
bkardell: Every designer I know that tries to enforce this style
runs into this problem.
bkardell: We landed on the possibility of solving it with Tab's CSS
Aliases thing.
bkardell: Important to not create something that's bound too tightly
to make tiny categories.
hober: I presented a form-submission API a few years ago, and the
current proposal looks a lot like it. From what I recall it's
not tied to the element being a custom element.
bkardell: Yeah, just think it's important to consider the use-cases
as holistically as possible, to make sure it gives authors
a good experience.
astearns: So think I'm hearing *general* agreement on this, with
some skepticism about whether it will end up being useful.
AmeliaBR: I don't usually say this, but this might be worth throwing
it to WICG.
AmeliaBR: On that thread lots of people active in CSS communication/
education, but not in standards. If we could convince Keith
etc. to draft up some ideas, might be a useful way forward.
<bkardell> that seems good
TabAtkins: I support that.
fantasai: I think on the CSS side it's just a few paragraphs. On the
HTML side they'll have to define exactly how it applies.
TabAtkins: And there will be a DOM side, to opt your elements into
things.
fantasai: If we don't have the extensibility, is it still worthwhile
to have this in CSS? The CSS side is just like 15 minutes
of work.
astearns: We'd still need the HTML side, right?
fantasai: That's more clarification, I'd think.
RESOLVED: Open up a new WICG project for this selector and its
sub-issues.
<label> elements
----------------
github: https://github.com/w3c/csswg-drafts/issues/397
AmeliaBR: I brought this up on WHATWG because the relevant text is
in HTML, but they threw it back to CSS.
AmeliaBR: Often you want to do some styling on the label or on
gencon that depends on :required or :invalid or :focus on
the label's associated input
AmeliaBR: Right now the only way to do that is by modifying your DOM
structure so the label is a following sibling of the input.
AmeliaBR: Having to modify your DOM to do styling is iffy, there are
some cases where this can't work.
AmeliaBR: And it also means you can't use the implicit association
of label with child inputs; you have to use IDs, which can
cause problems in dynamic content.
AmeliaBR: So the suggestion was that the <label> should reflect the
form-related pseudos, and :focus/:hover, of the associated
form element.
AmeliaBR: Last time this was discussed there were some performance
concerns, but labels already have a DOM association (you
can chase a DOM property to see the associated input)
AmeliaBR: As I recall there is something in the HTML spec about how
focus or hover already propagates in a certain way...
<xfq> WHATWG issue: https://github.com/whatwg/html/issues/1632
<astearns> some concerns from bz:
https://github.com/whatwg/html/issues/1632#issuecomment-238301486
myles: People use labels and form controls everywhere already, is
this gonna break anything?
AmeliaBR: If you've got `label:invalid` that currently does nothing,
then it could be an issue.
AmeliaBR: Or perhaps some of the more common pseudos
TabAtkins: I think :hover is the most likely to see some new stuff
emilio: Eh, reasonable to see `form :invalid`, would trigger more.
emilio: And the fact that labels can be anywhere in the DOM (current
state propagation, like to fieldset, is just parent/
ancestor-based), talks to BZ's concern about this being one
more thing to slow things down.
<AmeliaBR> `label:for(:required)`
AmeliaBR: On the perf issue, it's worth remembering that labels and
inputs already have DOM properties that link to each
other. But they probably aren't used much, so they might
be slow getters, I dunno.
emilio: Also worth noting that CSS needs a 2-way link; label->input
for the selector, but input->label for invalidation
<AmeliaBR> Re DOM APIs, labels have a `control` property, while
labelable elements have `labels` (node list)
https://html.spec.whatwg.org/multipage/forms.html#dom-lfe-labels
scribe: fantasai
TabAtkins: In general I'd say resolve to reject at this point, since
still implementer resistance on performance grounds.
Which makes me sad because I've run into these exact
problems.
<bkardell> can we note the "waves hands and invokes potential
houdini solution" in the rejects notes?
astearns: Not really a rejection, just no implementer interest yet
TabAtkins: Yeah, not going in as expected feature of the spec atm
AmeliaBR: If we do it in the way Tab proposes, to avoid any
back-compat issues with :for() pseudo
AmeliaBR: So there's a CSS issue and a WHATWG issue
AmeliaBR: CSSWG says if we do this, this is how we do
astearns: And try it out with Houdini
TabAtkins: I still have to finish TypedOM, but custom selectors will
probably be next
hober: There's the AOM work to do association without IDREFs, using
direct assignment. Should probably tie in with that
<hober> https://github.com/WICG/aom/issues/2
TabAtkins: I recently had discussions with people about solving
problems, can we have a selector associated with a map
that I have created
TabAtkins: Seems like would solve a lot of problems
TabAtkins: Should be part of houdini work
RESOLVED: Push this out to Level 5
Unknown pseudo() arg
--------------------
github: https://github.com/w3c/csswg-drafts/issues/3603
TabAtkins: We can either go with JS likes to signal errors for error
conditions
TabAtkins: or DOM likes to return nulls
TabAtkins: I believe we should return a null for this object.
TabAtkins: fremy made a good use case for being able to easily test
whether a pseudo is supported in an element
TabAtkins: Throwing is more verbose in JS
astearns: There's also question of does this element support this
pseudo
TabAtkins: https://github.com/w3c/csswg-drafts/issues/3603#issuecomment-463287002
TabAtkins: I think this is fine.
TabAtkins: Null will immediately throw an error if you try to access
properties on it, so you'll get an error if you don't
check anyway
TabAtkins: Gives you same behavior in practice, but null gives you a
more useful boolean result in practice
* fantasai wonders what gCS(unknown-property) returns
myles: ...
TabAtkins: querySelector() throws and it's really annoying
myles: Just pointing out the fact that it throws
fantasai: If you and fremy agree, seems OK to me
fantasai: We can also ask the TAG if they have an opinion on this
astearns: Not sure it's that important
<bkardell> +1
fantasai: It's about consistency across the platform. TAG is good
for that.
RESOLVED: Return null provisionally and open a TAG review issue.
New generated content pseudo :between/:separator
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2960
fantasai: I don't wanna do another generated content pseudo.... :(
TabAtkins: Gonna discuss the problem
TabAtkins: People want to address generated content siblings of an
element
TabAtkins: There's a few variants that people want, but usually you
want to address siblings, and before/after children
TabAtkins: Sometimes it's about wrappers
TabAtkins: There appear to be several different possibilities to
address this
TabAtkins: First one, is a ::between pseudo
TabAtkins: It's like ::before/::after in that it creates children of
an element. They sit between the children rather than
before/after.
TabAtkins: Solves problem of ordered list with separators
TabAtkins: ul::between { content: " | "; }
TabAtkins: Right now have to be careful about not styling last
element or first element or whatever.
TabAtkins: Next one is ::contents, which is a wrapper element around
all of the real children.
TabAtkins: This has a number of use cases. People want extra
wrappers and have asked for this before.
TabAtkins: Have to do it by putting more elements in the DOM
TabAtkins: Can be used like ::between in some cases, if you set the
actual element to be 'display: contents'
TabAtkins: and then style the ::contents instead of the element
itself
TabAtkins: Next one is ::parent/::wrapper, inverse of ::contents
TabAtkins: Creates a pseudo outside the element. More complicated
wrt inheritance, because it flows uprward from
originating element
TabAtkins: Last suggestion is ::outer-before/::outer-after. Creates
siblings of originating element.
TabAtkins: travels sideways
TabAtkins: I think we should not have all of these. Maybe one of
these. Maybe none of these
TabAtkins: 'display: contents' makes some of these easier
TabAtkins: Question is do we want to do any of these, and if so
which one?
fantasai: I really don't like the way ::contents requires hiding
the element itself
fantasai: This has bad cascade ergonomics
fantasai: ::between seems simplest
fantasai: solves some use cases very cleanly
<fantasai> The ::contents solution affects how every part of your
stylesheet interacts with this particular element. You
want to solve this separator problem in this corner of
your style sheet, but because you do it by hiding the
actual element and moving all styles to the ::contents
pseudo, every other part of your style sheet need to know
that it has to style the ::contents pseudo of that element
instead of the actual element.
<fantasai> This is fragile cascading and bad ergonomics for the
author.
<tantek> Cascading is already too hard for authors, I tend to agree
with fantasai that this would make the model worse (harder)
for authors to predictably use / style etc.
emilio: Can we agree that whatever we do, that doesn't affect
inheritance of the children? If you do ::wraper { color:
green; } doesn't affect children of the element
emilio: Because ::first-line has that weird thing and I prefer not
having it
dydz: So the problem is that you had that horizontal list and you
wanted separators, and you wanted vertical bar or character,
and currently the person is saying there's no easy way to get
at every other element, don't want to put a bar before the
first one and not after last one
fantasai: That's part of it, it's nicer that it's easier to express.
But the main problem is existing ::before/::after is child
of the item, but you want a sibling of the item.
dydz: Why can't you use ::marker?
TabAtkins: Markers are also children
TabAtkins: They're inside the list item. If I put a border around
it, it'll include the marker
myles: So you want a sibling
TabAtkins: Yeah, at least in the box tree
jensimmons: To dydz's point, people who write CSS have a workaround
for the specific case in the thread
jensimmons: but when we talk about possibility of creating a new
pseudo element
jensimmons: My brain starts spinning about all the dissatisfactions
we have about this
jensimmons: Sometimes we wish we had much more than ::before/::after
jensimmons: Sometimes we wish we had ones that were siblings
jensimmons: If we go down this road, think about all the ways that
we want to have pseudo-elements, that's great.
jensimmons: But let's come up with something that's robust and
elegant, and solves this use case without creating new
problems.
jensimmons: The scope of this problem is too small. It's a hint to a
bigger scope. Coming up with a quasi-hack that solves
this one thing is not as robust or complex as what we
really need
futhark: What Jen is saying is, ::before and ::after can be same
alias of ::between?
fantasai: Child list of an element is ::before, first child,
::between, second child, ::between, third child, ::after
<dbaron> We had something like this before, but I think concluded we
wanted XBL (or its successor) instead.
jensimmons: Wouldn't be between, would be something else. You could
have as many as you want. Like 17 of them. could
determine if children or siblings
jensimmons: We have gaps in flexbox and grid, another way would be
to style gaps or empty grid cells
jensimmons: would allow authors to style those things without them
being real
<bkardell> would it make sense to try to tackle the definitions
there in houdini?
myles: General solution to boxes is really interesting. But we don't
want to go so far and make a whole DOM in CSS.
myles: A competing proposal that is more powerful and general would
be interesting, would want to hear about it.
jensimmons: Most common case for pseudos that are siblings is
decorating empty grid cells without putting empty markup
in the DOM
TabAtkins: That one we definitely need to solve, I agree.
TabAtkins: That one is easier because it doesn't require where to
insert between elements, can be a pile of ::befores
TabAtkins: I fear that a general solution would just re-implement
the DOM, though.
fremy: I was going to say, I feel like in what we provide in CSS, I
would be very glad if we have ::between which is reasonable
for most use cases
fremy: If you want custom boxes, use Houdini
fremy: If you need 17 boxes, you need specific stylings for each
fremy: 17 random boxes is not useful
fremy: Grid is a good example of where we can describe this, but in
the general case I think it will get more and more obscure
<dauwhe> https://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting0
fremy: But if we do decoratively in CSS, seems nice, ::between is
very similar to what we already have and it solves a lot of
cases that people have
fremy: Having something simpler solution is better
fremy: I think ::between is the best way to solve this case. If you
need more complex, Selectors is maybe not the right solution.
TabAtkins: We're talking about boxes, but it's about elements.
TabAtkins: And custom layout is about fragments, not boxes.
TabAtkins: Let's look more into stuff.
TabAtkins: Jen brought up more possibilities, we should pay
attention before tackling this.
jensimmons: The need is to have a way to lightweight put styling on
things, like dividers between things or bg colors on
particular grid cells
jensimmons: Want to do that in an elegant way, not limited to one or
two.
jensimmons: We've been using ::before/::after. We're reaching limit
of those hacks.
jensimmons: I don't want to solve one use case. I want to solve the
systematic problem at the right level.
jensimmons: I don't think it's just about lines between navigation
elements, I think it's styling things on the page that
don't exist in the content.
<bkardell> wonder if we can be careful if/when we do that about
whether generated text winds up exposed to the
accessibility tree too
dauwhe: I run into this all the time. We want multiple borders in my
world. Just nest a bunch of divs.
myles: Which is contrary to the philosophy of CSS.
tantek: That feels a little different than what Jen was talking about
tantek: Jen was talking about ways to style the negative spaces in
CSS.
fantasai: Wrt multiple borders, we should solve that by actually
having multiple borders.
astearns: Sounds like we're done for now, keep discussing later.
URL modifiers for image loading
===============================
Scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/1603
https://github.com/w3c/csswg-drafts/issues/2994
https://github.com/w3c/csswg-drafts/issues/2095
https://github.com/w3c/csswg-drafts/issues/3659
AmeliaBR: So there are several modifiers that exist in HTML image
loading.
AmeliaBR: background-images don't need crossorigin info, so if it's
the first thing it sees, browser fetches it without
crossorigin.
AmeliaBR: If you then use it for something else that *does* care
about CORS, browser has to fetch a second time.
AmeliaBR: Or it just gets reused and errors.
AmeliaBR: Both are suboptimal.
AmeliaBR: Can get around it today by adding a <link rel=preload>,
but then need to alter markup to adjust CSS.
AmeliaBR: So having a way to indicate in CSS that something should
be requested with crossorigin permissions for later would
be useful.
tantek: I agree completely with the use case and with the more
general use case, that everything you can tweak about image
loading in HTML should be tweakable from CSS as well
hober: I agree that CSS should match HTML here.
hober: But both should be sitting on top of Fetch. Fetch should have
some keywords, and we use those keywords
AmeliaBR: Good point
AmeliaBR: I think all of these should be addressed together with a
common syntax.
AmeliaBR: I don't know what's the nicest or more author-friendly
syntax, but good to consider them all together, not
piecewise.
AmeliaBR: Other ones open are #2994 on preloading something, #2095
for async decoding, and #3659 for lazy loading
AmeliaBR: Issues for async and lazyload is that browser defaults for
CSS images are different from HTML content images.
AmeliaBR: Maybe can't copy html, need to think about what makes
sense for CSS specifically
jensimmons: Yes, we need this. Proposal is to put the burden on
authors to set this up correctly?
jensimmons: Authors already have a hard time on CORS compat.
jensimmons: Can we put the burden on the browser instead?
TabAtkins: I suspect not. These are all behavior changes, so
changing defaults could break changes.
AmeliaBR: Also if browser has to consider all possible cases for how
it'll request an image before it can send the request, it
can get messy/slow, especially with dynamic loading
astearns: Yeah, browser might not know that a *future* load will
need CORS, so there's no way for it to tell without a hint.
astearns: So on the align-with-fetch issue, does Fetch have keywords
for all these topics we can follow?
emilio: Firefox already does async decoding on all images.
myles: Really? We did that but had to roll it out.
emilio: We do it unless it's something our image library can tell is
fast.
TabAtkins: Is there an attribute for async decoding on <img>? Not
sure we should do anything img doesn't.
AmeliaBR: Yeah, there's a `decoding="auto|sync|async"` attribute
proposal.
emilio: What's the story with unknown url modifiers? Would be sad if
you have to rewrite the url several times for different
combos of browser support.
TabAtkins: Not defined right now. We should decide how we want to do
error handling
* emilio thinks lazyload should be split from the rest of the
proposal, since that's fairly different
myles: We solved this for src: with forgiving handling, split on
top-level commas and ignore unknown stuff.
astearns: Yeah, good to match.
<AmeliaBR> URL modifiers https://drafts.csswg.org/CSS-values/#url-modifiers
AmeliaBR: Reading the definition of url-modifier, it looks like they
can't be used on unquoted urls or just-string urls. That
means it needs to have a quoted string inside?
TabAtkins: Yes.
fremy: Edge currently ships with the quoted-url-as-function-token
behavior.
emilio: Also Firefox.
astearns: So any objection to silently ignore unknown url-modifiers?
RESOLVED: Unknown <url-modifier>s get silently ignored (rather than
invalidating the function).
AmeliaBR: So I think the rest of the issue is, align CSS's image
loading support with HTML's support, via url modifiers.
TabAtkins: Agreed.
<br>
Received on Tuesday, 26 March 2019 19:29:18 UTC