- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 May 2021 19:06:49 -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 TypedOM
-----------
- Issue #1039 (CSSColorValue section needs WG review) brought to
light many different concerns which need to be split into
separate github issues and discussed. The biggest topic raised
which will need further discussion is the scope of CSSColorValue
and if it should be a generic color manipulation object. Since
there are several items in front of TAG which relate to this
question, it will need some prioritization for discussion once
the issue is created.
CSS Images
----------
- There was no strong opinion of which behavior to use on Issue
#6286 (Behaviour of SVG degenerate aspect-ratios) so the group
will wait to hear back from AmeliaBR before deciding.
CSS Color Adjust
----------------
- There is enough need currently to include the only value in the
first level of CSS Color Adjust (Issue #5089 (Re-add only to
mean "don't auto-adjust me", per WebKit's behavior)). smfr
provided a link that describes the current WebKit behavior in
order to guide the creation of spec text.
- RESOLVED: Add print-color-adjust as an alias for color-adjust and
have the generic color-adjust be deprecated (Issue
#3880: Combine forced-color-adjust and color-adjust
properties somehow?)
CSS Contain
-----------
- RESOLVED: Specify this in CSS Contain (Issue #5913: :root/body
viewport propagation and containment)
- RESOLVED: If the used value of contain is other than the default
we break propagation (Issue #5913)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021May/0005.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
David Baron
Christian Biesinger
Elika Etemad
Simon Fraser
Chris Harrelson
Daniel Holbert
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Dael Jackson
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Florian Rivoal
Cassondra Roberts
Alan Stearns
Miriam Suzanne
Lea Verou
Scribe: dael
CSS TypedOM
===========
CSSColorValue section needs WG review
-------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/1039
leaverou: This was committed in December 2020 as editorial. Has
stayed in spec and adds a new API. We thought needs wider
review. Especially because referenced by other groups and
proposed as accepting inputs for color
leaverou: Back in December when this was posted without spec text it
was an API for CSS syntax. At time had concerns but
assured it was not a color object. Chris and I have been
working on color object since July.
leaverou: Now saying it should be used as a color object. After
review seems unsuitable. Need to review if first we want
this as API for CSS syntax and second what is the scope of
the API; syntax or generic color manipulation
leaverou: For second one I have more strong opinions and arguments.
leaverou: Posted some thoughts in issue. Side discussion with plinss
and chris which is fairly long and misleading title. It
evolved into what should this API do
<chris> Lea's comment:
https://github.com/w3c/css-houdini-drafts/issues/1039#issuecomment-844185998
leaverou: Using this as a color API for the web I would object. Not
focusing on missing functionality, though there are
issues. They can be fixed. Not sure a typedOM should be
used. Example, color object should allow adding color
spaces by adding color code
leaverou: CSS color needs to use numeric objects, not numbers, which
makes API clumsy. As input accepts numbers but get output
you have to use .value and convert angles
leaverou: Worse, not always concrete. Could be a CSS math value
which is calculations
leaverou: Unclear to me when writing code snippit how I would do a
simple color manipulation like lightness if you get back a
CSS math value. What happens when you can't resolve into a
number?
leaverou: If we use this object as general color object this
complexity needs to be accounted for in author code
leaverou: And because it's CSS format it needs complex. CSS rgb or
CSS color object have different shapes. In order to read
the color you use different methods. Author code needs to
branch
leaverou: Even as an API it's awkward and that can't change as
typedOM object. It's trying to have an API do 2 things
TabAtkins: First thing, would love wider review. Review from
leaverou and chris has lead to nice changes. More eyes is
always great
TabAtkins: For the rest, I think this was too much of an info dump
to be done as a late agenda+ or a single issue on the
call. I would love to do this as a structured F2F where
people can review. I think people tuned out with the list
and I want to handle individually
astearns: It is a lot of information. Are you interested in arguing
for this should be a general color object?
TabAtkins: Certainly
astearns: We could have had a quick resolution if generally agreed,
but yes would need point by point
chris: Agree with leaverou about webGPU and type things where this
type of CSS internals don't want this approach. I don't think
they realized an object can be complicated and how many of
the details they don't care about as an input. Especially
when extended to be an output
chris: Also feel somewhat mislead because lot of discussions about
what this is and consensus was this is not a color object and
we should hold back. But then TabAtkins has been promoting
this as the color object for the web and even if another was
needed it would be complex and no one would implement. Being
told to sit back and wait because we're not designing it and
then whoops it is what we're designing doesn't feel like how
it should be designed
chris: I have a lot of specific concerns about things like color
gamut handling which I guess is under general review
TabAtkins: I dispute that I have been disingenuous.
astearns: I would like us to center on technical issues and not on
personal issues
chris: You're right astearns
astearns: Let's just talk about the API itself
<fantasai> I think it's fair to say that it's inappropriate to
commit an entire API under an editorial commit message
and then pretend it was always in the spec without asking
the CSSWG for review, though...
leaverou: When it comes to using CSS color values as input to other
APIs there doesn't need to be mention in spec. If they
stringify they can accept color objects. This isn't about
accepting as inputs, but about other uses
astearns: I appreciate you brought it to the agenda to get more
eyes. I do agree this is a little much for a single issue.
I'd like to see a lot of this broken out into particular
issues that we can discuss separately and not re-work the
whole deal
astearns: I would appreciate concerns with use on canvas APIs to
bring it up in those venues
fantasai: If we have major concerns with API it should be marked in
the draft so it's clear to anyone reading the intended
scope and if there are major issues. Maybe if Chris and
Lea and TabAtkins can work out a summary of the major
points of concern or confusion it would help people
reading understand what's in contention
chris: You're right there are many intertwined issues. Crucial
question is what are we designing. Are we designing a color
object for the web or a thing specific to CSS parts of which
can be used elsewhere. Without a clear sense of what we're
designing it's hard to scope other technical comments
astearns: Can you open an issue specifically on that saying are we
designing CSSColorValue as a color object for the web? And
particular issues that crop up there will need to be spun
out and they may depend on the general answer.
chris: Happy to do that
<chris> The more up to date Canvas proposal for WCG and HDR is here
https://github.com/w3c/ColorWeb-CG/blob/master/hdr_html_canvas_element.md
plinss: chris said a lot of what I want to say. I accept this is
bigger and needs more discussion and eyes. I'm concerned if
we push this to next F2F or a long term period that a lot of
work will be done in a direction without us picking one and
I don't want to get to where we're stuck
<lea> plinss +1
<chris> plinss++
<fantasai> plinss++
<florian> plinss++
plinss: I want to address the meta issue about purpose of these
classes before more work gets done leading us down that path
astearns: Happy to convene a meeting specifically on this as well.
TabAtkins: Wanted to say the scope of current work people are
building on is about an input to canvas APIs. Accept CSS
values as strings and want to accept as typedOM.
Everything you can express in typedOM is possible by
putting it in string form so any of those concerns have
been present since canvas was introduced. Anything
further about this being a general color object should be
discussed, but not as pressing because no one is building
on that in the short term
TabAtkins: Let's have the larger discussion when we can prepare and
have time for it. No reason to be afraid we're setting
anything by not discussing because nothing you can do now
that can't do in strings
plinss: I want to agree with TabAtkins in part and rebut part
plinss: TypedOM objects as inputs is non-controversial
plinss: Problem is what are we using as the output and that is more
pressing. There's eyedroppers and color inputs that TAG is
reviewing and they output colors and we need to tell them
how to input. Need shorter than 6 month answer
<TabAtkins> Oooh, I wasn't aware of those impinging on this work.
Sure.
<TabAtkins> (Our next f2f is sooner than 6 months ^_^)
astearns: Please continue discussions. New issues will be opened and
we'll come back
<lea> I will reiterate that using CSSColorValue as input is not
something that needs to be explicitly added to a spec, as long
as it serializes
CSS Images
==========
Behaviour of SVG degenerate aspect-ratios
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6286
iank: Digging into replaced elements. Series of test cases in grid
repo that is probing this and there's a subtle difference in
impl
iank: If you go to SVG issue it contains example in 1st comment.
When embed SVG in image need to know SVG intrinsic size and
aspect-ratio
iank: SVG are unique in you can have one or the other or both.
Firefox has intrinsic but no aspect-ratio.
iank: Blink and WK has both
iank: Specific example: have width 0px, height 50px. Viewbox says
aspect-ratio is 1-1
iank: Firefox has intrinsic 0x50 which matches Blink and WK.
aspect-ratio is different
iank: Firefox does one interpretation where treats aspect-ratio as
degenerate and null. Blink and WK go this is degenerate so
fallback to viewbox
iank: That's the crux of the issue
<TabAtkins> example: <img width=100px src="<svg viewBox='0 0 1 1'
width='0' height='50px'>">
<TabAtkins> what is the <img>'s height?
fantasai: If in general case have width of 1px rather than 0 we will
ignore viewbox and use aspect-ratio from width and height?
iank: Correct
fantasai: Because it's degenerate blink falls back to viewbox, and
gecko continues to ignore viewbox
iank: Correct. Written down in the CSS spec. Linked to SVG text but
it's same text.
iank: I don't think when algorithm was written it considered that
width and height could result in degenerate a-r
fantasai: Yeah, I don't think we considered this
iank: You can also specify width -50px and get same behavior
fantasai: I have no opinion of what we out to do here. Don't think
it matters for authoring. Would be interested to know what
AmeliaBR thinks
<TabAtkins> I too have no real opinion on how we resolve this. Both
behaviors seem reasonable.
iank: Yeah, tagged AmeliaBR on the SVG but haven't received a
response
fantasai: Is there a reason to do one or the other?
iank: Not particularly. Could argue blink/WK is slightly better in
that we use an aspect-ratio when it's available. But really I
don't expect authors to write this. Only reason I'm bringing
it up is there's 6 test cases asserting a behavior, I think
written by a Gecko engineer. Not clear those tests are right
fantasai: Yeah, should clarify
fantasai: As long as we can't think of a reason my inclination is
let AmeliaBR read and make a decision for us
fantasai: I can ping her
iank: Anyone else with thoughts?
astearns: This is just what to do in this edge case and theres no
real world changes we can think of that would result from
this?
iank: Correct. Not addressing because a bug. Going through grid test
suite and noticed this edge case was unclear
astearns: Happy going with AmeliaBR but also happy going with 2/3 of
engines went this way so let's spec
astearns: Leave until AmeliaBR comes?
fantasai: Or resolve to do whatever she says
astearns: Objections?
chrishtr: Question
chrishtr: Did we discuss if degenerate cases in non-SVG are handled
same?
fantasai: 2 sources of information for aspect-ratio. Most image
formats don't have that confusion. We have general
degenerate case, but here is when hit in more primary
source of information. Do we fall back to secondary?
iank: Some precedent in aspect-ratio where if you specify a
degenerate it falls back to image's aspect-ratio I believe
iank: Is that right?
fantasai: Don't remember off top of head but I think we decided that
to match SVG
<fantasai> "If the <ratio> is degenerate, the property instead
behaves as auto."
iank: With that small amount of precedent then Blink/WK behavior you
can tie together. aspect-ratio behavior is if it's degenerate
it falls back to next best thing
astearns: Did that answer question?
chrishtr: What I heard is it's much more uncommon because images are
unlikely to have 0 height
fantasai: Not a real world case
chrishtr: because SVG is replaced element it behaves different
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9292
iank: Example ^ showing fallback for aspect-ratio property. I spec
degenerate where it will use the images a-r
iank: That's the fallback. If we want aspect-ratio to have this
fallback being more consistent then blink/wk fallback makes
more sense
<cbiesinger> I mean, for a while a-r: 1/0 was a parse error
<cbiesinger> but I think that was changed for consistency with
calc() that computes to zero
<fantasai> and then changed to 'auto' because that's what SVG does,
IIRC ...
astearns: Given that bit of consistency shall we resolve on Blink/WK
and see if AmeliaBR objects?
dholbert: I weakly lean against that. Feel like with aspect-ratio
property if you're explicitly providing invalid it makes
sense to not do anything. In SVG we've got a usable height
and width and it makes sense that does establish a value
to use
iank: You can also specify -10px width and has same behavior. And
you don't render at -10
dholbert: True. More that aspect-ratio is downstream. Don't feel too
strongly. Feels a little weird adding a special fallback
that no one will need for real content. I think it's a
trivial change
fantasai: I think we should wait and hear back from AmeliaBR. She
might have SVG logic that leans one way
CSS Color Adjust
================
Re-add only to mean "don't auto-adjust me", per WebKit's behavior
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5089#issuecomment-840840562
TabAtkins: There's some details which I don't have clarity on
exactly behavior of 'only' keyword. Something about
suppressing auto-darkening. Since I don't have great
details and browsers aren't trying to ship force
darkening I propose punt to L2
smfr: Even though not in Safari it is in the mail app and we
consider CSS to cover non-browsers. Only is UA should not
apply auto color adjustment to content.
smfr: One of the issues spec doesn't address is color scheme and
forced color interaction. Interesting on how color scheme
should interact with forced colors and can authors opt out of
forced colors
fantasai: Do have a property to opt out
<fantasai> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
smfr: We do but separate. I think need mind-meld of color scheme,
color adjust, and forced color adjust and I don't think spec
teases it out
TabAtkins: We preferred to say don't merge, they're separate, and
treat them as such. I think that's the next issue
smfr: I guess I'd like to hear from an implementor that has both to
understand how they interact
chrishtr: Chromium has both. I believe they don't interact
chrishtr: Some chromium browsers to have auto-dark mode that's use
controlled. Ex Samsung internet. Content opting out is
important where auto-darkening doesn't work well
TabAtkins: Alright, was under assumption there wasn't anything out
there. We should address. I'd ask smfr to provide more
details on how this works so we can add a spec
TabAtkins: Would like to know what things cause dark and light to
happen, the whole shebang so we can write a spec for it
smfr: There's a URL for original proposal we implement.
<smfr> original proposal on which color-scheme is based:
https://github.com/w3c/csswg-drafts/issues/3299
futhark: We also have opt-out of forced in Android. We use meta tag
presence as a way to opt out for web view apps
fantasai: Answering about interaction. If you have forced color and
can determine if it's light or dark we force color scheme
to be that. Color scheme and MQ get changed by forced
colors. Color scheme does not cause forced color to do
anything
smfr: Forced color always wins?
fantasai: Yes and changes color scheme to match
smfr: Only way to opt out is forced-color-adjust property?
fantasai: Yeah
astearns: So we'll continue to discuss and not punt?
TabAtkins: Yeah
Combine forced-color-adjust and color-adjust properties somehow?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3880#issuecomment-839880816
TabAtkins: Been an issue for a long time wondering if we can combine
the properties and generalize into a larger thing that
controls color adjustments
TabAtkins: After discussion fantasai and I concluded we shouldn't
because addressing different issues. Don't think
appropriate to make it easy to turn them all off at once
fantasai: And have WG resolution on this
<fantasai> https://github.com/w3c/csswg-drafts/issues/3880#issuecomment-816280715
<fantasai> https://github.com/w3c/csswg-drafts/issues/3880#issuecomment-816275920
fantasai: Reason it's on agenda is leaverou brought up information
about color-adjust property and looking at data. That
color adjust mostly affects print but has generic name it
seems like it should be shorthand. There was
-webkit-print-color-adjust. Looking at that wondering if
should call it print-color-adjust and leave color-adjust
as a deprecated alias
<smfr> +1 to print-color-adjust
fantasai: Reason it was generic is we thought it would be a generic
switch but it doesn't end up working well. Having a
generic name is more confusing than helpful
<lea> +1 to print-color-adjust
astearns: Seems reasonable to be more specific, though have to
support both
florian: Wondering while not fully generic are we sure it's not more
generic than print? Not wasting energy for screens with
different profiles. There might be adjustments similar to
print but not actually print. Or are we ruling those out?
fantasai: Good point but majority of use is for print.
smfr: There is a potential application. If we do HDR colors they
have a power usage impact so this may allow authors to decide
if high energy colors are allowed
florian: Thanks for a more concrete example. Could a default be
suppress and opt in or no default suppression?
smfr: Haven't decided yet. Maybe prevent cross-origin. Who knows
chris: Implementations require an explicit request for HDR current.
I think that would be the case here
florian: So could be applicable?
chris: Certainly
florian: Should we punt and explore that topic? Or is there time
pressure?
fantasai: 2 open issues on color-adjust. One is waiting on review
and the other we just discussed. Not much time pressure
astearns: Point of moving the name is to disabuse that color-adjust
is a shorthand?
fantasai: yeah
astearns: Pretty weak reason to add another name
fantasai: And that people are using print-color-adjust and WK is
-print-
florian: We're aliasing through shorthanding so we could add
highdef-color-adjust and then color-adjust is a shorthand
astearns: Deprecate the generic until we have a need and than
un-deprecate?
chris: I like combining the 2 if we need it
florian: And can do separately
florian: Introduce print, make the non-specific a shorthand but call
it deprecated for now
astearns: Arguments against?
astearns: Proposal: Add print-color-adjust as an alais for
color-adjust and have the generic color-adjust be
deprecated
RESOLVED: Add print-color-adjust as an alias for color-adjust and
have the generic color-adjust be deprecated
<fantasai> Note https://github.com/w3c/csswg-drafts/issues/5710 is
the major issue still open
CSS Contain
===========
:root/body viewport propagation and containment
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5913#issuecomment-836692271
futhark: I was not in APAC call so clarification questions.
Resolution says stops propagation if there is containment.
Applied or contain property?
futhark: Does paint containment stop it? Any containment?
futhark: And then there is which spec does this go into? Various
specs that talk about propagation or the CSS Contain spec?
futhark: I don't know if anybody had opinions
astearns: So where does this get specified?
florian: Suggest contain spec, possibly with notes pointing to it
astearns: Objections to spec this in CSS Contain
RESOLVED: Specify this in CSS Contain
astearns: What types of containment change propagation?
astearns: Any non-default or all of the values that create a
container?
futhark: Problem with those that establish a container is we may
need to change behavior as we add values
futhark: Can spec as the containment necessary to establish a
container but that breaks content if you use containment
for all things
astearns: Downside to saying we break propagation for non-default
value?
futhark: Don't think so. Not strictly necessary
florian: Feels overkill, but is it really bad?
fantasai: My thoughts exactly
florian: We're not effecting any amount of propagation from root,
it's from body to root?
futhark: Body to viewport and potentially root
futhark: Also for applied containment. Used or applied
astearns: Sounds like your preference is that if the used value of
containment is other than default it breaks propagation
futhark: Yep
astearns: Slightly worried that things which use contain:paint might
depend on propagation but can't think of a reason
<iank> I think its a non-issue here
florian: In the absence of container queries, doing containment on
body might not be common, so we're probably fine
astearns: Proposal: If the used value of contain is other than the
default we break propagation
astearns: Objections?
RESOLVED: If the used value of contain is other than the default we
break propagation
<chrishtr> \o/
astearns: Other questions on your list?
futhark: No
astearns: I think we are done for the day. thanks everyone for
calling in and we'll talk next week
Received on Wednesday, 19 May 2021 23:07:32 UTC