- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 18 Mar 2021 19:07:36 -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.
=========================================
Publications
------------
- RESOLVED: Republish WD of Cascade 5 and move open feature requests
to L6
- A request for wide review of Cascade 5 will be sent in preparation
for a CR request
- RESOLVED: Republish Sizing 3 WD
- In 2 weeks there will be a CR request for Sizing 3. Everyone is
encouraged to review the spec in advance of that in case there
are uncaught issues with intrinsic sizing.
CSS Fonts 5
-----------
- RESOLVED: Reverse the resolution and drop advance-override (Issue
#5983: advance-override details)
- RESOLVED: Add a size-adjust descriptor to @fontface, accepting a
percent. Applies a scale factor. Impacts all associated
metrics of the font, including the outline. Because it
does not affect a computed fonts size it does not affect
em [it does affect normal] (Issue #6075: Add glyph
scaling override descriptor to @font-face)
- A new question will be opened for if we should deprecate
font-size-adjust based on the above resolution
CSS Variables
-------------
- There is a new proposal for addressing issue #5624 (Higher level
custom properties that control multiple declarations) which
would create a new type of custom property which creates a new
cascade pass to resolve. Anyone with interest in this problem is
asked to participate on the GitHub issue to reach a solution.
Color 4
-------
- RESOLVED: Remove color() function fallback (Issue #5931: Concerns
about color() function fallback)
CSS Contain 2
-------------
- It remains undecided if the content-visibility: auto subtree
elements should be visible in the accessibility tree (Issue
#5857). Exposing the content could mean a performance hit only
for those using the accessibility tree and therefore be
considered discriminatory. On the other hand, not exposing the
content could lead to them not getting to some content which
should have been reachable. Conversation will continue on GitHub.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0015.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins Bittner
Christian Biesinger
Mike Bremford
Oriol Brufau
Elika Etemad
Brandon Ferrua
Robert Flack
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Sanket Joshi
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Stanton Marcum
Myles Maxfield
Tess O'Connor
Manuel Rego Casasnovas
Cassondra Roberts
Jen Simmons
Miriam Suzanne
Lea Verou
Greg Whitworth
Scribe: dael
Rossen: Let's get started
Rossen: As usual, any extra agenda items or things we should change
on current?
TabAtkins: fantasai had a request to push a few to the top
Rossen: Besides what I did?
TabAtkins: She replied to the thread
Rossen: I added the first two items. Anything else?
TabAtkins: I'm not looking at whatever you updated
Rossen: Got it. Agenda is the topic and the first two are what
fantasai requested
<fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0014.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0013.html
fantasai: I've got sizing 3 and cascade 5.
Rossen: What do we need to discuss?
fantasai: Publishing
Rossen: Okay
Rossen: First is a WD?
fantasai: Sizing or cascade
leaverou: chris and I had a schedule request. Could we move color
fallback before negative percentages since that will be
bikeshedding?
chris: And Safari is stalling on impl waiting for this
leaverou: Should be quick
chris: Issue #5931
Rossen: 15 in the agenda. Okay. Will keep that in mind
Publications
============
Cascade 5
---------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0014.html
fantasai: We updated spec with WG resolutions for cascade layers
fantasai: 2 open issues which are bikeshed on syntax
fantasai: Want to publish new WD and re-target open requests against
cascade 6
<chris> 6!!
Rossen: Definitely should republish
<miriam> 🎉
Rossen: When you say re-target existing issues to 6 does that mean
that will be part of republish?
fantasai: No, publication will be new WD. At that point cascade
layers has only 2 syntax issues. Appropriate to request
wide review and try for CR. All open feature requests
should target against 6
Rossen: Awesome. Objections to republish WD and move open feature
requests to L6
RESOLVED: Republish WD of cascade 5 and move open feature requests
to L6
Sizing 3
--------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0013.html
fantasai: Tab and I did edits, posted ^
fantasai: Would like a new WD to get edits in. Tweaked to be as far
as we can tell correct
fantasai: Also think this should go to CR, but because intrinsic
sizing is complicated we want to ask WG for other to do
top to bottom review before we transition to CR
fantasai: This is republish and ask for review before we transition
to CR. Sent wide review request with no issues returned
Rossen: Could be good, could be no one looked
fantasai: Yeah
Rossen: Thanks. Let's publish updated WD and that will help people
get a good snapshot of what's going to go into CR and nudge
feedback
fantasai: Resolution to publish and ask for WG how long should we
wait before CR for review? How much time do you need?
Rossen: Objections to republish sizing 3 WD
RESOLVED: Republish sizing 3 WD
Rossen: Let's put 2 weeks to get feedback before CR transition. That
will put a bit of urgency and hopefully someone comes and
reviews
CSS Fonts 5
===========
advance-override details
------------------------
github: https://github.com/w3c/csswg-drafts/issues/5983
<fantasai> https://github.com/w3c/csswg-drafts/issues/5983#issuecomment-800123577
fantasai: Where we're at is jfkthame's last comment ^
fantasai: Suggestion is reverse a resolution, drop advance-override
and focus on scaling descriptor in 6075
chris: Good proposal. Had a lot of problems with advance-override.
This seems better approach
TabAtkins: Last I heard from chrishtr yesterday, this is reasonable
to us
fantasai: And xiaocheng agrees
Rossen: Objections?
RESOLVED: Reverse the resolution and drop advance-override
Add glyph scaling override descriptor to @font-face
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6075#issuecomment-799915767
fantasai: Proposal add a descriptor to fontface which accepts
percentages. Scales computed fonts size before select font
face. Effects all metrics and glyph outlines, but not
computed font size.
fantasai: size-adjust is suggested name because same as
font-size-adjust in working
florian: Do you mean used font size is scaled?
fantasai: Yes
fantasai: Take computed font size, scale, but don't change computed
font size
fantasai: 2 use cases. One is what advance-override tried which is
the pitch of the font on the page scaling.
fantasai: The other reason to add is the glyphs in a different font
for same font size look different sizes. We have
font-size-adjust to equalize x-height, but only works for
writing modes where x-height matters. Having a manually
managed scaling allows authors to do size normalization
for other writing systems and other aspects of font design
fantasai: Doesn't have a11y or i18n problems advance-override had
TabAtkins: Making nearly identical to font-size-adjust. Can we fold
it in?
<chris> no we can't
fantasai: This is a descriptor.
TabAtkins: Nevermind. Cool
chrishtr: fantasai, there's an issue about multiplying ascent and
descent
chrishtr: When used with line-height:normal
fantasai: Yes, ascent and descent would get multiplied. If you want
stable line-height you shouldn't use normal since that
pulls things out of the font.
chrishtr: You would expect authors to apply ascent overrides to
counter effect?
fantasai: size-adjust needs to scale all font metrics. Not just used
for font-fallback, but other purposes. In case where; if
you don't want to scale the advance for some reason you
would unscale using ascent and descent override properties
fantasai: Most places where people care about this level of
precision they are likely to not be using normal because
you would have different line-heights for fallbacks. If
you care a lot about precision of typesetting you'll use
line-height:number
chris: I wanted to point out we should have example in spec. I can
create one. Should show with unicode range. For Arabic
bigger, Thai smaller...that's an interesting use case. Want
different normalization depending on script and this allows
it. Interesting additional use case.
myles: We're going to have to make sure we define what happens when
@fontface has this and ascent-override. Not hard, just have
to decide
fantasai: For that question, all metrics overrides you apply as if
they are what came in font and size-adjust is right before
you select your font. You want to do that because when
setting ascent override you're trying to match to a point
on the glyph, not arbitrary, and that needs to scale with
glyph. If you scale the glyph and not ascent it will be
weird
myles: A few minutes ago you descent there were problems with
font-size override property
fantasai: You mean advance-override?
myles: font-size-adjust
fantasai: Yeah, scales based on x-factor which doesn't help with
something like Thai
myles: I check mdn and only one browser supports font-size-adjust.
Should we deprecate that?
chris: It's a bit different. This is a percentages. We could
harmonize. Could do in new descriptor rather than property.
Not sure it makes sense to harmonize.
chris: If suggesting deprecate font-size-adjust I think it's a
separate issue, but reasonable maybe
myles: I can open a separate issue
Rossen: I was about to ask if these are additional clarifications we
can work separately and sounds like they are
Rossen: Any additional comments?
Rossen: If not, summary of proposal?
fantasai: Proposal: Add a size-adjust descriptor to @fontface,
accepting a percent. Applies a scale factor. Impacts all
associated metrics of the font, including the outline.
Because it does not affect a computed fonts size it does
not effect em
Rossen: Objections?
jfkthame: Can we bikeshed name?
Rossen: On the issue?
jfkthame: Okay
myles: Note sure I agree it wouldn't effect line-height
fantasai: Doesn't affect computed fonts size. Line-height is
calculated against that. That's intentional
myles: I'll open an issue
Rossen: Thanks myles. If you are concerned for the current
resolution and don't think it's separate we can discuss now
<florian> [I think it would affect line-height: normal, but not
line-height otherwise]
myles: I don't think need to now.
myles: I'd appreciate removing that part from resolution
fantasai: Integral to getting this to work. line-height is a number,
not a number per font. this is a per font scale factor.
You can't have it scale line-height. You can have it scale
ascent and descent but line-height has to be single, not
array
myles: Thinking about normal
fantasai: Does affect normal
myles: Okay. Doesn't affect line height with a number. Does affect
normal
Rossen: Objections?
RESOLVED: Add a size-adjust descriptor to @fontface, accepting a
percent. Applies a scale factor. Impacts all associated
metrics of the font, including the outline. Because it
does not affect a computed fonts size it does not affect em
CSS Variables
=============
Higher level custom properties that control multiple declarations
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5624
Rossen: Before we go into details, leaverou is this ready?
leaverou: Is TabAtkins on?
leaverou: To remind people use case is web components forced to use
presentational attributes, even though there's an AG
guideline. Custom properties can only contain fragments
and often need higher level keywords
leaverou: Been exploring how would be possible. First idea was to
have an @if block. Had a breakout with fantasai and
TabAtkins and realized what if block was trying to do is
replicate selector logic because can't use selectors for
computed style. Had an idea which might make more impl-able
leaverou: TabAtkins suggested new type of custom property resolved
earlier in cascade which only has keywords or numbers.
TabAtkins do you want to describe it?
TabAtkins: Preface this that it's a possibility here. I think it's a
useful use case.
Rossen: Let me pause you. Is this issue ready for resolution? Or to
bring WG back to point of current thinking?
TabAtkins: Get people informed about issue to get more eyes. Not
seeking resolution
Rossen: Thanks
TabAtkins: Idea I have is, new custom property: const property
TabAtkins: Can be set like custom property, but can be selected on.
Can do < or >.
TabAtkins: Way you avoid problems is do separate cascade pass to
resolve const properties and treat them as not matching.
You set const and then do everything else. Avoids loops,
but lets you pass properties through the tree
TabAtkins: Can set them on the light dom, will fall into shadows.
Can match based on them.
TabAtkins: This is a possibility. Would like eyes. Fear is 2nd pass
like this is a lot of expense.
TabAtkins: Possible other ways to solve. Lots of space there, want
help exploring and finding how to make this better for
users of custom elements
leaverou: Hope we can solve without resorting to attributes since
we're trying to move away from those. Making attribute
selectors more powerful doesn't solve issue
TabAtkins: Open to a lot of possibilities. Would like attention paid
so we can progress
Rossen: Anything else we can do to attract attention?
Rossen: Please take a look. Important issue and worth solving
CSSOM
=====
Serialization for declaration block with variable reference in
shorthand may not be useful
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2515
Rossen: Do we have the right people?
Rossen: Doubt we have xidorn. Can anyone represent this?
TabAtkins: This was put on by fantasai, presumably because needs to
be addressed. Not certain we need to address on a call.
It's for me and emilio to work on
Rossen: I'm fine moving forward if we don't need group consensus.
TabAtkins: Not yet. May come back later.
CSS Color 4
===========
Concerns about color() function fallback
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5931
chris: Concern expressed about the syntax. I explained came from SVG
chris: Doesn't have much value, complicates parsing and typedOM.
Seem to be consensus on removing. People that implemented
like BFO are fine dropping
chris: Since then discussion has drifted to what to use instead. I
sense consensus on dropping, would like resolution
<faceless> Big +1 from us
leaverou: Fine to remove as long as we add in-gamut MQ so authors
can do fallbacks that way. I think we have consensus on
that too
chris: Agree with leaverou that's good to solve, but separate issue
Rossen: I want to separate the two. To your earlier point the other
mechanism must be worked on and we need to figure out CSS
way, but is there objections to removing this?
RESOLVED: remove color() function fallback
Rossen: I would urge you to fork the other discussion into a
different issue
leaverou: There is a different issue
CSS Contain 2
=============
Clarify whether content-visibility: auto subtree elements are visible
in accessibility
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5857
vmpstr: We have content-visibility:hidden as not visible in a11y.
The auto value does not explicitly state if it should/should
not be exposed. Some dev concerns that chromium does not
expose. Would like to clarify in spec that
content-visibility: auto elements should be exposed to a11y
vmpstr: They would be essentially visible in a11y. Offscreen
elements in subtree of content-visibility:auto are visible
in a11y.
<fantasai> seems fine to me, given auto seems to be mainly about
delaying rendering of elements until they're on-screen
and not about actually hiding the content
Rossen: Which is the case with visibility, but not display:none
Rossen: Sounds reasonable. Any other opinions?
florian: I think it's different than visibility:hidden. Not all
elements in subtree are accessible. In this case they would
all be
chrishtr: Yes, would make all visible even if display:none ancestor
vmpstr: aria label would be respected so can hide
fantasai: Seems weird
Rossen: This is a bigger issue. If could to disable hammer of
display:none which does nothing, if we destabilize that
promise that's a different conversation
florian: We don't want to ignore display:none, but we're ignoring
styles and display:none is a style
fantasai: But if treating as shown you have to look at styles
vmpstr: Expose nodes to a11y. Any action taken to explore, once the
elements come on screen they're rendered. In that case if
something is display:none it would disappear from a11y
Rossen: Which is the problem. From a11y PoV what you have in your
a11y tree and available to user will be different than what
is visible in the view
<fantasai> +1 to Rossen
Rossen: Let's say you have a quiz and quiz has answers inside
display:none the right answers will be available to those
with access to a11y tree
Rossen: Breaking display:none for a11y or css is bad
florian: Case you talked about probably not an issue. Different
issue, once things are on screen you would maybe see answer
Rossen: Not true. a11y tree and text could get to those without
moving tree
florian: Yes. Typical case screen reader not reading what's on
screen but the outline of doc with hidden outline of doc
when presented to user it would claim there's a section and
when you try and go there it's gone
Rossen: Point here is we're presenting information that shouldn't be
presented
vmpstr: Alternative is to not expose it which also exposes different
information to a11y uesrs. If there are section headings
that should be visible, can't be accessed through header nav
which is bad
florian: Wondering about implementability. a11y tree largely from
box tree so you need to have a box tree which is working
off some style. Isn't it?
[missed]
vmpstr: Combo of dom and box tree
Rossen: Different view, think of it that way. Starts with dom,
predominantly dom.
chrishtr: Two options are err on side of not making a mistake on
display:none or err on side of expose as much as possible
fantasai: Stuff under auto is under a11y tree but other properties
that cause to not be there would remove that. You're
saying that's not possible and we need to choose
everything or nothing?
chrishtr: Exactly. Not possible because purpose is performance. We
don't want to just do it for a11y because would expose a
timing difference
florian: Since would need specialized code could it only style the
relevant properties for a11y tree?
vmpstr: Thought about it. Number of properties isn't the cost, it's
resolving all of your classes to figure out what styles. Not
much cheaper to just apply some set of styles as opposed to
full style resolution
Rossen: Going back to chrishtr point. This is not a good idea for
a11y users because that will effect timing
chrishtr: Partial recalc thing
Rossen: I agree the proper solution is for purposes of a11y
content-visibility:auto needs to resolve all the styles and
then not effecting a11y pre-computation.
Rossen: That said, want to go back to point this effecting the
timing. Can you tell a bit more?
chrishtr: Why the timing shouldn't be different?
Rossen: Timing for a11y users is different already
chrishtr: One of the main concerns raised during dev of
content-visibility is introducing vectors that make timing
different was not okay
Rossen: That's a worthy discussion to be had. a11y computation
compared to visual is more expensive today.
Rossen: a11y users...those of you who have worked with them must
have seen they're more patient about getting to their
content. For them it's about fidelity of getting to content,
but patience is way better. Arguments about timing in favor
of fidelity is always bad for time
chrishtr: Not about patience, it's about discrimination. That's the
concern raised
Rossen: I see
dlibby: I think chrishtr answered my concern. Wanted to add
typically it's privacy and not exposing vectors for screen
readers to be detected
Rossen: Anyone from Mozilla here that could represent these points?
Doesn't feel right to push the resolution at this point
dholbert: I wasn't part of the discussion so I don't know exactly,
but could be because unbounded content in this that author
assumes is free. If a11y has to display it could be
unbounded time to process. That could be a concern. Not so
much a factor longer, but unbounded time where something
like complete works of Shakespeare where a a11y user has
to see
Rossen: Right, but then we're back to content-visibility:hidden that
hides the content from a11y readers.
dholbert: Not sure we have great option. That's the concern with
forcing a11y to style that content
Rossen: Do you have any experiments on this?
vmpstr: Have dev feedback for hiding. An article that said be
cautions about using. Advice was to take the headers out
because otherwise they're hidden.
vmpstr: This issue was in response to that article
chrishtr: We changed chrome behavior for more a11y, but can change
back if that's the resolution
<chrishtr> https://web.dev/content-visibility/
<chrishtr> See note about accessibility - updated last week
chrishtr: It's linked to from that blog post
<vmpstr> https://marcysutton.com/content-visibility-accessible-semantics
Rossen: Hearing some lines of concern. One is we don't want to
penalize a11y users in a disproportionate way compared to
those that don't depend on a11y tree.
Rossen: Other concern is from PoV of what would be there will be
different than what it should be had styles been computed
Rossen: That dilemma doesn't seem to be resolved. We're trying to
force a resolution to validate one or the other and we want
to validate both.
fantasai: Blog post talks about putting headings inside the tree is
problematic. What if we hide everything from the a11y tree
but if there's headings resolve the styles on the heding
and ancestors. Maybe that would allow minimal style
resolution.
fantasai: You could nav to heading but hide most of it
Rossen: A little more. It's heading, but it's links and tables and
paragraphs. Everything indexable by AT today should be
indexed tomorrow. AT industry has differentiators they're
depending on
Rossen: On top of that aria capabilities which could be referencing
content-visibility subtree still need to resolve
Rossen: We can take a whole sale don't expose or expose it the right
way. Anything outside of that will be broken behavior for
a11y
Rossen: We're at top of the hour. I don't want to force resolution.
Rossen: This discussion will go into GH. Will hopefully prompt more
discussion and we can bring back next week. Is this urgent?
vmpstr: That's fine, can wait a week
Rossen: That's all the time for today. Thank you for calling in.
Have a great rest of your week
Received on Thursday, 18 March 2021 23:08:18 UTC