- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 26 Aug 2021 05:51:52 -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 Contain
-----------
- RESOLVED: content-visibility:hidden prevents scrollIntoView() and
similar functionality from working on the subtree (Issue
#6529: Should scrollIntoView scroll to
content-visibility:hidden subtree elements)
CSS Highlight API
-----------------
- RESOLVED: When an author uses a static range for highlight API, it
should actually be a static range internally, not backed
by a hidden live range (Issue #5497: Invalidation of
static ranges)
- RESOLVED: Publish a new Highlight API WD when changes are made
CSS Cascade 5
-------------
- RESOLVED: @layer statements must occur before or after all
@imports, not interleaved (Issue #6522: Proposal to
disallow interleaving of @layer and @import rules)
CSS Fonts & Nesting
-------------------
- Based on the TAG feedback on extending the format() syntax for
'src', work was done on supporting font-tech queries in
@supports. (Issue #6520: Nesting of @supports inside @font-face
and font technology feature queries)
- There were several people expressing support, but some concerns
around font-families combining and not having an else syntax or
inline/nested supports.
- The group will return to the topic next week to try and reach a
resolution.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Aug/0019.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
Christian Biesinger
Emilio Cobos Álvarez
Elika Etemad
Megan Gardner
Chris Harrelson
Sanket Joshi
Brad Kemper
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Myles Maxfield
Morgan Reschenberg
Cassondra Roberts
Dominik Röttsches
Miriam Suzanne
Lea Verou
Regrets:
Daniel Holbert
Scribe: TabAtkins
Scribe's scribes: fantasai & emilio
Rossen: Any additional items?
astearns: Might need some extra wording in CRDs to trigger
wide-review tooling checks. Chris, do you know which drafts
are having this problem?
astearns: Apparently there's some tooling the W3C has added for
soliciting wide review, and there's some magic words that
we need to add to CRDs we need wide review for
fantasai: I don't think we've published anything lately that need
this. We have resolutions on some, but haven't published
them yet
fantasai: And so far we've solicited wide review manually, so it
shouldn't be a problem
<fantasai> if you've been publishing the instructions on the wiki
anyway https://wiki.csswg.org/spec/publish
Rossen: So maybe we just have to update the wiki if the tooling
updates?
Rossen: I'd encourage Chris to follow up on this and see if there are
any edits needed
??: Could we bump the highlight topic up? sanketj wanted to
participate but has a 9:30 conflict
CSS Contain
===========
Should scrollIntoView scroll to content-visibility: hidden
subtree elements
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6529
vmpstr: We have content-visibility:hidden that hides the content of
the subtree, and spec says that the contents should not be
available to UA features like focus, find-in-page, etc
vmpstr: I think one of the features it should be restricted from is
fragment nav
vmpstr: I don't want to scroll into the hidden content
vmpstr: But the current fragment nav text points to scrollIntoView()
for defining it. and scrollIntoView() says we scroll as long
as there's a layout box
vmpstr: My hope is we can prevent scrollIntoView() for
content-visibility:hidden subtrees
vmpstr: I think last comment from Chris is that we should change
scrollIntoView() to say "if it doesn't have a layout box, or
is not available to UA features, return"
<bradk> Is content-visibility in a draft?
<astearns> bradk: https://drafts.csswg.org/css-contain-2/#content-visibility
<leaverou> Does that mean we also don’t scroll to disabled form
controls since they can’t be focused?
TabAtkins: I support this
vmpstr: To be specific we gen the layout box in the subtree when we
*need* to, such as to getBoundingClientRect() on the subtree
vmpstr: So the layout box *is* theoretically there, but it's
generated on demand. We just don't want that to happen here.
Rossen: Can we get a tighter definition for "available to UA
features"? It's very broad
Rossen: What would be the better scoped version of that? Is it just
for focusing?
vmpstr: I think it should be "behaving similar to display:none", it's
not just focus
vmpstr: display:none *also* doesn't have a layout box, but this does
chrishtr: We can scope it by "if you have a content-visibility:hidden
ancestor"
Rossen: Okay so if it's hidden or has an ancestor
chrishtr: Only ancestor. If the element itself has it, it's still
there on the page like normal
<leaverou> But ancestor can be overridden by another ancestor lower
down
<leaverou> Perhaps if the computed value of the parent is
content-visibility:hidden?
TabAtkins: I think best is to define the term somewhat generally, and
say that content-visibility:hidden is the only way to
trigger the term currently
<leaverou> Agreed as well
Rossen: Any more comments?
RESOLVED: content-visibility:hidden prevents scrollIntoView() and
similar functionality from working on the subtree
Highlight API
=============
Invalidation of static ranges
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4597
dandclark: This was originally what the criteria was to invalidate a
static range during DOM mutations
dandclark: discussion evolved into use of StaticRange more generally
dandclark: So when an author adds a StaticRange to a highlight,
should we internally back it with a live range? Or just
let it stay static
dandclark: I want to advocate we use statics internally
dandclark: One for performance; static range is better for
performance in some cases when there's a lot of DOM
mutations
dandclark: Team has done some benchmarks and shown the performance
diffs aren't theoretical
dandclark: And issues with invalidation of static ranges during paint
time can be addressed with invalidation caches
dandclark: So if they're backed with live ranges internally, we
pretty much lose all the benefits and there's no reason to
support it
dandclark: Second is some issues sanketj pointed out
dandclark: If a static is backed internally with a live range, the
author doesn't have a ref to it, so how do they manipulate
this
dandclark: Like if a highlight is unregistered, should we maintain
it? Highlight can be reregistered, unsure what the
lifetime is
dandclark: So I'd like to get agreement that the internal range is
indeed static
chrishtr: So your proposal is that the static range is not live
internally, and as a result, when the highlight api uses a
static range it's ignored if it's invalid
chrishtr: [missed]
dandclark: There are some cases like "start before end" that you
might have to treewalk to determine; it's not
constant-time to determine
dandclark: You can largely cache validity status and be fine; if
there's no dom mutations you're guaranteed right
chrishtr: But if the dom mutation was non-trivial, the UA might have
to treewalk in the worst case?
dandclark: Yeah
chrishtr: And you couldn't avoid that situation?
dandclark: I think UAs could in theory do some optimizations, but the
simplest way is to just cache the data; you won't have
mutations between every paint in practice
chrishtr: So the script usually will make a static range and then
immediately add it to the doc
dandclark: yeah
florian: Agree. I think this is the right thing to do; it's why we
proposed having static ranges in the first place
florian: Live ranges can be costly, and it might not even be a useful
cost
florian: If the DOM changes and the UA updates the range, whether or
not the updated range is what the author actually wanted
isn't clear
florian: So paying the cost of updating the live range, only to
immediately discard it and regenerate the range, is silly.
<sanketj> +1 to the proposed resolution
<chrishtr> +1
<GameMaker> +1
Rossen: Any further comments?
GameMaker: Agreement; webkit has the same performance issues that
Chrome does, so +1
RESOLVED: When an author uses a static range for highlight API, it
should actually be a static range internally, not backed by
a hidden live range.
florian: Do we think we need a spec change to reflect this? Or is the
spec already sufficiently implying this?
dandclark: I think the spec is clear as-is; we'd only need a change
if we decided the other way
dandclark: There's another issues about invalidation we could
discuss; it was the original issue.
sanketj: I think it would be good to have a note about using static
ranges internally
sanketj: So for interop we should have an explanation
florian: We say already that when you use a static range they
shouldn't be updated, but we can work over the note
dandclark: I can look over it
Publication
-----------
fantasai: Last publication of this draft was Dec 2020; given changes,
we should get an update onto TR
fantasai: ED claims there's only been minor changes since last WD,
that probably isn't true
florian: Agree. I'll start making sure the changes section is up to
date
Rossen: Should we get a resolution to republish the WD when it's
ready?
RESOLVED: Publish a new Highlight API WD when changes are made
CSS Cascade 5
=============
Proposal to disallow interleaving of @layer and @import rules
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6522
miriam: xiaochang is working on a cascade layers impl, and was
concerned about allowing `@layers ...;`rules allowed anywhere
in the doc, including between @imports
miriam: He's suggesting instead we just allow them before or after
all the imports, but not between
miriam: I think that's fine; there's no functionality loss, just a
little bit of flexibility. I'm fine with this.
<fantasai> wfm
<chrishtr> +1
Rossen: Seeing support, any other opinions? Objections?
emilio: I'd argue we should only allow after
emilio: The less syntax we have to mess with preload scanners the better
miriam: That actually does reduce functionality, we need to be able
to order layers before we import them
emilio: That means the scanners need to deal with this
emilio: Do we also allow the block syntax?
fantasai: No, we disallow that intentionally
emilio: Okay, as long as there's no arbitrary blocks before the
imports it's okay
RESOLVED: @layer statements must occur before or after all @imports,
not interleaved
Fonts & Nesting
===============
Nesting of @supports inside @font-face and font technology feature
queries
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6520
leaverou: A little background, in the TAG review request the current
syntax is extending the format() syntax for 'src'
<leaverou> https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#use-case-3-detectability
leaverou: It hasn't been implemented yet; Chrome is keen to implement
quickly
leaverou: In the TAG we recognized the use-case, but were concerned
about a new microsyntax when @supports already exists
leaverou: So was thinking about how we could utilize @supports, and
posted this issue
<chris> Explainer for current src descriptor
https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md
leaverou: Two things. First, adding a new @supports query for
detecting font tech.
leaverou: Lets authors differentiate their CSS in other places;
existing proposal only lets them use it when selecting font
source.
leaverou: Could imagine authors wanting different CSS for a
monochrome vs color font
leaverou: This also makes it much easier to programmatically detect,
vs doing rule hacking and seeing if there is a syntax error
leaverou: Google said they could add the font-tech queries in
@supports easily
leaverou: Second bit is to let @supports nest inside of @font-face,
extending the Nesting proposal
leaverou: But that would be a more substantial request
leaverou: So proposal is just to add the @supports queries for now -
it does the job, if a bit clunky. And in the future perhaps
do the nesting thing.
drott: Good summary. I'd support font-tech queries in @supports
drott: And am open to later improving it by integrating Nesting, but
the immediate benefit is just feature detection, so the
@supports queries works for me.
drott: I've made a syntax proposal for Conditional 4 to support this
chris: I wrote an explainer for it
chris: [missed due to bad audio]
chris: TAG asked for an explainer; having written it, it was clear
the only benefit of the existing syntax is that old browsers
would parse without falling over
chris: It has no other redeeming features. It's an ugly complex
microsyntax and is hard to read
chris: I think using @supports makes sense even if we can't use it
directly in @font-face
chris: We've got some examples in the thread and I think it reads
easily
emilio: I like this
emilio: Only question is if there's another place we need to parse
this font stuff?
emilio: To avoid the "specialized parser" thing that we try to avoid
with @supports
TabAtkins: While trying to avoid specialized parse is a general goal
TabAtkins: We recognized there will be cases where we do
TabAtkins: as long as we're carefully scoped wrt feature queries that
are not just parsing-based, should be OK
myles: One question - if an author uses @supports, is there a way to
say "else"?
myles: If there's not a way to do that... @font-faces join together
to form a family, rather than overriding
emilio: Can use "not"?
myles: "not" is both "fails the query" and "doesn't understand"
chris: Usual fallback is to put something normal outside, then
override in a @supports
myles: Right, that's problematic; if it's supported it'll define a
combined family using both @font-face rules.
myles: Author probably wants it to override
myles: If they're careful they might override, like all same weight/
etc, but if they didn't they'll both be present
myles: and they will join together to form a family
myles: If descriptors aren't identical, might end up using both fonts
in the page instead of only the second one
chris: We already have this thing where font faces can combine
together into a family, that's by design
TabAtkins: He's saying that conflicts with the author's design here.
myles: Right, if you have the non-conditional outside and the
conditional inside, that's brittle
TabAtkins: This is a general problem with a lot of things
TabAtkins: We don't have an answer to negate a query, but there's a
proposal for an "else" on conditional rules
TabAtkins: if there's implementer interest I'd be happy to revive it
<TabAtkins> https://tabatkins.github.io/specs/css-when-else/
<dbaron> some of these problems seem specific to @font-face inside
@supports rather than @supports inside @font-face
<fantasai> +1 dbaron[m]
myles: I think there isn't a lot of sense to build the stopgap
solution on something that doesn't exist yet
myles: If the oracle delivered us some way of having an else attached
to @supports tomorrow, that would solve the problem
drott: I think this is an improvement over the current proposed syntax
drott: You're basing this on the concern on the likelihood of a typo;
I think most will be coming from 3rd party fonts so that's not
really a concern
drott: Second, in browsers where author expects font-tech(color) to
work, "not" would work
myles: I think it would help if after this call we could have an
example of the fallback
<chris> the issue already has such an example
leaverou: There's a snippet in the issue that Chris posted
leaverou: I think drott mentioned most points
leaverou: Reminder that this isn't *ideal* but it can be done
quickly, and when we go on to nesting it'll work without
duplication
leaverou: Also think having "else" in a conditional block would be
super useful; it shouldn't hold this up though.
<drott> +1 for not blocking on an else block
<TabAtkins> Agreed, fwiw
dbaron: My understanding of myles' concern is - I think a lot applies
if we have @supports { @font-face{}}, but a lot of the
proposal is doing @font-face { @supports{}}, and I don't
think the interaction concerns apply in that case
myles: Right. I have different feedback in that case, but the
proposal is currently the first case.
fantasai: First, given myles' example, I do have concern about
allowing this without inline/nested supports, because of
his mentioned concerns
fantasai: Second, it seems the proposal is to add font-technology()
function which include some features that could be part of
a font format, but it's not clear to me how that relates to
the font format
fantasai: What if the browser supports colorv1 in woff2, but not
others. Would we need to tie the feature query to a font
format?
chris: woff1 and woff2 are encodings of the same font tech (truetype)
<chris> 1. stopgap 2. OM complexity inside @font-face 3. making other
stylistic changes based on font support 4. unrelated to
formats
chris: The entire format string was a stopgap because we didn't have
font mime types
chris: So "stopgap" is a non-argument in my mind
chris: If we do put @supports inside @font-face it complicates the
OM; current proposal avoid that
chris: Using @supports doesn't just allow switching font, it lets you
vary other aspects of your style
chris: Finally, the only reason supports were smuggled into format
string is for parsing. But spec actually mandates OpenType and
TrueType treated the same.
chris: So the font technology is almost completely orthogonal to the
format used
chris: So decoupling as this proposal does is a much cleaner and
nicer way
leaverou: The concern myles brought up about typos is already
existent; when authors write a family they could already
typo and have the wrong family happen
drott: As lea mentioned, the reason we brought to the TAG is it
seemed helpful to get some time of feature detection for
COLRv1, so I hope we can have CSS support for that at the same
time
Rossen: I think the TAG feedback was clear - COLRv1 is gonna be a
great addition
Rossen: Introducing new microsyntaxes is generally discouraged when
we have existing feature-detect capabilities
Rossen: I appreciate you have some implementation urgency on your
end. Important to get what's gonna stick for the future right
though.
Rossen: So not sure I'm hearing the solution that addresses the
current user needs and the tech being proposed
Rossen: With two minutes remaining, unsure if we'll have a resolution
Rossen: Propose we continue in the issue and bring this back next
week for resolution
Received on Thursday, 26 August 2021 09:52:33 UTC