- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Jan 2021 19:32:20 -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 Cascade 5
-------------
- RESOLVED: Rename @layers to @layer (Issue #5855: Rename @layers to
@layer)
Selectors
---------
- RESOLVED: Convert at parse time (Issue #5847: Define how "legacy
aliases" work on selectors)
CSS Pseudo
----------
- RESOLVED: Drop caret-color and cursor (Issue #4100: Painting of
the cursor and the caret with highlight pseudos)
- RESOLVED: Exclude word break and no break spaces on either side of
the letter (Issue #5830: Fine-tuning ::first-letter
punctuation pattern matching)
- RESOLVED: Exclude dashes and opening punctuation (ps and pd in
unicode) from following (Issue #5830)
- RESOLVED: Include symbols when looking for first-letter (Issue
#5099: ::first-letter should include currency)
- RESOLVED: Align with chromium behavior for ::first-line and
line-height (Issue #2282: ::first-line and line-height)
- RESOLVED: ::first-letter pseudo element is closed at the end of
the line even if the content that would otherwise be
part of it is wrapped to the next line (Issue #2254:
Multi-line ::first-letter)
Sizing & Contain
----------------
- RESOLVED: Align the behavior of auto sizing for size-containment
with that of ResizeObserver (Issue #5668: Revisiting
auto-sizing when size-containment applies)
CSS Contain
-----------
- The next step for content-visibility: hidden-matchable property
(Issue #5595) will be TAG review to evaluate the group's
questions about if matchable will work with browser settings
like reader-mode and if matchable belongs in CSS or in markup.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jan/0003.html
Present:
Adam Argyle
Rossen Atanassov
Christian Biesinger
Oriol Brufau
Tantek Çelik
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brad Kemper
Johnathan Kew
Una Kravets
Vladimir Levin
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Myles Maxfield
Morgan Reschenberg
Florian Rivoal
Cassondra Roberts
Jen Simmons
Miriam Suzanne
Lea Verou
Scribe: dael
Rossen: Let's get started
Rossen: We have a full agenda. As usual I wanted to ask if people
have any extra agenda items.
Rossen: Only reminder to give is about the upcoming F2F in February.
Rossen: We have started to add the milestones to open issues. Feel
free to mark agenda+ F2F for anything you want for the F2F.
Rossen: Other details are in the private list
CSS Cascade 5
=============
Rename @layers to @layer
------------------------
github: https://github.com/w3c/csswg-drafts/issues/5855
Rossen: Topic explains it. fantasai anything to add?
fantasai: Nope
<florian> Seems fine
Rossen: Any feedback or objections to renaming @layers to @layer?
<miriam> I'm in favor
<leaverou> in favor
Rossen: Hearing no objects and seeing IRC support
RESOLVED: rename @layers to @layer
Selectors
=========
Define how "legacy aliases" work on selectors
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5847
emilio: Have a couple places where we define a selector where for
legacy reason it can be implemented as alias but no
definition of that.
emilio: Came up as I did compat work on other pseudo classes.
emilio: Compat can change what needs to be done but seems as if we
should have guidance on how this should work
emilio: afaict two options are keep zeroizing the non-standard or
convert them at parse time
emilio: Some inconsistencies in Blink. Gecko should always turn it
into the standard at parse time. I think that's what we do
for properties in general
Rossen: Proposal is align more closely with converting at parse time
Rossen: Questions or should we resolve on that?
Rossen: I'll take silence as no
Rossen: No comments or objections?
Rossen: I see support in GH from TabAtkins
RESOLVED: convert at parse time
Math & CSS Fonts
================
Solution to mixing text and math fonts in a document
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5534
Rossen: Do we have folks to discuss these MathML issues?
Rossen: fantasai you added this to agenda a while back
Rossen: Silence I will take as not ready.
Rossen: We'll backlog at this point and remove agenda+
CSS Display
===========
math/inline-math
----------------
github: https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-745563829
Rossen: Is this something we can resolve now and move forward and if
anyone has issues we can reopen
fantasai: Mats proposed that display:math outside of MathML should
make element behave as an em row. I agree with Mats but
Fred thinks more complex to implement. Mats had
implemented and didn't think it was complicated
Rossen: Who was pushing back on complexity?
fantasai: Fred
emilio: Also issue of display:math doing magical things depending on
which element. Is there a different issue on that? That's
the other concern Mats had
fantasai: Should be a different issue on that one
emilio: I don't mind filing it, no need to discuss right now in
order to discuss right now
Rossen: Doesn't sound like we're ready to discuss
fantasai: I can't present Fred's PoV. I can point you to the
comments. I agree with Mats so could represent that.
Rossen: Let's push this on back to the backlog as well
Rossen: Perhaps these can be F2F topics
fantasai: You need to schedule them when the people you want to show
up will show up. It's been end of agenda so no one knows
to call in
astearns: I pinged everyone involved and didn't get a response
Rossen: Likewise. It's not for lack of trying
Rossen: There are going on the back burner and those that care can
bring them back
CSS Pseudo
==========
Painting of the cursor and the caret with highlight pseudos
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4100
fantasai: florian asked what happened with multi highlights and
different caret values. Which one wins. Top or top
non-auto. Top most non-auto makes more sense I think but I
don't know. Is anyone planning to implement these
properties?
Rossen: Regardless of plan to implement we should be able to define
expected behavior. If top-most non-auto makes most sense we
can resolve and when people impl if it's not the right
choice we can discuss again then
florian: Alternative could be if no one thinks this is good to
implement we could drop from list of elements that apply to
this pseudo element. These were added because not layout
effecting. But if there's no interest we could drop them.
Rossen: Choices are drop it or top-most non-auto
GameMaker: I wasn't on the call earlier but I recall reading notes
about issues with this and grammar and auto-spell check
because loading resources could be a security issue
GameMaker: Maybe didn't understand discussion, but thinking that
could be a reason to drop. In my implementation I haven't
looked at doing cursor or caret. Definitely would be more
complicated to do. I'm in favor of just dropping cursor
and caret
<tantek> +1 to dropping. seems to add complexity for theoretical
reasons
Rossen: Anyone want to keep those?
florian: Not a strong want but it seems security only applied to one
of the two. Caret color won't load resources
fantasai: But if no one wants to implement and there's no strong
usecase we should drop
<tantek> I'd be in favor of only reconsidering them if an
implementor felt compelled to try implementing it (for
whatever reason)
Rossen: Objections to dropping caret-color and cursor?
RESOLVED: drop caret-color and cursor
CSS Sizing & Contain
====================
Revisiting auto-sizing when size-containment applies
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5668
vmpstr: A little background. We have content-visibility:auto Way it
works is when element goes offscreen we add size containment
and when it's on screen we remove. Can change the scrollbar
size which is undesired. Added constrain-intrinsic-size to
manage this. Works great as a placeholder because gives some
size even when size containment applies.
vmpstr: Problem is it's hard to know the right size so scrollbar can
still jump. When element is on screen as it rolls offscreen
browser knows size that would cause scrollbar not to jump.
There is a value it could take. Browser knows but it's not
exposed
vmpstr: I think script can get an estimate
vmpstr: Proposal is add an auto qualification to
contain-intrinsic-size which is when size containment is
first applied and when content has been previously rendered
remember that size and use it as the value. Else use
placeholder
vmpstr: Daniel and Christian raised some points that it adds
dependency on sequence of steps.
vmpstr: Wanted to bring to group. Hoping there's a solution that
doesn't involve script. Maybe not this exact proposal, but
this is what I have
TabAtkins: Point about non-determinism about exactly when size is
recorded, while technically true it's a cost we eaten
with animations. Style depends on exactly when it started
so you know how far in animation you are. Since we've
eaten that cost for animations I don't see why not here
unless we think that was unavoidably broken
TabAtkins: We should think about this the same as animation start
smfr: Slightly different proposal is specify this exactly same as
ResizeObserver. Timing is well defined. Write the spec so you
get the same behavior as if you registered a resize on it and
that's the same size as you'd get with snapshot
<TabAtkins> smfr's idea makes sense to me as well
<TabAtkins> it's what you'd get if you did this by hand anyway
vmpstr: Good idea. Question is when do we snapshot. If you add size
containment and change another style I guess you first
process size containment and snapshot at that time?
smfr: I think you would use size from the most recent event loop
steps where your resize observer would have fired and given an
answer. Might be loop before a style change that effects
containment
smfr: That's the last thing you saw on screen
vmpstr: Makes sense
chrishtr: ResizeObserver is when content-visibility content is
unskipped, right?
vmpstr: On the contents of the element. On the element itself the
observer would still fire
chrishtr: So a polyfill would put it on the element and when it
fires set contain intrinsic size on that. And smfr
proposal is do that without any script
vmpstr: Pretty much. I've seen a polyfill that does that. I'm not
sure what to do with padding and margins.
chrishtr: ResizeObserver allows you to observe different boxes
vmpstr: Then yeah
chrishtr: What if it was independent of content visibility. It
restricts to the contain-intrinsic-size property
vmpstr: Content visibility was motivation. Proposal is change to
contain-intrinsic-size to save off the value
chrishtr: Only do when size containment wasn't present
vmpstr: Right. And just snapshot at the time size containment starts
being applied
chrishtr: So if size containment isn't present that size is
automatically reflected into contain-intrinsic-size used
value
Rossen: Hearing alignment on proposal from smfr to align with
ResizeObserver. Are we happy with that and then will work on
additional details in the issue?
Rossen: Objections to align the behavior of auto sizing for
size-containment with that of ResizeObserver
RESOLVED: Align the behavior of auto sizing for size-containment
with that of ResizeObserver
CSS Contain
===========
Proposal: content-visibility: hidden-matchable
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5595
Rossen: This issue can take a lot of time. Let's try to spend no
more than 10 minutes on this.
jarhar: Hello everyone. Proposed content-visibility:
hidden-matchable property. I added responses on GH to the
questions from last time. Wanted to know if there are
additional issues and if responses on GH suffice
fantasai: Once concern is if the control should be in css or in
markup. Might be good to ask TAG about that.
fantasai: Other than that, main question is defining details of what
operations can and can't trigger matching
<tantek> +1 to fantasai's concern, "matchability" feels like an
expression of more semantically relevant content and thus
may belong more in markup rather than in styling.
smfr: I think chris's last comment is a good summary of my
discomfort. I think TAG feedback would be good. There are
features in UAs that vary and this proposal has impact on
those features. TAG level discussion would be great
<tantek> agreed with the reader-mode and screenreader semantics
concerns comments in the issue
Rossen: I'm scrolling through open TAG issues. I see the match event
open from jarhar. Is there another active one with TAG?
jarhar: I believe I do have a TAG review open.
jarhar: Issue #511 on TAG
<Rossen> https://github.com/w3ctag/design-reviews/issues/511
Rossen: I believe that's scheduled to discuss during TAG F2F in a
couple weeks
chrishtr: And the concern from smfr has not been yet discussed in
TAG correct?
jarhar: Not that I know of
Rossen: We have this issue cross-linked to TAG review. As the review
with TAG we'll have the CSS issue as well for more context
Rossen: What I'm hearing right now is a pause on this issue until we
have TAG review
Rossen: Then bring it back here
Rossen: Also heard concerns from smfr. That's the summary. Is that
fair?
chrishtr: smfr you said you have discomfort. I guess not swayed by
our arguments. But if TAG doesn't think it's a big problem
you're okay?
smfr: If TAG is okay I'm okay. For example, I got pinged by devs
about what are a11y considerations for hidden-matchable. There
is ambiguity around a11y and reader-mode. Prefer to resolve
but understand why it exists
chrishtr: It's potential for dev confusion?
smfr: Dev and user. They ctrl-f in reader mode but spotlight doesn't
find it and that's confusing
<tantek> +1 smfr
chrishtr: So we'll take it to TAG
chrishtr: Your comments, fantasai, are good to consider. We should
work that out once we have consensus on smfr's issue
Rossen: Cool. With that let's move forward
<jensimmons> We definitely don't want to create new CSS where the
a11y best-practice is confusing and unknown. There
should be clarity.
<tantek> +1 jensimmons. agreed that's a good general methodology
CSS Pseudo
==========
Fine-tuning ::first-letter punctuation pattern matching
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5830
fantasai: Problems raised in terms of matching ::first-letter.
Example in an issue a " b". When we added ability to
include whitespace we chose to include word spaces
fantasai: Problem is we aren't considering what's on other side of
punctuation. If spec only used to separate makes sense,
but not always. We're picking up punctuation that should
be attached to word following. That's a problem.
fantasai: I think exclude word and no-break spaces on following side
of letter. Maybe leading side but definitely following
Rossen: Feedback on this one?
Rossen: No feedback on it, I guess
<tantek> +1 reasoning makes sense
fantasai: Objections to making word and no break spaces not included?
jfkthame: No objection but thinking it should be same both before
and after letter since that's less confusing. If they want
a word space they need to use a different character no
matter what
fantasai: Happy to exclude from both sides for consistency. word
space isn't the correct character to use typographically
anyway
Rossen: Prop: Exclude word break and no break spaces on either side
of the letter
Rossen: Objections?
RESOLVED: Exclude word break and no break spaces on either side of
the letter
fantasai: There are several classes of punctuation. One we don't
want to include is opening punctuation after first letter.
first-letter than { doesn't make sense to include. In
European language there's spaces so it doesn't matter
much. For other languages there is no such thing and we're
trying to get first letter. We have opening punctuation
class and that should be excluded
fantasai: Two ambiguous classes that are common where I don't know
how to handle cleanly. Least we can do is exclude the
opening punctuation
Rossen: Any feedback?
<tantek> +1 on excluding opening punctuations
bradk: Sounds reasonable
fantasai: Similar case with dashes. Not quite sure the conventions
for dash after first letter. I suspect we want to exclude
on following side, but I'm not entirely familiar. On
leading side long dashes mark quotations. Not sure on
following. Inclination is also exclude dashes from
following punctuation
<bradk> I don’t have opinion about dashes
Rossen: One resolution here?
fantasai: Sure
fantasai: Proposal: Exclude dashes and opening punctuation (ps and
pd in unicode) from following
RESOLVED: Exclude dashes and opening punctuation (ps and pd in
unicode) from following
fantasai: I think that's if for now on this issue. Will need to come
back, I think
::first-letter should include currency
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5099
Rossen: Has a test case in it
fantasai: Proposal is we include symbols along with letters and
numbers when looking for first-letter
fantasai: Makes sense and we should do it. Otherwise if you start
paragraph with a symbol there isn't a first-letter. Blink
and WK do this
Rossen: Any reasons why we shouldn't do it?
<tantek> should we include # also in case you start your paragraph
with a hashtag?
<bradk> +1
Rossen: Objections to include symbols when looking for first-letter?
RESOLVED: Include symbols when looking for first-letter
::first-line and line-height
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/2282
fantasai: Is ::first-line about to affect root inline element
fragment. Then an issue about if line-height can be
changed about first-line. Same question.
fantasai: Seems to me letter it affecting makes sense. Proposal:
root inline fragment on the first line is inside the
::first-line and therefore is effected by changes in size
oriol: Clarify, it's not just being able to change line-height, but
also set smaller than line-height in the block container or
is block container the min value
Rossen: Currently block container is the min and the proposal here
allow it to be smaller
oriol: Depends on impl. In FF block container is a min but in
chromium you can reduce to smaller
Rossen: Which are we proposing to change to? chromium or FF?
oriol: I think fantasai proposed chromium
Rossen: So ability to set sizes smaller than block container
Rossen: Additional comments or feedback?
RESOLVED: Align with chromium behavior for ::first-line and
line-height
Multi-line ::first-letter
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/2254
oriol: Problem is theoretically first-letter should be in
first-line. If block container is narrow enough it can happen
that first-letter will span multiple lines.
oriol: I had a proposal to try to define how this should behave.
oriol: Some parts to this proposal
oriol: First would be to standardize what FF, old Edge, and WK do
which is that if you don't have a typographic letter unit
then the first-letter is allowed to match the punctuation.
oriol: If you have both punctuation and letter you include both. If
you don't it's allowed to only have punctuation.
oriol: Second would be if first-letter could span multi-line we
restrict it to first-line so it can inherit.
oriol: Browser that does both parts of this proposal is FF
Rossen: Feedback? Any reason why we shouldn't adopt FF behavior?
* fantasai doesn't have a strong opinion
Rossen: Objections to adopt the FF behavior which allows us
to...want to make sure we have right resolution
fantasai: Summary: first-letter pseudo element is closed at the end
of the line even if the content that would otherwise be
part of it is wrapped to the next line
<tantek> +1 that's a good summary fantasai
Rossen: Objections?
RESOLVED: ::first-letter pseudo element is closed at the end of the
line even if the content that would otherwise be part of
it is wrapped to the next line
Rossen: That's the end of the agenda. We can break 5 minutes early
unless there's any other topics for discussion
Rossen: Going once, going twice...let's get 5 minutes back
Rossen: Thanks everyone, we'll chat next week
Received on Thursday, 14 January 2021 00:33:02 UTC