- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Apr 2023 19:33:22 -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.
=========================================
F2F Planning
------------
- There are three possible locations for the F2F. The group is asked
to provide feedback on the private list as to how likely they
are to attend the three candidate locations on the week of July
17th or the week after.
CSS Positioned Layout
---------------------
- RESOLVED: FPWD CSS Positioned Layout L4
CSS Counter Styles
------------------
- RESOLVED: No change to current spec. Draft ability for a counter
function to return the counter string including prefix/
suffix, with various fallback options (Issue #8619:
Should fallback use prefix/suffix of original style or
fallback style?)
CSSOM
-----
- RESOLVED: Accept proposal to match JS scinot serialization
triggers, other than 6-digit decimal truncation rule
(Issue #8538: Serialize numbers using scientific
notation?)
- RESOLVED: Update CSSOM to allow null representation of imported
style sheets (Issue #8608: CSSImportRule.sheet not being
null conflicts with @import supports())
- RESOLVED: Accept IDL in issue (Issue #8710: Extend CSSImportRule
to expose supports condition)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0014.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Paul Grenier
Chris Harrelson
Daniel Holbert
Brian Kardell
Rune Lillesveen
Eric Meyer
Tim Nguyen
Vitor Roriz
Jen Simmons
Miriam Suzanne
Bramus Van Damme
Regrets:
Chris Lilley
Lea Verou
Chair: Rossen
Scribe: fantasai
Scribe's scribe: emeyer & TabAtkins
Administrative
==============
Rossen: As usual, I wanted to ask for any additional topics/agenda
changes
Rossen: I was able to capture everything sent to ML, and personally
have one additional topic wrt CSSWG F2F for the summer
Rossen: But before that, any other topics?
CSSWG F2F
---------
Rossen: First, thanks for answering the surveys
Rossen: Overall results were that we have about 20 people who would
be willing to travel for an F2F meeting
Rossen: Bigger question, and where we're stuck at this point, is
where can we do that
Rossen: There are two primary hangups:
Rossen: 1. Can we get the venue and even sponsored ($$$)
Rossen: or 2. Hosted at their location of business
Rossen: Then the other question is whether people can travel to that
venue
Rossen: We intentionally proposed US East Coast because can
accommodate Europe and West Coast for majority of
discussions and also some overlap with APAC
Rossen: Mexico was brought up as an option, because fantasai found a
venue with a lot of ventilation
Rossen: we would be able to address most of the concerns of having
meetings in ventilated areas
Rossen: problems is we would need a sponsor
Rossen: Travel is, however, not more expensive than going to US East
Coast
Rossen: in fact often much cheaper
Rossen: US East Coast is another option, fantasai found some venues
there
Rossen: That satisfies any requirements about staying within the US
if anyone is restricted by borders
Rossen: but still run into trouble with venue costs
Rossen: Last option is to be hosted by a company, which would be in
normal corporate environment
Rossen: which almost certainly means a closed conference room
Rossen: and so far only Apple has stepped forward to offer, so one
of their offices
Rossen: So default option would be to host a smaller meeting on the
West Coast
Rossen: assuming smaller because fewer people might be able to travel
Rossen: and less overlap with Europe
<fantasai> -> https://wiki.csswg.org/planning/f2f-2023
Rossen: fantasai captured the options in the wiki ^
Summary of Options:
Option 1: West Coast Corporate Hosting
Option 2: East Coast US Venue
Option 3: Mexico Venue
Rossen: We need to make a decision quickly, so that we can secure
venues and plan travel
Rossen: Wrt external venues, cost would be $10-$15K
florian: Would Apple be able to switch from hosting to sponsoring
the venue?
Rossen: Their offer is to host, not sponsor
jensimmons: They're different
jensimmons: different budgetary options
<TabAtkins> yeah, hosting vs sponsoring is totally different
unfortunately
fantasai: I have question for figuring out what to do
fantasai: 1. Which venues are you willing to attend?
fantasai: 2. Which venues do you WANT to attend?
fantasai: 3. Which venues do you think you can pull off attending?
fantasai: With the answers to those three questions, we can figure
out what to do
fantasai: I'd like answers to these questions from everyone who
would like to attend
<dbaron> just a note that answers might need to be given in the form
of probabilities
<fantasai> that's fine :)
Rossen: OK, let's poll async via IRC, and we can also post to the ML
<astearns> 1,2,3: any and all work for me
Rossen: fantasai is fighting really hard behind the scenes to make
this happen, and allow us to have high-bandwidth productive
time
Rossen: not just to move through issues, but to also make progress
on more creative off-track topics, ideas
Rossen: hoping we can make this happen
<miriam> Knowing the dates soon will make a bigger difference to me
than the venue…
fantasai: Miriam asked about dates, we're looking at week of July
17th
fantasai: or possibly the week after
<miriam> ok, thanks!
Rossen: That week has the highest probability of attendance
CSS Positioning L4
==================
FPWD Publication
----------------
Rossen: Tab asked for FPWD?
TabAtkins: The biggest innovation in L4 is that I pulled over
Appendix E from CSS2
TabAtkins: I've done a light rewrite to try to make it properly use
modern element vs. box terminology
TabAtkins: would really appreciate review on that.
TabAtkins: Also did some light refactoring to pull out sub-algorithms
TabAtkins: I believe it's an accurate representation of Appendix E,
but would love review.
TabAtkins: I've also introduced some top-level concepts introduced
in Fullscreen spec
TabAtkins: Have PR to move those over
TabAtkins: Would also like review on that.
TabAtkins: And finally, the `overlay` property that we discussed
previously for controlling exit/entry animations for top
layer
TabAtkins: It's a slightly funky property, because it can only be
specified UA-level !important rules
TabAtkins: but allows authors to be able to control transitions.
TabAtkins: I believe this is the right way to do it, introduces no
new concepts
TabAtkins: just relies on how cascade operates on transitions.
TabAtkins: And that's the spec right now
TabAtkins: [summarizes]
TabAtkins: There's more stuff I want to add, to elaborate on
stacking context stuff
TabAtkins: want to e.g. get filtering and opacity built into this
TabAtkins: and need to add steps for View Transitions which are on
top of top layer
TabAtkins: But what's there already is reviewable, and imho ready
for FWPD
Rossen: Any reasons not to publish?
<fantasai> +1 from me, thanks for the overview
RESOLVED: FPWD CSS Positioned Layout L4
Rossen: What's the state of CSS Positioned Layout L3?
TabAtkins: This doesn't touch L3, it's a delta spec
TabAtkins: The things defined in L3 vs L4 are disjoint, no effect
Counter Styles
==============
Should fallback use prefix/suffix of original style or fallback style?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8619
TabAtkins: Issue here is, per spec, when you generate counter style
for a marker
TabAtkins: it generates in your requested style, and adds prefix/
suffix
TabAtkins: but if there's fallback to a different style (because
given style can't generate that number)
TabAtkins: the algorithm doesn't pay attention to that fallback's
prefix/suffix.
TabAtkins: It uses the prefix/suffix of the chosen style
TabAtkins: I wrote it that way because simple, and because ability
to even obtain prefix/suffix of a counter style is not
accessible to author code
TabAtkins: so if we match to the prefix/suffix that was used to
finally render
TabAtkins: authors wouldn't be able to manually reproduce that effect
TabAtkins: However, it seems that browser do follow the fallback and
use the prefix/suffix from the finally used counter style
TabAtkins: so have requested the spec to do that
TabAtkins: If people want to change, then we can change the spec to
have the prefix/suffix use the fallback style's prefix/
suffix
vitorroriz: WebKit follows the current spec, so not all browsers
follow the other way
vitorroriz: It came out from a bug report, but your sense about the
counter API also makes sense
TabAtkins: We can add more API to allow authors to do the same
thing, if we want to
TabAtkins: but it does seem that FF and Chrome do follow the
fallback, and WPTs match that
jensimmons: This might be a good time to do what's right for authors
jensimmons: Safari hasn't had support for counter styles, so once we
ship it could become a lot more popular
fantasai: My concern with changing the spec is you'll end up with an
inconsistent prefix/suffix if you're falling back
fantasai: Say your number system doesn't have negatives, and you use
() as your prefix/suffix
fantasai: And if falls back to decimal which has period as its suffix
fantasai: you'll switch styles when you fallback, functionally
fantasai: Feel like it would make more sense to keep the prefix/
suffix consistent across the list
fantasai: even if your system is limited in some way
fantasai: So I think the spec behavior makes more sense from a usage
point of view
fantasai: I understand from an impl it can be easy to just generate
a string from another style
ntim: Looking at WPT, it seems that Chrome matches safari, not
Firefox
emilio: When jfkthame changed this, he had a strong opinion that it
was the right thing to do
emilio: If we resolve not to change, we should check in with him
<TabAtkins> the bug report has a good reason for the suggested
behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1808995
dholbert: Wrt fantasai's example, it was for someone using 2nd/3rd/
4th, using letters as a suffix
dholbert: and trying to use the appropriate suffix there
dholbert: in which case it's quite reasonable to use the suffix from
the fallback
<TabAtkins> right, `counter(ordinal)` would still just produce a
number from that counter style
fantasai: It seems that that person is trying to create a numbering
system
fantasai: but the prefix/suffix is only a formatting applied to
counters when rendered as a list-item marker, specifically
fantasai: doesn't work in other uses
fantasai: seems that it should be built into the number *value* if
it's part of the number, not part of the formatting prefix/
suffix
TabAtkins: a) To build this in yourself, you'd have to do it as an
additive system... which would probably work just as well?
TabAtkins: but aside from that, this is the reason why it makes
sense to have a counter() variant that produces the full
representation rather than just the number value
TabAtkins: so that authors can reproduce what authors are doing
automatically in list-item
TabAtkins: I would like it if authors can reproduce the
functionality in API, so if we resolve to change should
update API
TabAtkins: I don't have a strong opinion on which way to go
<TabAtkins> @counter-style ordinal { system:additive;
additive-symbols: 900 "9", 800 "8", ..., 90 "9", ..., 9
"9th", ..., 1 "1st"; }
<TabAtkins> actually that's way shorter than what the bug reporter
was trying to do
fantasai: I feel like if we want to support ordinal numbering, we
should build that into the value of the counter
fantasai: so I lean no change
vitorroriz: I tend to agree with fantasai, we should provide
appropriate API
vitorroriz: but might be a bit awkward if we don't
jensimmons: Building examples, there's numbering in Ethiopic which
uses a suffix based in the language
jensimmons: It's confusing that prefix/suffix applies only to list
items
<vitorroriz> I also think that we should just change it if a
counter() variant api is provided to enable authors to
access the fallback prefix/suffix
TabAtkins: That's a legacy issue, counter function has always worked
this way
jensimmons: It does feel like prefix/suffix works with the number
jensimmons: feels unnatural
TabAtkins: I can see both ways
TabAtkins: Whatever way we decide the default, when we create
function, could make it optional
TabAtkins: then if what the default's doing, they can do themselves
jensimmons: So keep existing legacy stuff simple and add something
more powerful?
<TabAtkins> value-prefix/value-suffix descriptors? and maybe with
some more functionality to tie it to numeric value.
something for counter-styles-4
fantasai: I think the current prefix/suffix feature is reasonable
to exist
fantasai: this is so that list-item counters format properly, and
those prefix/suffixes should not be emitted in counter()
fantasai: but it might also be helpful to have a prefix/suffix
feature that represents some segment of the number
rendering itself
fantasai: that's a different feature, and we have a bit of a name
clash, but it's a different feature that maybe should also
exist
fantasai: and in that case, it's a bit more complicated, because the
prefix/suffix can depend on the *value* of the counter
fantasai: and is an essential portion of the stringification of the
number
<TabAtkins> proposed resolution: no change from current spec, but
add a counter-tbd() function that generates a string
*with* prefix/suffix (exactly what fills ::marker by
default) with a choice of using original or fallback
prefix/suffix.
<TabAtkins> (oh, and put some notes in calling this behavior out)
TabAtkins: [reads out proposal]
<jensimmons> and I'd add that the new thing works in lists, and
elsewhere counters are used.
fantasai: I'm not 100% sure about whether that's going to make sense
once we have proper support for ordinal numbering
fantasai: Not sure if you'd want to switch, but maybe you do
fantasai: If you prefix and suffix are characters, would you
actually want to follow the numeric pattern
fantasai: I think we might want to investigate further how to do
ordinal numbering
TabAtkins: That's a harder problem, but we still need the formatting
string version of the function
TabAtkins: so I think we should do it anyway
Rossen: Any further thoughts or objections to the resolution?
oriol: So the new function, could it be for the `content` property,
or for list-style-type, or ... ?
TabAtkins: At the moment, define it as exactly equivalent to
counter() and counters() but with slightly different
generation for the string
TabAtkins: so these should be usable as <string>, if the browser
supports it; but would definitely be allowed in 'content'
oriol: so it wouldn't be for list-style-type
TabAtkins: no, it's not a new counter type. Just a new
string-generating function
fantasai: Maybe an argument to the existing function?
Rossen: OK, hoping this answers the question. Didn't hear any
objections
RESOLVED: No change to current spec. Draft ability for a counter
function to return the counter string including prefix/
suffix, with various fallback options
CSSOM
=====
Serialize numbers using scientific notation?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8538
TabAtkins: Our rules for serializing numbers are reasonably
well-defined
TabAtkins: But we have scientific notation now, which is widely
implemented
TabAtkins: Browsers use it for serialization *sometimes*,
inconsistent, depends on the property...
TabAtkins: So the proposal here is to formalize when we serialize as
scinot
TabAtkins: My proposal is to match JS exactly, which means that you
use scinot whenever either the number has 22 or more
digits of integer value, or has 6 or more leading zeroes
in its decimal portion and is zero integer
TabAtkins: Only change from JS is that we continue to truncate to
only 6 digits after decimal point, maximum
TabAtkins: this is required for compat
TabAtkins: and also it hides some differences between browsers/
properties
TabAtkins: and it also hides some floating-point variances
TabAtkins: so there's spec text in the issue
TabAtkins: and that's it
TabAtkins: Wrt interop, we're all over the place
TabAtkins: Every property and every browser does an effectively
random thing
TabAtkins: partially due to different levels of precision, e.g.
width supports subpixel, but scale property supports ...
TabAtkins: e.g. Chrome start scinot at 0.0001
TabAtkins: So no interop, so match JS with wrinkle about 6 digits
seems reasonable to do with minimal impact on authors
Rossen: Any additional comments?
TabAtkins: dbaron's point was to bias towards older formats during
serialization
TabAtkins: that's part of why the bounds are so wide
TabAtkins: Most numbers you will ever encounter in a stylesheet do
not trigger scinot
TabAtkins: but outside those bounds, e.g. when serializing a
transform matrix, need to serialize somehow
Rossen: Pretty clear proposal, not seeing anyone rushing to the
queue ...
Rossen: any objections to the proposal?
RESOLVED: Accept proposal to match JS scinot serialization triggers,
other than 6-digit decimal truncation rule
CSSImportRule.sheet not being null conflicts with @import supports()
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8608
emilio: 2 specs conflicting with each other
emilio: imported stylesheets cannot be null, but since we have
supports() condition the UA is not required to fetch the
stylesheet
emilio: so we need CSSOM to allow it to be null
<TabAtkins> +1 for the obvious fix
<fantasai> +1
RESOLVED: Update CSSOM to allow null representation of imported
style sheets
Extend CSSImportRule to expose supports condition
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8710
emilio: While we were implementing supports() for @import, we
realized it's not exposed in CSSOM
emilio: so following the pattern for others
emilio: and then report null or empty string if it's missing
<TabAtkins> +1 to this one too, obvious and the suggested IDL looks
right
<TabAtkins> nullable is most correct I think
TabAtkins: I think we should accept with proposed IDL in the thread
fantasai: As long as the naming is consistent with other interfaces,
I'm fine
Rossen: Objections?
RESOLVED: Accept IDL in issue
F2F
===
Rossen: Going to transfer this conversation to these questions to
the ML, and hopefully we'll have a meeting decision soon
Received on Wednesday, 26 April 2023 23:33:54 UTC