- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Apr 2021 19:29:08 -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.
=========================================
CSS Snapshot 2021
-----------------
- Please start gathering thoughts and content for the 2021 snapshot
on github in issue #6243.
CSS Fonts
---------
- RESOLVED: No change to name; stay with size-adjust (Issue #6114:
bikeshedding name of size-adjust descriptor)
- RESOLVED: Add from-font keyword to font-size-adjust [to Fonts 5]
(Issue #5539: font-size-adjust: auto)
- fantasai will add details to issue #4818 (oblique angle for
vertical text with text-combine-upright) about the difference in
visual presentation this would introduce between regular italics
and this property. Discussion will continue on GitHub
- The group will wait for more evidence of author demand before
taking up issue #6104 (Consider 'extends' descriptor to reduce
duplicate declarations)
CSS Inline
----------
- RESOLVED: Fonts with negative line gaps are clamp at 0 (Issue
#5064: The web de-facto requires nonnegative line gap
metrics in fonts)
CSS Ruby
--------
- RESOLVED: Undo previous resolution. Treat replaced elements with
an internal ruby display value as if they were inline at
used value time (Issue #6000: Replaced annotation
containers and base containers are nonsensical)
Selectors
---------
- RESOLVED: Close no change (Issue #6237: Add a :media pseudo-class,
to match the set of elements matching the media
pseudo-classes)
- Issue #6250 was filed to better define if Seek returns as playing
or paused.
CSS Images
----------
- RESOLVED: image-set should act like srcset attribute with applying
resolution (Issue #6241: image-set() resolution should
be applied on-top of, not instead-of the natural image
resolution)
Counter-Styles
--------------
- RESOLVED: Switch to using 25AA (Issue #6200: counter-style square
symbol (0x25FE) is bad)
Contain
-------
- Issue #6175 (What is the migration path for Container Queries?) is
reaching a conclusion to allow a user to test a container query
property value pair. The final details will be worked out on
GitHub.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Apr/0005.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
David Baron
Tab Atkins-Bittner
Christian Biesinger
Oriol Brufau
Tantek Çelik
Elika Etemad
Brandon Ferrua
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Jonathan Kew
Peter Linss
Rune Lillesveen
Alison Maher
Myles Maxfield
Tess O'Connor
Morgan Reschenberg
Florian Rivoal
Miriam Suzanne
Lea Verou
Greg Whitfield
Scribe: dael
Rossen: Hi everyone. We are going to get going in a couple minutes
florian: The thing on issue #13 is a followup on something we've
discussed earlier so it would be nice if we could move it
earlier. Easy followup if it's fresh in mind.
Rossen: I was maybe have this after the fonts items. I wasn't sure
if it was ready
florian: We can timebox to short and if it's longer we can get back
to it
Rossen: Alright. Let's see if we can get through fonts first
Rossen: It is 9:02 in PT. Time to start
Rossen: As usual, I wanted to ask for any additional agenda changes.
Noted the one from florian
Rossen: Anything else?
CSS Snapshot 2021
=================
github: https://github.com/w3c/csswg-drafts/issues/6243
florian: This is not for deep discussion now. Last year we said we'd
do snapshot early, failed, and released in December. Wanted
to bring attention we should start thinking about it so we
can release before Dec. Suggested mid-year would be nice
florian: Start thinking, filing issue. We'll get back to it soon
Rossen: Thank you for not forgetting and drawing our attention to it
Rossen: In light of agenda I propose we move forward and everyone is
encouraged to add issues or ideas to that issue. I will
bring it back once a month and we can check in until we
publish
CSS Fonts
=========
bikeshedding name of size-adjust descriptor
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6114
chrishtr: One option is keeping the name. I think fantasai prefers
that
chrishtr: Another option is font-scaling or font-scaling-factor
chrishtr: Opinions?
fantasai: I prefer original name
chrishtr: I'm okay with all of those
chrishtr: jfkthame and myles weighed in
jfkthame: I prefer name with scaling but can live
leaverou: What about scaling-factor? font- is not needed if this is
a descriptor in @font-face
fantasai: Proposed name is size-adjust which ties into font adjust.
Work a bit differently but do exactly the same thing
fantasai: size-adjust description on @fontface gives you descriptor
to adjust font size by that much. font-size-adjust
property takes a number of how big to scale to match
x-height
fantasai: Proposals to expand beyond x-height to try and get fonts
to match and normalize on metrics you request.
fantasai: Both scale used size instead of impacting computed
fantasai: Other reason was I figured pretty accurately represents
what you're trying to do when you spec a font and size
Rossen: Way I read the thread most folks lean toward font-scale as
rename. Proposal by jfkthame and okay by chrishtr and myles
Rossen: In description you used, fantasai, you used 'scale' 80% of
time and 'adjust' once. font-scale sounds like pretty
awesome alternative. Should we try and resolve on that?
plinss: If we have existing property that does same it makes sense
to keep the name
jfkthame: What troubles me is it does it in a different way and the
value given has a different meaning. That's source of my
unease with keeping names close
fantasai: There's syntax valid in font-size-adjust and ones in
font-adjust and don't overlap. If we add percent it should
do the same. If we want a feature that's where it should
go and size-adjust would be a subset of font-size-adjust
<smfr> there’s also [-webkit-]text-size-adjust
Rossen: We can do one of two things. Hearing a split. We can straw
poll between size-adjust and font-scale and take the result
<fantasai> ok with a straw poll, has opinions but not gonna block
chrishtr: sgtm
<jfkthame> likewise
<Rossen> A - size-adjust
<Rossen> B - font-scale
Rossen: options ^
Rossen: Please cast your opinions, A or B, or the order you prefer
<fantasai> A
<myles> abstain
<plinss> a
<jfkthame> B
<Rossen> B A
<rachelandrew> A
<chrishtr> AB
<dholbert> B
<astearns> abstain
<smfr> B
<Morgan> abstain
<futhark> abstain
<florian> abstain
<cbiesinger> abstain
Rossen: I love that abstain has a and b
Rossen: This is very non-conclusive
chrishtr: A bit more B than A
Rossen: 5 and 5. That's not enough for consensus
Rossen: Since there's no consensus, I don't hear strong reason to
change
chrishtr: Can I make suggestion? Is there anyone who would object to
leaving it the way it is?
Rossen: That was going to be my proposal too
Rossen: And if needed this can be brought back
Rossen: Proposal: No change to name, stay with size-adjust
smfr: No objections but then we have size-adjust font-size-adjust
and prefix text-size-adjust which is things with similar names
doing different things
myles: Very different things
Rossen: Based on WG votes we don't see to want to change strongly.
Forcing a resolution and if people have strong opinions we
can bring it back
Rossen: Are there objections?
RESOLVED: No change to name; stay with size-adjust
Rossen: Please engage in issue if want further discussion
CSS Inline
==========
The web de-facto requires nonnegative line gap metrics in fonts
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5064
myles: Pretty straightforward. Browsers do it but not in spec.
myles: If font says it has negative line-gap it's clamped at 0
Rossen: Anyone with different opinion why this shouldn't be the case?
Rossen: Objections to Fonts with negative line gaps are clamp at 0
florian: Question, have you checked this is true of print formatter?
myles: No, haven't checked. FF, Chrome, and WK do it
florian: Sounds like a good idea, wondering if done in print and how
we deal with compat. Maybe just suggest they do it as well
Rossen: This is why we have standards
RESOLVED: Fonts with negative line gaps are clamp at 0
myles: I think metric is within inline spec so I think this issue
should be parented under that spec
Rossen: Sure
CSS Fonts (continued)
=====================
font-size-adjust: auto
----------------------
github: https://github.com/w3c/csswg-drafts/issues/5539
myles: Right now font-size-adjust takes a number. Seems hostile to
authors. Believe use case is I want my fallback text to match
relative size of primary. If author doesn't know aspect-ratio
of primary text they have to figure it out and hard code it
myles: I think that's a problem. Don't have strong suggestion to
fix. One would be add keyword like from-font or auto that's
use aspect-ratio from primary font
Rossen: Do you have a...seems like thread is leaning for from-font
instead of auto. Should we resolve on from-font?
Rossen: Objection to adding from-font keyword to font-size-adjust?
RESOLVED: Add from-font keyword to font-size-adjust
Rossen: This is fonts 4? or 5?
myles: Probably 5. In general new should be 5
<fantasai> +1
oblique angle for vertical text with text-combine-upright
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4818
Rossen: Fairly straightforward explanation. Proposed resolution is
in case of vertical text layout when we use
text-combine-upright which introduces horizontal text skew
should be to combined characters
fantasai: Complication, if you have oblique glyphs they won't go
downwards, but to the side. I think a little tricky for
that reason. Wanted to bring it for discussion. I think
what probably makes sense is we need another property that
explicitly does skewing on the line
fantasai: Not sure which way to do. Could be consistent with real
itals or fix stuff on line
Rossen: Then my proposal is continue on GH there. It doesn't sound
like what you mentioned was already discussed to point where
we can resolve. Behavior is dependent on your prop for skew
property I would prefer to have the discussion when ready
fantasai: Not dependent but needs consider. Main thing is do we want
to be consistent with italics or have real and fake
italics be different
Rossen: Important decision. Hope was in absence of this we could
resolve but you bring up a good point. This will introduce a
fairly apparent difference which will not have a way for
authors to combat it
Rossen: If this was the case I propose we wait on resolving until
we've resolved skew and how it works
Rossen: What do you think fantasai?
fantasai: I don't think we're ready to resolve, but doesn't depend
on skew. We can go back to issue, but can't just be me
talking about it. Been out there for a while
Rossen: Can I ask you to link the skew issue if it's not linked and
we'll bring back when ready for more discussion?
Consider 'extends' descriptor to reduce duplicate declarations
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6104
fantasai: The @counter-style rules can get complicated. @extend lets
you go off previous definition. As @font-face gets more
complicated might be might to have same mechanism so a
font-face rule can extend another one and add some
descriptors
myles: I think I agree with astearns comment where we should wait
for things like Sass to come up with it. A bit early to add
because don't know we need it
astearns: And a lot of things we're adding to complicate rule are
for specific fonts and not really shared. Don't want to
get to state where someone uses a value they tested on one
font on a lot where they don't know correct
fantasai: Yeah. When have variable font you'll have a bunch of
common stuff to core. might want to set some things to set
named variants
astearns: Agree probably useful for variation fonts, but should wait
until we know it'll be used
leaverou: May not have seen seen complaints because authors copy/
paste generated @font-face rules. Duplication is there
<fantasai> +1
myles: I understand we're discussing this because adding rules. If
we give them time to start using new things we'll hear noise
about needing this. If not necessary we won't
Rossen: Hearing folks leaning toward waiting to see how and when
it's needed
Rossen: We'll put this on pause until have stronger signals
CSS Ruby
========
Replaced annotation containers and base containers are nonsensical
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6000
Rossen: Let's timebox to 5m
florian: We discussed that it didn't make a whole lot of sense for
replace elements to have ruby-base or ruby-text. xidorn has
pushed back
florian: Would rather we treat as inline replaced elements. Invokes
rest of box fixup. Anonymous parents still generated. This
would be simpler and is what happens with tables already.
Replaced elements in table only get to be inline and
wrapped into table parts
florian: I think emilio also argued for that.
florian: Given the pushback and we do this for tables I think this
is a good idea. Saying they're treated as inlines makes
sense
florian: If we do that I would also propose we move this into the
display spec instead of being in tables and ruby. Display
talks about layout internals and could say when you try and
apply to replaced element it's treated as inline
florian: Any problems with that?
Rossen: Did anyone follow it?
Rossen: florian since there's no issues or comments, proposal?
florian: Proposal: Undo previous resolution. Treat replaced elements
with an internal ruby display value as if they were inline
florian: at used value time
Rossen: Would this align closer with table?
florian: Yes, closer with tables on Mozilla's current impl
Rossen: If I have display:table on the replaced element it becomes
inline?
florian: display: table-row or -cell they're inline. For outermost
like display:table or ruby this is handled.
florian: For internal you're treated as inline
Rossen: Right. Awesome
Rossen: Additional comments or objections?
RESOLVED: Undo previous resolution. Treat replaced elements with an
internal ruby display value as if they were inline at used
value time
Rossen: Did previous one make it into spec?
florian: Not yet
CSS Images
==========
image-set() resolution should be applied on-top of, not instead-of
the natural image resolution
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6241
Rossen: Is emilio on?
Rossen: I'll push this
Selectors
=========
Add a :media pseudo-class, to match the set of elements matching the
media pseudo-classes
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6237
TabAtkins: As of a week or two ago had 2 pseudo classes that applied
to media. playing and paused are mutually exclusive. All
elements not playing are pause.
TabAtkins: We agreed on edits from hober adding additional media
pseudo-classes to match additional states. I realized
this property that you could always select on one
pseudo-class no longer applied. Example: muted. Select
all not muted you can't use Not muted because selects
everything on page
TabAtkins: Suggestion to help authors with this which is
pseudo-class to just select media elements
TabAtkins: A few objections in issue. leaverou pointed out requests
in the past to select MQ as selector so it mixes into
selectors and name for that would be media
TabAtkins: emilio pointed out we have audio and video and now that
we have :is it's not hard to get the same effect as you
had before is pseudo-class
TabAtkins: Both are reasonable. Don't know if enough to sink it. I
still think might be valuable to do something in this
realm. What do others think? Not sure which way to go
florian: Question. When you use pause it only gives you paused media
elements?
TabAtkins: Yeah. Every single media elements is either playing or
paused. But because no non-muted pseudo-class we no
longer have that property
florian: And can't solve by adding opposite of those introduced?
TabAtkins: Could. Feels weird to add explicitly negated version when
we have pseudo class negation
florian: But not same meaning
TabAtkins: Yeah.
hober: I think TabAtkins is right it's a real problem. Sympathetic
to emilio point that :is audio|video is enough. Worry it's
not future proof. If we add another media feature sites will
not match the new ones
hober: Slightly prefer adding a new pseudo-class but could live with
leaving it to :is
hober: Don't care for adding negated pseudo-classes for all the new
ones. Exploded number in a way that feels distasteful, but
it's an aesthetic preference
TabAtkins: I think at this point I'm okay going with emilio and if
we introduce more media elements we can revisit this so
we don't have to negotiate future-proofing with media
pseudo-class
leaverou: I wanted to ask if we have sufficient evidence that
authors want to target all media elements in a way.
Stylesheets trying to target non-muted media elements?
Feel it would be all video or audio
<fantasai> +1 leaverou
hober: One use case is in user stylesheet. Looking at a website,
something obnoxious happening and I can't find it to make it
stop
Rossen: Good use case.
<bkardell> it would be useful in extensions too
emilio: Wanted to mention there is precedent for explicit negation
with readwrite and readonly. You could argue that for
website authors having media pseudo-class...argument hober
made makes sense but can flip. New media elements would have
selectors that didn't match start matching. Can go both ways.
emilio: I don't care either way, but there is precedent for negation
TabAtkins: That precedent exists in same way as playing and paused.
Explicit different states. If name is not-x is what feels
weird
TabAtkins: Think we're reasonably agreeing to close no change and
rely on :is
<fantasai> +1 to close no change for now
emilio: Sounds good
<leaverou> +1 to close
Rossen: When seeking will one apply? both? none?
TabAtkins: I think playing
hober: Buffering and stalled playing still matches. I don't remember
if new spec text says for seeking. Might be good followup
TabAtkins: Yeah, could use clarification
<tantek> possibly related: we have pseudo-classes for partially
loaded images right? (that are still loading)
<TabAtkins> OH wait lol, we just have a :seeking pseudo-class now
<TabAtkins> So, uh, obviously that's the one that matches when
you're seeking
fantasai: On queue to agree with leaverou and emilio. Close no
change. If we need clarification add resolution
hober: Clarification shouldn't be always one or the other for
seeking. Can used seeker to search playing or paused. Need to
say unlike buffering or stalled you might be playing or
paused when seeking
Rossen: Seek has no change to the last known state of playing or
paused. Fair?
hober: I think so
Rossen: Proposal: Close no change
hober: Can we also add action to write clarification?
ACTION hober add text for Seek has no change to the last known state
of playing or paused
<fantasai> filed issue for hober at
https://github.com/w3c/csswg-drafts/issues/6250
RESOLVED: Close no change
CSS Images
==========
image-set() resolution should be applied on-top of, not instead-of
the natural image resolution
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6241
emilio: Matches existing impl. Basically spec says if you omit
image-set resolution then you use natural image resolution
emilio: If you spec image-set resolution it overrides whatever
resolution image has
emilio: Allows to figure out if image has native resolution. Not
amazing. Chrome and WK apply image resolution and then
image-set resolution. Seems reasonable and sensible
emilio: So this should agree with existing impl
TabAtkins: Happy to resolve on agree with existing impl. I'm not
sure how this is supposed to work from reading thread. Do
not understand multiplying resolution by exif resolution
gives you something usable
emilio: It's a cross-origin info leak
TabAtkins: I suspect something more subtle is happening than I
understand. Feels ridiculous. But we'll figure it out
emilio: If you find out what it is that's great
TabAtkins: I'd like us to match so happy to resolve
TabAtkins: Proposal: image-set should act like srcset attribute with
applying resolution
Rossen: Objections?
RESOLVED: image-set should act like srcset attribute with applying
resolution
Counter-Styles
==============
counter-style square symbol (0x25FE) is bad
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6200
TabAtkins: One of the easy cases we need to resolve on
TabAtkins: Count spec says build in square renders something like
25FE codepoint. Problem is that has emoji presentation.
Presents as an emoji rather than a character with text
color
TabAtkins: Also apparently a little larger
TabAtkins: Suggestion of better character
TabAtkins: 25aa
TabAtkins: Switch in spec to 25aa which is not emoji so renders more
correct and better size
TabAtkins: GH treats 25aa as an emoji which is not what borwsers do.
Confusing but should be fine in practice.
Rossen: Any other ideas of a character? If not, objections?
RESOLVED: Switch to using 25AA
CSS Contain
===========
What is the migration path for Container Queries?
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6175
miriam: Talked about this last week
miriam: Went to thread.
miriam: Proposal to add a container function to supports similar to
selector in that you can test a container query property
value pair
miriam: Also it would be good to get consistency on how unknown
functions or tests are handled
miriam: Other proposal is unknown supports conditions evaluate as
unsupported
Rossen: Thank you
Rossen: With that proposal, are there any other opinions where?
TabAtkins: Sounds good
miriam: Proposal 1: Any unknown supports conditions should evaluate
as unsupported
TabAtkins: Rephrase: unknown support conditions should work the same
as unknown media conditions
florian: Clarification, they don't evaluate to false which is a
weird not bool
TabAtkins: Evaluate to false at top value. Unknown property as
unknown but it doesn't define top level unknown so
becomes false
emilio: Do we want @supports NOT [unknown] true or false?
TabAtkins: Same as MQ for unknown things. NOT [unknown] is unknown
miriam: Don't think that works well
emilio: Right. Not great. Can't use @supports NOT container because
will never match. Returns true for browsers without container
miriam: Want it to evaluate true when negate it
TabAtkins: There's unknown which is syntax we don't understand and
syntax that's false because you don't impl the thing yet
miriam: To be backwards compat we need unknown to evaluate true when
you negate it so it works with browsers that don't
understand container
dbaron: Argument that @supports should be different for MQ. Unknown
@supports is like an unsupported feature
<dbaron> (And I think I was agreeing with miriam.)
<miriam> Yes, @dbaron - that's exactly what I was trying to get at,
thanks
Rossen: We have folks starting to drop off
Rossen: Sounds like we want to take this back to the thread, flesh
it out, and bring it as first topic this week
TabAtkins: Thread got confused with impl doing weird things. We're
past that, just need to discuss on this
Rossen: We're a couple minutes overtime. Thanks for hanging around
Received on Wednesday, 28 April 2021 23:29:50 UTC