- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Dec 2023 19:55:11 -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 Contain
-----------
- RESOLVED: No container is valid for unknown queries (Issue #7551:
Inconsistent handling of known and unknown features
jeopardizes backward compatibility)
- RESOLVED: Add the comma-separated syntax (Issue #7551)
Media Queries
-------------
- Issue #9701 (Media query for enclosed screens) will return to
GitHub for further discovery about potential use cases and
considerations about when an enclosed screen device is able to
"cast" to another screen.
- RESOLVED: Add a new condition= attribute that takes
<import-condition> syntax (Issue #9375: Consider `@media
supports()`)
- RESOLVED: Do not add `supports()` to @media (Issue #9375)
CSS Values
----------
- RESOLVED: Accept edits (Issue #3320: Clarify fragment URLs resolve
against the current tree, not document tree)
CSS Backgrounds & Values
------------------------
- RESOLVED: Accept the proposal in the comment [
https://github.com/w3c/csswg-drafts/issues/549#issuecomment-1823607623
]
(Issue #549: Align logical values for <position> with the
ones defined in CSS Logical Properties)
CSS Backgrounds
---------------
- RESOLVED: Add x,y,block,inline longhands, and the repeat-block and
repeat-inline keywords to the shorthands (Issue #116: Add
background-repeat-x/y)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0004.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Stephen Chenney
Yehonatan Daniv
Elika Etemad
Robert Flack
Daniel Holbert
Brian Kardell
Jonathan Kew
Florian Rivoal
Fernando Serboncini
Alan Stearns
Brandon Stewart
Miriam Suzanne
Regrets:
Chris Harrelson
Bramus Van Damme
Lea Verou
Chair: astearns
Scribe: TabAtkins
Housekeeping
============
astearns: Housekeeping - next week there will be some HDR and images
topics
astearns: If you're planning to travel to Mountain View in Feb,
please add your name to the wiki
TabAtkins: I'll send more reminders, but at some point a few weeks in
advance, I'll need to make a final call
CSS Contain
===========
Inconsistent handling of known and unknown features jeopardizes
backward compatibility
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-1753610690
miriam: In Container Query resolving process, first step is finding
the container that can answer the questions
miriam: Then we query it
miriam: Issue we created here is that, right now, if we have an
unknown condition in our query, we assume any container can
answer it
miriam: Really should be that *no* container can answer it
miriam: Down the road, when the unknown is supported, it should
actually become conditional
miriam: If it's becoming true now, because we ignored it, that'll
break if it's sometimes false later
miriam: Better to have it always false now, and then sometimes true
later
miriam: Stalled due to some concern about backcompat. Rune did a use
counter and found usage is extremely low
miriam: So hoping we can make the change despite it being breaking
miriam: First change - no container is valid for unknown queries
(<general-enclosed>)
miriam: Second - add a comma-separated syntax so you can execute
multiple queries that can match against multiple queries
miriam: The difference between logical "or" and a comma is the comma
allows two different containers to be queried, while "or" is
looking for a single container that can answer both questions
<TabAtkins> +1
astearns: Does the syntax have logical or currently?
miriam: I believe so (I'd have to double check)
astearns: So the comma-separated container-or could be combined with
query-or
miriam: Yes, confirmed, logical "or" is allowed in spec currently.
astearns: Comments or concerns?
astearns: So let's resolve on the first
RESOLVED: No container is valid for unknown queries
astearns: Second is to add the comma-separated syntax, an "or" but
allowing different containers
<TabAtkins> +1
RESOLVED: Add the comma-separated syntax
Media Queries
=============
Media query for enclosed screens
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9701
fantasai: For virtual headset displays, there might be some things
that are different from regular displays an author will
care about
fantasai: We have several MQs already - pointer, hover,
environment-blending
fantasai: One thing that came up is whether you can scan a QR code on
the page - if you're on a headset, your phone can't be used
to scan something on the page
fantasai: So question is if we should add this, and if so, what to
call it?
bkardell: Whether you can scan a qr code is something people want to
do with.
bkardell: igalia makes a vr browser
bkardell: used on many enclosed-screen browsers
bkardell: The fact that you can't scan the obvious way doesn't mean
there won't be a way to do it
bkardell: The browser might offer a way to follow a qr code itself
fantasai: In general, you can't take a photo of the screen with
another device
bkardell: Not directly, but you can cast to another device
fantasai: At that point you have another device and it can resolve
the MQs differently
bkardell: Well, not if it's like ChromeCast
florian: Need to be careful about the "cast" situation
florian: In the flip way, you think if you're *not* in an enclosed
screen you want to hide passwords by default, but show when
you are in an enclosed screen because nobody can see
florian: But if casted they can
florian: So does it mean people *probably* can't see your screen? Or
*definitely* can't?
florian: Think we need to know more about the intended use-cases
(plural) to know how they expect to behave
bkardell: Yes, agreed. There's "pass-thru" on devices; on a Quest
it's not good enough for photos, but for others...
bkardell: Might be good to bring to Immersive Web group. Happy to
talk more offline.
bkardell: I think there def are some more MQs to do here
astearns: Sounds like we should take this back to the issue and
explore the specific use-cases in more detail.
astearns: Is that ok?
fantasai: I think that's fine. Main thing from our side is the QR
code issue.
bkardell: Explain that?
fantasai: You have an app, can send info or authenticate yourself by
scanning a QR code with your phone and it'll link accounts
fantasai: But you can't do that if you're on a headset
TabAtkins: The phone is the thing that needs to see the QR code,
doesn't matter if the headset can scan it
TabAtkins: so that e.g. you can link your phone chat with desktop chat
TabAtkins: This is not handled by the browser on the headset being
able to do anything
bkardell: The browsers on both devices can talk to each other
bkardell: Those devices generally have some way to send info to
another device. We should talk offline
astearns: In the cases I can think of, where scanning a QR code is
necessary, there's usually an alternate provided because
not everyone has a second device.
astearns: We'll take it back to the issue and explore the use-cases.
CSS Values
==========
scribe: fantasai
Clarify fragment URLs resolve against the current tree, not document
tree
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3320#issuecomment-1823679506
<fantasai> spec text -> https://drafts.csswg.org/css-values-4/#local-urls
TabAtkins: Awhile ago, we discussed how a fragment-only URL needs to
be resolved
TabAtkins: both in general, in presence of base URL changes, or
history API changing URL etc.
TabAtkins: wanted those to be stable
TabAtkins: Also question of how that works in shadow DOM
TabAtkins: IDs are scoped to a particular shadow tree
TabAtkins: The resolution was that a fragment URL in a shadow tree
resolves against IDs in that tree if possible
TabAtkins: if document-global, does page-local resolution
TabAtkins: not paying attention to absolutized URL still matches
or not
TabAtkins: fantasai objected to the way I was writing because of
future-compat with other types of fragment URLs (that are
not IDs)
TabAtkins: I'm not 100% sure, because not familiar with other parts
of the ecosystem
TabAtkins: but I think it gets the point across
TabAtkins: If your fragment is an ID reference, treat as ID reference
relative to whatever shadow tree you're in
TabAtkins: otherwise, resolve against document e.g. as media fragment
TabAtkins: if other fragment types need to be shadow-sensitive, can
adjust, but for now they're all global
TabAtkins: So requesting review from CSSWG, maybe take a resolution
to accept text but can take time to review if wanted
astearns: Has ryosuke reviewed?
ACTION: fantasai ask ryosuke to review
astearns: Any comments?
astearns: Proposed to accept edits and close the issue
bkardell: Does it take into account the base URL?
TabAtkins: No, very specifically not paying attention to URL before
the fragment part
TabAtkins: If your URL is just a fragment, it's guaranteed local
TabAtkins: no matter what you do to page URL, or when you resolve URL
TabAtkins: We interpret as an ID reference
bkardell: Ok, I get it
astearns: Objections?
RESOLVED: Accept edits
astearns: As people find more problems, open more issues
CSS Backgrounds & Values
========================
Align logical values for <position> with the ones defined in
CSS Logical Properties
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/549#issuecomment-1823607623
TabAtkins: In the issue, specifically the comment at
https://github.com/w3c/csswg-drafts/issues/549#issuecomment-1823607623
TabAtkins: fantasai and I worked on final proposal to integrating
logical values in to <position> and <bg-position>
TabAtkins: I'm very happy with this in general, and most places where
this will matter
TabAtkins: e.g. in transform-origin or shapes
TabAtkins: There's a question that Oriol raised about how this
expands into longhands when you have both physical and
logical
TabAtkins: We haven't fully resolved how that's supposed to work
TabAtkins: background-position, given it has -x/-y, will presumably
have -inline/-block
TabAtkins: From syntax, it's obvious which to resolve to
TabAtkins: but not obvious for var()
TabAtkins: Don't know which set to expand into until var() resolution
TabAtkins: So further issue of how to handle in background-position,
which I'd like to defer
TabAtkins: but for <position> itself, I'm happy to resolve to accept
this set of additions if people are happy
scribe: TabAtkins
fantasai: I think that we need to somehow make this work, so we
should just accept this syntax for both things then figure
out var() resolution
fantasai: Even if it's very dumb, at least it'll work for basic
cases. Need logical bg positions
TabAtkins: Yeah that's probably reasonable.
astearns: So we would accept proposal in that comment, and then open
up issues on var() resolution
TabAtkins: Already open
astearns: Proposed to accept proposal
fantasai: Summarizing:
fantasai: The new syntax expands <position> to allow x-start/x-end/
y-start/y-end as alternatives to left/right/top/bottom
fantasai: It also adds block-start/block-end/inline-start/inline-end
as a separate production which can't be mixed with the
physical axis keywords
fantasai: And as a shorthand also allows just "start start"/etc
fantasai: Same pattern as in other logical props
fantasai: So we can specify fully physical, specify physical axis but
a logical side, or specify fully logical. Gives us every
combination
fantasai: But for the resolution I'd say just accept the proposal in
the comment
<SebastianZ> +1
astearns: Any reactions to that summary?
astearns: Objections?
RESOLVED: Accept the proposal in the comment
CSS Backgrounds
===============
Add background-repeat-x/y
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/116
SebastianZ: background-repeat-x/y as longhands for background-repeat
SebastianZ: Implemented in Gecko, usage numbers relatively high
SebastianZ: Usage numbers are around 0.5%
SebastianZ: So, want to specify this for web-compat
SebastianZ: Oriol pointed out it might make it hard to add logical
keywords to background-repeat shorthand
SebastianZ: But I think we do need to do this as the usage numbers
are high
TabAtkins: I agree, that level of usage means it's part of the Web,
in effect
astearns: I haven't read through entire backlog, but we resolved not
to specify them *yet*
SebastianZ: At some point there was a resolution to not specify them,
but couldn't find the reasoning behind it
SebastianZ: Probably because -x and -y are physical longhands?
fantasai: We have the same issue with bg-position, so we have to
resolve it somehow
fantasai: So given usage numbers I think we should resolve to add
-x, -y, -block, and -inline
fantasai: And then add repeat-block repeat-inline keywords
SebastianZ: Agree
<TabAtkins> +1
astearns: So proposed resolution is we'll add x,y,block,inline
longhands, and the repeat-block and repeat-inline keywords
to the shorthands
astearns: Objections?
RESOLVED: Add x,y,block,inline longhands, and the repeat-block and
repeat-inline keywords to the shorthands
Media Queries Con't
===================
Consider `@media supports()`
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/9375
bramus: For @import we have a bunch of conditions we can tag onto it,
MQs and supports()
bramus: You can use @supports in your stylesheet, but we wanted a way
to add it into <link rel=stylesheet>
bramus: Proposal's evolved a bit. Currently proposal is a
`condition=""` attribute
bramus: This new attribute is future proof; if we just add <link
supports> then what about the next condition
bramus: I was thinking the syntax would be `condition="supports(...)
and media(...)"`
bramus: You have the same problem as with any new attribute, browsers
that don't understand the attr will ignore it and apply the
stylesheet
bramus: So followup, maybe `media=""` can accept these? And we can
add `condition=""` as a synonym?
miriam: Some context, we discussed at TPAC in meeting with WHATWG
miriam: We'd proposed extending `media=""` to accept all import
conditions
miriam: The WHATWG did not like that
miriam: Advantage of using `media` is that it would be backcompat, it
already fails if it's got unknown stuff
miriam: They'd prefer us to think about the future; it's only a small
polyfill to work around this for now
miriam: So new proposal is the new attribute. I think Bramus's idea
of a new generic condition attribute is fine.
miriam: No need to define what goes into it, it should match @import
miriam: Taking the <import-condition> syntax, which is already defined
emilio: I'm not totally opposed to new attr, but it feels like a much
bigger endeavor
emilio: media is used on more things, <meta>, <source>,e tc
emilio: I guess we can figure out if all of those need condition or
can be just media, but that feels weird
emilio: We also need to figure out how media and condition interact
emilio: And iirc, media attribute ends up in CSSSTyleSheet.media in
the OM
emilio: So do we need to reflect condition into the stylesheet? Only
if it's an MQ?
emilio: Seems okay in theory but it's a lot more work
emilio: than just reusing media
TabAtkins: I think that the 'condition' attribute is fine
TabAtkins: agree that re-using <import-condition> is right
TabAtkins: a) everything that takes media= should take condition= ;
no reason to restrict
TabAtkins: b) interaction between media= and condition= should be
imo, in presence of condition= media= is ignored
TabAtkins: that helps with the polyfill, because you can put a
guaranteed failing media condition in
TabAtkins: c) for media query in stylesheet, don't think it's
particularly needed. We can always add later if we feel
it's necessary
<emilio> wfm
bramus: I think my concern is addressed by Tab's (b)
bramus: But then why don't we just upgrade media= to accept import
conditions?
astearns: I can see the parsimony of just updating media=
astearns: But we can take this as designing a well-rounded condition
attribute without worrying about the cruft of media=
TabAtkins: Parsing of raw media query is pretty weird, because of
media types
TabAtkins: having new attribute with media() function helps
TabAtkins: Also addresses question of reflection into stylesheet
TabAtkins: If in media= have to say how it reflects, but new
attribute can just not
fantasai: Disagree with Tab about media vs condition
fantasai: Think both should apply when both specified
fantasai: But think we can add a keyword to media that says "go look
at condition=", which'll be invalid on downlevel clients
fantasai: I think if someone wrote an MQ they shouldn't have to
duplicate that into condition=
fantasai: We've also had discussions about @layer
fantasai: It's not a conditional, and it has to be reflected in the OM
fantasai: So would this new condition attr take in things like that?
fantasai: Or would that have to be an additional attribute?
miriam: This would not take layer()
miriam: Just the import conditions
miriam: WHATWG was very open to new attributes for things like @layer
miriam: We wanted to solve this first so you can add layer= *and*
have a way to make it fail if layer wasn't supported
miriam: This solves that, you can fail it with a support query
miriam: That leads into my next, I agree with Elika on how media/
condition should interact
<dbaron> also +1 to fantasai's proposal on interaction
miriam: Main consideration for emilio's q about putting this on more
media= things
miriam: If we define this as <import-condition>, which is defined
around stylesheets, will this be an issue later?
miriam: Like an import condition that makes sense for images,
specifically?
miriam: And is that even an issue? Or would you just ignore/fail on
the other elements?
TabAtkins: I think we'd just fail queries that didn't apply to that
type of import, yeah
miriam: Would we define these new kinds of queries in
<import-condition>?
TabAtkins: Maybe. Or we'd extract the grammar to an independent spec
and just ref it in @import
bramus: I'm less sure about media= and condition= both declared
bramus: I see authors moving to using only condition= with media()
bramus: So for migration/polyfill I lean toward Tab's idea, but I
need to give it more thought
astearns: I think we can open separate issue
TabAtkins: Yeah, I don't feel strongly about this, but would like to
discuss it a bit more. Do it off the call
fantasai: I see authors probably still using media= just because it's
shorter, why type more
astearns: Do we have an issue about other elements using media=? Or
should we just resolve it today?
fantasai: Well we don't control HTML but can make a proposal.
fantasai: Thinking about what would be a reasonable resolution...
fantasai: Can resolve to explore condition=
fantasai: Can definitely resolve to reject media=supports()
astearns: Proposed is we solve the use-cases with a new condition=
attribute that takes <import-condition> syntax
<fantasai> also @media supports(), which is the title of the issue
<fantasai> 100% not accepted
astearns: Any objections?
RESOLVED: Add a new condition= attribute that takes
<import-condition> syntax
TabAtkins: Should we resolve to reject @media supports()?
astearns: Yeah. objections?
RESOLVED: Do not add `supports()` to @media
Received on Thursday, 14 December 2023 00:55:45 UTC