- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Aug 2021 18:47:58 -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.
=========================================
CSSOM
-----
- RESOLVED: Return empty style if string begins with a colon, return
element style otherwise (Issue #6501: Throwing on invalid
pseudo-elements in getComputedStyle is not web-compatible)
- RESOLVED: Accept edits (Issue #6253: Shorthands should serialize as
empty string when longhands have variables)
CSS Overflow
------------
- RESOLVED: overflow-clip-margin uses the same corner-adjustment
formula as margin/etc (Issue #5896: overflow-clip-margin
+ border-radius continuity adjustment)
- RESOLVED: Accept dbaron's editorial feedback about making the
"accidental" case more explicit (Issue #5896)
CSS Display
-----------
- RESOLVED: Serialize specified value of display using keywords
specified (Issue #5575: Should <display-legacy> values be
aliased at parse time?)
- RESOLVED: close wontfix (Issue #4022: display:contents list-item)
- RESOLVED: Close no change (Issue #3998: The 'flow' keyword is
redundant)
- RESOLVED: Publish new CRD of css-display-3 (after today's edits)
(Issue #6516: Horizontal review)
Highlight API
-------------
- Though the group ran out of time for discussion, the expectation is
that next week the we be able to resolve issue #4597
(Invalidation of Static Ranges) as close no change.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Aug/0014.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Dan Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Sanket Joshi
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Alison Maher
Morgan Reschenberg
Cassondra Roberts
Jen Simmons
Alan Stearns
Miriam Suzanne
Lea Verou
Regrets:
Chris Harrelson
Daniel Holbert
Florian Rivoal
Scribe: fantasai
CSSOM
=====
Throwing on invalid pseudo-elements in getComputedStyle is not
web-compatible
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6501
emilio: Resolved to throw in these cases
emilio: I implemented it
emilio: but people do silly things
emilio: and it's not Web-compatible
emilio: One error is passing property names as pseudo-element names
emilio: and one is passing 'false'
emilio: Question is, should we try to do something smarter? Should we
return an empty style? Should we not throw and return the
element's own style?
emilio: Blink and WebKit return the element's own style
emilio: Firefox does that, but not if pseudo-element starts with two
colons
emilio: which is at least a bit more forwards-compatible
astearns: Not returning element style with two-colon strings means
we're less likely to have problems when we introduce new
pseudo-elements
emilio: Errors we're seeing seem to be mostly typos
emilio: ...
emilio: We could special-case in the IDL
dbaron: Seems the Web-compat problems are strings without
double-colon, so could throw on double-colon strings that are
also errors
emilio: I'd be OK with that
TabAtkins: Don't have a strong opinion, whatever is both Web- and
forwards-compatible
TabAtkins: document legacy weirdness
astearns: We'd resolved on throwing rather than empty style before,
why did we decide that?
emilio: Usually better, but optimistic that we could get away with it
<dbaron> the cases where we need to worry about forwards compat are
(we think) the start-with-colon cases
emilio: Anyone object to returning empty style if string begins with
colon, otherwise return element style?
iank: Does this paint us into a corner for slot pseudos or anything
like that?
emilio: I don't think so
emilio: If you do '::slotted' there's no style to return, multiple
elements can match it
astearns: Objections?
RESOLVED: Return empty style if string begins with a colon, return
element style otherwise
Shorthands should serialize as empty string when longhands have
variables
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6253
TabAtkins: Variables spec has text about handling situations when
shorthand contains variable and you ask for longhands
TabAtkins: At that time, we don't know what they will be, until
computed value
TabAtkins: Same problem opposite direction, if variables in
longhands, trying to serialize shorthand
TabAtkins: Can get two completely invalid longhand that creates a
valid shorthand, for example.
TabAtkins: So spec specifies the same thing, if longhand contains
variable and you ask for shorthand, considered
unserializable shorthand.
TabAtkins: Wanted to confirm edits with WG
emilio: This is the only thing that makes sense
TabAtkins: Firefox and Chrome do specified behavior, WebKit does
incorrect behavior
TabAtkins: Currently
astearns: Any concerns about this?
RESOLVED: Accept edits
CSS Overflow
============
Scribe: TabAtkins
overflow-clip-margin + border-radius continuity adjustment
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5896#issuecomment-892995385
fantasai: I think dbaron's comments are mostly editorial
fantasai: So I'll ask the main question
fantasai: Do we want to accept that the overflow-clip-margin follows
the same corner-adjustment rules as margin/border/padding
edges (so pointy corners stay pointy, round corners stay
round)
fantasai: When you have a curved border edge, and we calculate the
equivalent padding or content-box edges, we subtract the
border/padding widths, flooring at zero.
fantasai: Similarly when you're going out to the margin edge or box
shadows, we *add* the margin/shadow size to the radius, but
with a special adjustment that keeps zero radius at zero.
fantasai: Some math keeps it continuous between the two cases without
causing noticeable changes in most cases
<fantasai> https://drafts.csswg.org/css-backgrounds-3/#corner-shaping
<fantasai> https://drafts.csswg.org/css-backgrounds-3/spread-radius
dbaron: Another complexity is that a corner might be an inset on one
side and outset on the other. Already possible with negative
margins
dbaron: This probably makes that case more common, since it's an
offset from the padding edge
dbaron: I think the spec actually does something reasonable for this
right now, but it's by accident. I think it's right, though
dbaron: It probably should look more intentional to make sure impls
think about that case
fantasai: I just posted the testcase we used when we were figuring
out the continuity formula
fantasai: So proposal is to use the same formula for
overflow-clip-margin
astearns: Any other opinions?
[no objections]
RESOLVED: overflow-clip-margin uses the same corner-adjustment
formula as margin/etc
astearns: Should we also resolve about being more clear about the
positive-and-negative margin case?
fantasai: Sure
astearns: So proposal is to accept dbaron's feedback, making the
"accidental" correctness more explicit.
RESOLVED: Accept dbaron's editorial feedback about making the
"accidental" case more explicit.
dbaron: I don't think there's more to discuss, but I did raise more
substantive editorial issues that I think could confused
implementers.
dbaron: Do think we need to deal with those, but don't think we need
group time for them.
astearns: So fantasai you'll go thru those and either implement or
bring back to the group if necessary?
<fantasai> yes
CSS Display
===========
scribe: fantasai
scribe's scribe: TabAtkins
Should <display-legacy> values be aliased at parse time?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5575#issuecomment-893899115
TabAtkins: Awhile ago, Oriol brought up that we have the short
display values like inline-block, inline-table, etc.
TabAtkins: after attempt of splitting display property and then
re-unifying
TabAtkins: we have two-keyword values
TabAtkins: Question was whether these two ways of writing the same
value should be canonicalized at parse time or some other
time
TabAtkins: Argument for canonicalizing at parse time is that code
written before these values were valid, might be expecting
inline-foo pattern
TabAtkins: If author writes 'inline flow-root' for some reason, that
code won't correctly respond
TabAtkins: counter-argument is that it can be confusing when we
return something different from what author wrote,
especially for specified values
TabAtkins: and code written in the past will continue to work, just
not with the new syntax
TabAtkins: and that code wouldn't work for new display values in any
case
TabAtkins: fantasai and I come down on the side of not canonicalizing
at specified-value time
TabAtkins: It doesn't create Web-compat issues
TabAtkins: and it lets authors work in the syntax they specified
emilio: Is proposal to canonicalize at computed value time?
fantasai: Don't we have a requirement for shortest-serialization for
getComputedStyle?
TabAtkins: Separate question
emilio: It's very easy to check for one and not the other
emilio: I think it's better to canonicalize at parse time
TabAtkins: It sounds like you're saying that canonicalize to happen
at some point, and while prefer at specified value but ok
if only at computed value?
iank: Not concerned about Web compat?
emilio: I am, but figure they're accounted for?
iank: I don't think anyone's done research on this
iank: If Firefox implements this and it breaks or doesn't break a
bunch of sites...
TabAtkins: Not canonicalizing can't have Web-compat impact, because
legacy code written with inline-block will still return
inline-block
TabAtkins: New code written against old libraries would not work
maybe, but that's not compat
emilio: Firefox has shipped the new syntax for awhile now
emilio: so could have compat
emilio: I don't think it's super useful not to canonicalize
emilio: Useful for authors that write JS code and browsers
astearns: I suspect whether or not we canonicalize at parse time is
much less web compat concern than if we do it at
computed-value time
astearns: but there's argument of if computed-value is simplified,
might be simpler to do it at parse time
iank: Whether we do it at parse time...
TabAtkins: fwiw, I agree that at computed value time they should be
canonicalized, because they are in effect the same value,
and shortest serialization would require it
iank: Are we ok with backing out if there's a compat problem?
emilio: This proposed resolution is the behavior of the only existing
implementation
TabAtkins: Yeah, so this is completely web-compatible if anything
can be
fantasai: The existing rule is "shortest most backwards-compatible
serialization"
astearns: So want to be clear that they're the same
RESOLVED: These values compute to each other and thus serialize as
"shortest most backwards-compatible" which is the older
keywords
TabAtkins: 2 objections to canonicalizing at parse time
TabAtkins: First, specified value should reflect what the author
specified
TabAtkins: if put .style="inline flow-root" should get that back when
request it
TabAtkins: Also, canonicalizing back out would make it harder to
split back out into two longhands
emilio: I don't see why
fantasai: When teaching CSS, Jen and Rachel have found the split
keyword syntax useful for explaining the difference between
inner and outer display roles
fantasai: If they disappear from the OM as soon as they're inputted,
that creates a strong bias against using them, they're not
so real anymore
<jensimmons> yup to useful for teaching. Once they are in every
single browser everywhere, I expect developers to start
using them exclusively. (AKA, 2027?)
[missed exchange]
emilio: I don't feel super-strongly, can compromise at computed-value
time
emilio: I think it's weird one way or the other
emilio: Computed value of 'display' is more looked-up than specified
value
TabAtkins: In general specified values aren't looked at too much
anyway, unless looking at value of style attribute
emilio: I don't see this as super useful, but if fantasai disagrees,
it's OK I trust her
jensimmons: I haven't been completely following, but +1 to what
fantasai said
jensimmons: about the syntax of inner and outer is super useful
jensimmons: Teaching now, and later once all browser support it, will
likely switch to it
emilio: But if we serialize into old syntax, doesn't seem so useful?
emilio: Serializing the old value increases time to adoption, while
serializing the new value which is nicer, but...
astearns: I do agree with Tab's first point, that we do try to keep
the serialization of specified values as close to what
author inputted as possible
astearns: and sounds like Emilio is OK with that, and didn't hear
concerns about having specified vs computed being different
astearns: So proposed resolution is that for specified values we
serialize as written
astearns: and for computed value, we canonicalize
emilio: Not quite as written, if you write "inline flow"... do you
want to serialize to "inline"?
emilio: Nevermind
emilio: sounds OK
jensimmons: Not sure what issue is, but if this affects what appears
in the computed panel in devtools, idea of browsers
saying "I took old value for you and put it into the new
style" that would be a good thing
emilio: The computed panel, you can put whatever there. Doesn't
affect specified.
jensimmons: I think what happens in parsing engine, nobody knows,
doesn't matter to authors
astearns: So can we resolve?
<bradk> +1
RESOLVED: Serialize specified value of display using keywords
specified
display:contents list-item
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/4022
astearns: Proposal is close wontfix?
TabAtkins: Brought up that there's nothing theoretically wrong with
'display: contents list-item' which would generate a
::marker
TabAtkins: Currently the grammar doesn't allow combining these two
TabAtkins: My objection to this is just that we don't have any
particularly strong reason to do so
TabAtkins: but there's nothing wrong with it
TabAtkins: So suggesting close no change
TabAtkins: but no objection to making it possible if someone thinks
this is a useful thing that we should allow
astearns: My case in the comments is completely theoretically
TabAtkins: I can see it, but I think it's one more thing that we
don't necessarily need
emilio: Seems like one more edge case that we should avoid, so ok
with no change
astearns: Any objections to no change?
RESOLVED: close wontfix
astearns: If Mats feels strongly, he could reopen it
The 'flow' keyword is redundant
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3998
TabAtkins: Mats pointed out that the 'flow' keyword doesn't
technically do anything
TabAtkins: The display-outside value you pair it with, if don't
specify anything else, it's implied
TabAtkins: was wondering why it's there
TabAtkins: There are 2 reasons
TabAtkins: It was a remnant of display-inside/display-outside as
separate properties
TabAtkins: did need a keyword for ordinary flow
TabAtkins: when we collapsed back to shorthand, combined values
TabAtkins: and then I'm personally not a fan of states which are
expressed by a lack of a keyword
<miriam> +1
TabAtkins: So prefer when a particular state allows an explicit
keyword, even if getComptutedStyle omits it
TabAtkins: Lastly, Firefox already shipped with it
TabAtkins: So my preferred resolution is to close no change, keep the
keyword
astearns: Any other comments?
RESOLVED: Close no change
jensimmons: Sounds to me like this would have a big impact on authors
for the reason we discussed earlier, and we want this
jensimmons: so all in favor of the resolution
Publishing Display
------------------
github: https://github.com/w3c/csswg-drafts/issues/6516
astearns: Proposed resolution is to publish CRD
astearns: We have changes list and DoC
<chris> looks good to me
TabAtkins: The one thing, we will need to do slight modifications to
make that resolution about canonicalization clear, but I
think that's the only change not reflected in the draft
fantasai: We're actually set to publish a new CR Snapshot, which is
the one that invokes patent policy
fantasai: But we don't have horizontal review when we pulled in
'order' and 'visibility'
fantasai: We need review on those because they're major changes
compared to previous CR
<fantasai> https://drafts.csswg.org/css-display-3/#visibility
fantasai: Also want the WG to take a look at the 'visibility' section
in particular. We didn't just copy from CSS2, we added more
text, especially for interactivity (clicking, etc) which
wasn't clearly specified in CSS2
fantasai: So after we get review on this new CRD, our intention is to
request a new CR snapshot
astearns: Objections to publishing CRD after edits from today?
RESOLVED: Publish new CRD of css-display-3 (after today's edits)
Highlight API
=============
Invalidation of Static Ranges
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4597#issuecomment-892202307
dandclark: Static ranges can get into weird states, like if I remove
one boundary from the DOM
dandclark: Sanket came up with criteria for deciding if a range is
valid or invalid
dandclark: but the question is, if user adds range to a highlight
should we use a live range, or use static range internally
dandclark: Reason to use live range, don't have to check validity in
the same way because they're kept up to date
dandclark: We discussed awhile, and decided not to back static ranges
with a live range
dandclark: First, performance reasons -- live ranges, they can slow
down DOM mutations because live ranges have to be notified
every time there's a DOM mutation
dandclark: Static range doesn't have that issue
dandclark: We did some research showing that this performance issue
is observable
dandclark: and we also found that with caching, it's possible to
cache static range validity
dandclark: which reduces performance cost during painting
dandclark: But if they were backed by live ranges internally, that
wouldn't hold
dandclark: because DOM mutations would have to update, so lose
performance benefits
dandclark: Sanket also raised some issues with using live ranges
internally
dandclark: Authors don't have direct references to those live ranges
dandclark: so difficult, how would they remove or modify a highlight
that they added?
dandclark: Even if we added a map, can become out of sync with tree
dandclark: and not clear when safe to drop live range, because author
might de-register and re-register a static range
dandclark: so confusing developer-confusing scenarios there, tricky
answers for spec
dandclark: So proposal is to allow static ranges and live ranges to
be added to highlights
dandclark: and there's no live range backing for static ranges
astearns: My first question was, can developer use either
astearns: Is it clear to devs that live range could have performance
implications?
dandclark: It's in line with current use of live ranges
dandclark: Spec issue states that static ranges solve this performance
dandclark: Use of live ranges in general, here or otherwise, has
these performance costs
dandclark: I think it's a documentation and devrel issue
dandclark: of when live ranges vs static ranges are appropriate
sanketj: HTML doc also mentions this (?)
sanketj: It has been documented
sanketj: Static ranges are fairly new concept, previously only had
option of live ranges
astearns: OK, out of time
astearns: My understanding is that with this impl experience, you
would like to close issue no change?
dandclark: Yes
astearns: OK, we'll expect to close no change, and will resolve next
week
Received on Wednesday, 18 August 2021 22:48:41 UTC