- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Dec 2020 18:55: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.
=========================================
Next virtual long-form meeting (early Feb?)
-------------------------------------------
- The group was in favor of having more long-form meetings since
they're now virtual. Rossen and astearns will propose specific
days/times on the private list.
Reminder for re-joining group next week
---------------------------------------
- Due to the change in patent policy, everyone will need to re-join
the working group to accept the policy. Emails should go out
shortly.
CSS Text, CSS Fonts, and CSS Text Decor
---------------------------------------
- The PR to change the applies to text was merged (Issue #5303: CSS
Text, CSS Fonts, and CSS Text Decor). Any issues or missed specs
should be raised as separate issues.
CSS Conditional
---------------
- Issue #5697 (Inconsistent phrasing around placement of @import
rules) will be closed as editorial. A new issue will be opened
for the naming of the <stylesheet> grammar construct.
CSS Variables
-------------
- leaverou introduced her proposal for fixing the current limitation
that custom element authors cannot use custom properties in the
place of presentational attributes (Issue #5624: Higher level
custom properties that control multiple declarations). There was
a lot of interest in solving and some discussion around creating
some syntactic sugar and using if() conditions to make it
possible. Discussion will continue on the issue.
Grid, Flexbox, and Quirks
-------------------------
- Everyone agreed that quirks should not skip grid and flexbox items
(Issue #5545: Avoid percentage height quirk in new layout
models). There was concern about web compat in making the
change, but the group will try for it and revert if there's
breakage.
- RESOLVED: dholbert to make a change to quirks spec to clarify
behavior for flex and grid items and containers (Issue #5545)
CSS Color 4
-----------
- Several browser vendors will go back and check with their teams if
there are any concerns requiring a higher number of minimum bits
for storing colors in css data structure (Issue #5667: Minimum
bit depth for serializing color() values)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Dec/0011.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Mike Bremford
Oriol Brufau
Tantek Çelik
Elika Etemad
Brandon Ferrua
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Jonathan Kew
Daniel Libby
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
François Remy
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Lea Verou
Greg Whitworth
Jeffery Yasskin
Regrets:
Hui Jing Chen
Scribe: dael
astearns: First is if anybody has amendments to agenda. We will pull
item 9 up to probably 5 because leaverou can't stay on long
<leaverou> thanks astearns!
rune: I have an announcement
rune: At Google we are exploring containing queries. We are figuring
out how you can implement and what spec may look like
rune: Was brought as 1d containment last call. I wanted to announce
we are working on it and communicating about it on chromium
slack. Any input from other vendors is welcome
astearns: Great you're discussing. Don't know if slack is best
rune: That's where contributors to chromium discuss. We'll bring to
WG things to discuss more globally
astearns: Great. Questions?
Next virtual long-form meeting (early Feb?)
===========================================
astearns: We usually meet end Jan, early Feb.
<fantasai> https://www.timeanddate.com/calendar/
astearns: Rossen asked last week for discussion on the ML. I didn't
see any. Unless there's a strong opinion about time we may
just pick a week in early Feb and slot some times to get
together in longer form
Rossen: This is also the time when we discuss if we want 2 or 3
meetings + TPAC. I don't have visibility of when TPAC is. If
it's later might make sense to have 3 additional. If it's
earlier like Sept perhaps 2. If anyone knows it would be
great
Rossen: We should try to decide before we start to pin dates
hober: One thing I would like group to consider after experiment
with TPAC is maybe group should not meet during or near TPAC.
Personally between the sections I found the 3 week slog
exhausting. I think it would be good to have WG avoid a month
on either side of TPAC to not overburden.
<florian> +1 to hober
<gregwhitworth> +1 to hober
<Rossen> +1 to hober
astearns: Yeah. Agreement on IRC. I like the idea of not overloading
if it's virtual
<rachelandrew> +1 if it is virtual no reason to bundle them
<leaverou> +1 to only joint meetings during virtual TPAC
chris: Reason we went from 4 to 3 meetings was travel budgets type
of thing none of which applies to virtual. I think we could
have more. If we have 4 before TPAC we get more work done
chris: To hober's point, I totally agree. Virtual TPAC means we
should focus on joint meetings. We should push our meetings
out since it's virtual
<Rossen> chris, Travel and time away from the office - travel is not
a problem but time away is still there
<gregwhitworth> I wouldn't mind a once per month 2-3 hour session
fantasai: I was going to suggest more often seems to make more
sense. We frequently fill the agenda and it's not like
people need to travel. We don't know TPAC time. Seems more
like late Oct or Nov so there's more of a chance for in
person. I think we should plan for more
astearns: I believe all our virtual meetings this year we did not
get through agenda. Slightly more frequent might get
through issues
florian: I will insist some fall in daytime my time is we have more.
I understand most people don't live in Asia but some do. If
we have many of them some should be at hours nice to people
in my time
astearns: I thought I was careful to make sure half was in favorable
times to you
florian: Somewhat the case. When I have meetings that end at
midnight or start at 5am I find myself thinking better than
3am but they're not great. If we're having many meetings I
would like some during my actual work hours. I know not
most will, but if there are many I'd like some at nice hours
astearns: Okay. We will continue on private list. Rossen and I will
propose something and then we can talk about it and
further meetings.
Reminder for re-joining group next week
=======================================
astearns: Everyone will be forced out and have to re-join because
we're opting in to the new patent policy. Everyone has to
click some boxes on a web form. If you don't get it by
early next week please let me know.
astearns: Just an FYI
Rossen: One more before technical agenda.
Rossen: Plan is to take the last 2 weeks of Dec off
astearns: Yes. We will meet next week and then no meetings for the
last 2 weeks of the year. It's been a long year, there are
holiday,s people need time.
CSS Text, CSS Fonts, and CSS Text Decor
=======================================
Distinguish applying to text vs applying to boxes
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5303
fantasai: Looks like chris merged the PR. This will change applies
to line for as many specs as I can think of. I guess heads
up it's merged. There were questions about writing modes
where so far text-combine-upwrite does apply and
writing-mode does not
fantasai: css 3 text we're getting toward 0 issues. If i18n and tag
sign off I'll ask to transition next week
florian: On testing front we're doing pretty good. Large amount of
tests and gaps documented. We have test for many things.
Don't need all for CR.
astearns: Any other bits on this?
astearns: It was just informative? No resolutions?
fantasai: I guess if we want to close 5303 which is the bug
astearns: Since PR is merged yes I assume
florian: Might have missed some, but none was wrong. Can open new
issue for anything missed
CSS Conditional 3
=================
Inconsistent phrasing around placement of @import rules
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5697
jeffery: Looks fine
fantasai: Remaining question is there is a stylesheet construct that
isn't for entire style sheet. Confusing and should change.
Should we file as separate issue? Concerns?
astearns: Tracked as a separate issue
fantasai: Should we resolve it should be changed?
astearns: Why don't you raise the separate issue, discuss there, see
if anyone disagrees, particularly TabAtkins.
astearns: We'll close this as editorial?
CSS Variables
=============
Higher level custom properties that control multiple declarations
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5624
leaverou: There is a very reasonable TAG guideline that custom
elements should use properties for presentational
elements. With current state of custom properties this is
impossible for non-trivial
leaverou: Current custom properties can only be literal fragments
and you need to transform
leaverou: There are problems where we need to add inline
conditionals.
leaverou: However, when you have lots of these properties
intersecting then it can get really messy if only 2 you
have is inline functions that need both conditions.
leaverou: Ideal is something to cascade but not sure feasible.
Wanted implementor feedback and then I can draft a more
detailed proposal
leaverou: Examples I've looks at from component liberties are in the
issue
leaverou: Some impl have weighed in in the issue [missed]
leaverou: Wondering if set of constraints could be introduced to
make it more feasible. Wanted to bring to attention of
group for more ideas or thoughts
astearns: Feedback on the shape of the feature?
fremy: I think it's a pretty good idea.
fremy: Really something that's a limitation of custom properties.
Quite true when you use attributes you do more than reuse
variable.
fremy: Pseudo class you can't use in theory but it would be really
nice to have syntactic sugar. I know you can do it meta
languages. Good to auto-prefix with an if() condition. That
would give us most of advantages. Extend the css selector
syntax to have an id for all properties
<TabAtkins> Assuming we're fine with simple conditionals in an if()
function (which we've discussed before and this should
be okay), doing an at-rule inside holding a block of
props could have a reasonable desugaring to that.
<TabAtkins> It would have some side-effects - any properties in the
block are effectively using a variable, so it would kick
in IACVT [invalid at computed value time] behavior, etc.
leaverou: One thing to keep in mind is these often need to control
multiple elements in the component. Alignment might need
to control margins and padding. Ideally should work
leaverou: [missed]
leaverou: Often they need to control properties in mutli elements.
Example alignment controls spaces, padding, etc in multi
child elements. Good to keep in mind that it plays nicely
with nesting module
leaverou: Some reasonable syntax to combine and falling back to
invalid at computed value time would prob be acceptable
<leaverou> As long as we can combine conditions and nest them,
having IACVT as the ultimate fallback is acceptable
<fremy> @TabAtkins: I would think it solves many issues
<TabAtkins> so like `.foo { color: blue; @if (var(--state) = one)
{ color: red; } }`, it'd desugar to `.foo { color: cond(
var(--state) = one, red; blue); }`
<TabAtkins> The nice part of this is that it inverts the grouping
from "all variants of a given property" to "all
properties associated with a given variant", which can
be much more readable in some circumstances.
astearns: I think this is a really interesting proposal and I'd like
to see further discussion on what we can do here. Any
major concerns about spending time on this?
astearns: I think we should take this back to the issue and/or come
up with a proposal which we can file issues on. It's a
really good idea. Anything else from group?
leaverou: I primarily wanted to draw impl attention. I can't design
impl needs. Continue on issue is fine
Grid, Flexbox, Quirks
=====================
Avoid percentage height quirk in new layout models
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5545
oriol: This is about this % quirk. When in the block axis you have %
and your containing block has auto height in quirks mode
sizing skips the ancestor until it find another with a
definite height and resolves % against this
oriol: For compat reasons must happen in flow layout. Quirks spec
says shouldn't happen for grid and flex
oriol: I'm proposing we should say quirk should not skip over grid
and flex items
oriol: The current behavior chromium has where grid item with auto
height and inside an element with % height it's resolved from
grid area not grid item. If item is stretched the height is
supposed to be definite. But knowing if we will stretch
before is tricky and I think it's bad to propagate this to
new layout modes
<fantasai> wfm
oriol: Firefox does not skip grid and flexbox items. WebKit skips
flex not grid. Chromium skips both. I think we should align
with Firefox and never skip
TabAtkins: I'm very satisfied to limit quirks here if other impl are
<dholbert> I'm happy to align with the Firefox behavior. :)
iank: I'm okay with this...it's a pretty late hour to do this change
to flexbox in particular but also grid. Chromium can try but
might have revert if there's web compat issues.
iank: I think WebKit is closer to Chromium than issue says and I
think it exposes a WebKit bug. I'm okay with this but want to
reserve the right to go back if there's compat issues
Rossen: One thing to double check, you said quirk shouldn't apply to
anything in grid and flex items. I didn't hear you say
anything about grid and flex items themselves
oriol: Grid and flex items have grid or flex container parent and
spec says about that already so already not happening.
Rossen: Means later subgrid as well. If we all agree with rule,
which makes sense, but we should define anything in a grid
boundary should not have to take the quirk
oriol: Not sure I would go that far. A grid item can have varied
structure. If you have nested block we could keep the quirk.
Maybe breaking that on whole tree of grid item would be more
problematic
Rossen: Having had to impl this quirk twice it's super nasty. Less
we have to do it the better. If we can't get away, it is
what it is
iank: I forgot to say a couple things. Would it be possible to
instead of relying on quirks spec pull it into flexbox and
grid specs? Quirks spec doesn't necessary spec correctly and
leaves open to interpretation
iank: Also, would have been nice if when Firefox did the change this
was brought up
dholbert: Sorry, I don't think I did enough testing of other
browsers when impl. I was aligning to quirks spec, I think.
dholbert: To forbidding quirk inside grid I think best way to think
is it tunnels up through blocks and if you hit an
unsupporting container it just stops. If you think of flex
and grid as an unsupporting container you have it. It's
not that flex items are special but that flex and grid
container are special
Rossen: I believe this is the exact issue. If flex or grid item fits
the bill and has a spec height you can use in quirks
algorithm this item can later stretch with a lot of
properties that effect fixed height.
Rossen: Fully agree we should have a stronger rule here about flex
and grid items to have them not partake in quirks.
Rossen: I don't disagree with anything you say, but the less we can
have the nasty quirk the better
fantasai: Note on edits, I don't think makes sense to have in flex
and grid. It's really a special behavior for block and
anything other then that should not have quick. Quirks
should say these boxes do this thing and if you hit any
other kind you terminate.
fantasai: In flexbox and grid we'd have to list a lot of exceptions.
astearns: I agree it should be defined in one place
fantasai: We don't have a block layout spec so we don't have a place
to put it
astearns: I was thinking flex and grid specs could have a note
saying we're not doing this thing for the reason it defines
fantasai: I don't think there's a natural place to put that. Update
the quirks mode spec, at some point it goes into a block
spec
oriol: Quirks mode mentions block containers, but grid and flex can
be block containers
fantasai: Whatever correct term is. Seems related to block layout
and not about flex or grid. It's not an exception, it's
block being special and that shouldn't have anything to do
with flex and grid items
Rossen: sizing?
fantasai: It's special for blocks.
Rossen: We have a lot of sizing things that do apply to not
everything
TabAtkins: I don't mind sizing since it will apply to table sizing
as well
astearns: Do we need a resolution to move the definition of the
quirk to sizing and be explicit about how it does not
apply to grid and flex items
fantasai: Need to say it's only blocks and tables.
astearns: Might be good to have as an example because has been
implementor confusion
plinss: Need to be careful about is this really a quirk and only in
a compat mode or is this normal css behavior?
fantasai: It's not normal.
plinss: Then it should stay in quirks and not be in a normal module
in my opinion
astearns: Fair. We do need to firm up the definition
fantasai: dholbert do you want to propose a change to quirks spec?
dholbert: I can take a look at it.
dholbert: Firefox behavior falls out of how I understood quirks
spec. I'll take a look
<jensimmons> I do think we need something to help future
implementors / anyone who doesn't remember this call to
know what to do if they are implementing Flex/Grid/
Future stuff. Something far off on the side is too off
in the side. A note, as Alan suggested, or something
would be good.
astearns: Proposal: dholbert to make a change to quirks spec to
clarify behavior in this case
astearns: And iank is okay with it being tried in chromium to check
for compat
plinss: Is this only in quirks or is it certain conditions of normal
css?
??: Only quirks mode
astearns: Objections?
iank: Test would be nice as well
astearns: Yes. Test would have shown this earlier, but thanks oriol
for finding. Can you write tests?
oriol: Didn't hear
astearns: Will need tests to show we have interop behavior. Could
you commit to adding tests?
oriol: Yeah
oriol: I think Firefox already has tests. I'll look better and write
some if needed
astearns: Would be great to have in WPT
RESOLVED: dholbert to make a change to quirks spec to clarify
behavior for flex and grid items and containers
astearns: Anything else?
CSS Color 4
===========
Minimum bit depth for serializing color() values
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5667
chris: Request for impl feedback. Spec says you must preserve 8
bits. Fine for sRGB but not for other color spaces. 2020 min
is 10 and recommended is 12. smfr said they're storing as
floats so they're good with whatever
chris: I think TabAtkins said it's 16 bit range. Would be great to
have more confirmation. I thought Chrome canvas rejected it
because too many bits
chris: Haven't heard from Mozilla
smfr: I want to clarify something. Careful to distinguish between
bits to store css color values vs depth of backing store.
Backing store can use half float. Have to be very specific
chris: Internal storage where when you serialize for OM you can
return with specificity
smfr: And that has not round-tripped between buffer
chris: Right
chris: Given that clarification can anyone from Mozilla answer?
astearns: Anyone from Mozilla willing to commit to finding the
answer?
astearns: Or could say who we could ping
dholbert: Start with emilio maybe. Not sure
astearns: Chromium clarification?
rune: I thought we just stored 32 bit.
chris: I mean 8 bit per component which is not sufficient except for
sRGB
chris: I think TabAtkins was talking about future plan
<chris> 16bit half float
TabAtkins: What I heard is plan to handle higher color profiles was
to switch underlying texture to be a 16 bit half float
per channel. It gives more than 8 bits of precision.
Don't know how that reflects rest of stack
smfr: But this is not about texture formats
TabAtkins: Underlying format of images we use to paint
smfr: This is storing colors in css data structure
TabAtkins: But if we're planning to deal with half-floats I presume
we'd reflect across internal stack
<smfr> generally code wouldn’t use half-float in data structures, so
you’d probably store floats
chris: Clear, but can you get someone to confirm. Else I'm going to
start putting bigger minimums and don't want people saying
can't do that.
iank: Not sure explicit details. I think we did have concerns about
increasing size of representing colors. I can find out about
this
chris: That would help, thanks
<emilio> in Gecko we store 32-bit integer, 8-bit per channel of rgba
<emilio> But we're going to probably do something else for new color
spaces or what not
<smfr> iank: webkit just sets a bit that says “go look at this other
data structure"
chris: 8 bit is a nice round stable thing. If you go beyond you
basically use 16 bits unless you're packing
<emilio> Yeah, same concern iank mentions about growing too much
style data structures
<emilio> At least when they're not using non-rgba colors
chrishtr: When you say min 10, 12 bits what section?
chris: Serialization on how you get back string of a color spec. How
many digits do you round to. 2 digits is 100 values which
isn't enough.
chris: I had said 8 bits but needs to be higher because will get
bounding. Depends on the space how many bits to avoid bounding
chrishtr: And what to know if min would be too large and make too
large memory buffer
chrishtr: I think need min possible because memory constraints are
possible. Memory is main reason I hesitate to add these
color spaces to chromium
smfr: Spec allows 8 bit even if allow extended svg. We render P3
colors because render to another color space. I don't think
this requires all buffers to be half float
chrishtr: To represent all things in color space you need more
resolution
smfr: Potentially yes
chrishtr: So you have 8 bits and map with different transfer function
smfr: Yeah, might get bounding. Have been shipping for years on iOS
and no complaints.
chrishtr: Is that compliant
chris: Spec doesn't say how many to render. Purely on rendering
chrishtr: Serialization or interpolation you need the bits. But if
browser uses lossy way to render that's quality of impl
chris: It's fine. Most frame buffers are still 8 bits. It's avoiding
cumulative rounding errors in processing which can blow up
chrishtr: Got it, thank you
chris: Sounds like we shouldn't close because need to get back.
Happy with discussion and okay to move on
astearns: Sounded like people are okay with spec something here
chrishtr: smfr, how many bits do you use in the WebKit CSS data
structure
smfr: If color is P3 we set a bit in our color data structure saying
interpret this as a pointer to another data structure and the
other data structure has the bits. We only pay the cost if
it's outside sRGB
chrishtr: If page had a bunch of P3 it would use 4 floats for every
color in CSS in the stylesheet, but not for every pixel
smfr: And only colors that are spec that way, not every color
chrishtr: And that's not similar memory impact because not common
rune: Current Chrome impl uses 64 bits. 32bit RGB and flags on
either side. System colors are keywords too
chris: That sounds like nice impl. Only pay cost if you need it
chris: Thank you! This is all I wanted to know
astearns: Only have a couple minutes. Not sure anything on the
agenda that's 2 minutes
astearns: I'll close the meeting early, thank you everyone
Received on Wednesday, 9 December 2020 23:56:04 UTC