- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 16 Aug 2020 08:04:42 -0400
- To: www-style@w3.org
- Cc: public-houdini@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.
=========================================
Houdini: CSS Typed OM
---------------------
- leaverou and chris presented their work on converting between
color spaces and developing utility functions.
(Issue #989: Color Conversion and Contrast Ratio).
The sample code for the color spec is listed in
https://drafts.csswg.org/css-color-4/conversions.js and
https://drafts.csswg.org/css-color-4/utilities.js
and a color library is being developed at https://colorjs.io/
to explore API options for a color type and also to explore
various methods of implementing higher-level color calculations
in CSS. The group agreed that the work done so far is great
and looks forward to proposals informed by this work.
- One of the core goals of a new color type would be to handle
color space conversions, since those are tricky.
- TabAtkins will write a test for mutation observer for style attr
changes via TypedOM to verify that the problem in Houdini Issue
#997 (Concern about attributeStyleMap updating the style
attribute) is due to devtools being open.
- RESOLVED: TypedOM reifies values as simplified form (mirroring
getComputedStyle etc.) (Houdini Issue #965: Simplifying
away calc() wrappers around single numeric values when
reifying)
- RESOLVED: Put the list in a "value" property, and add a forwarding
for compat (Houdini Issue #948: Using ObservableArray
for the list-ish values in TypedOM)
Houdini Property Values API
---------------------------
- RESOLVED: Keep all fields in @property required (Houdini Issue
#994: Make all the descriptors optional)
Houdini Worklets
----------------
- RESOLVED: Ban data URL from spawning a worker (Houdini Issue #985:
Ban data URL worklets)
- RESOLVED: Update the worklet spec working draft
CSS Grid
--------
- RESOLVED: Update the CSS Grid L1 CR
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#friday
Scribe: fantasai
Scribe's scribe: TabAtkins
CSS Typed OM
============
Color Conversion and Contrast Ratio
-----------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/989
<leaverou> CSS Color 4 sample code:
https://drafts.csswg.org/css-color-4/conversions.js
and https://drafts.csswg.org/css-color-4/utilities.js
Rossen: This issue motivated by TAG review about addition of lch and
lab color spaces
Rossen: One concern being discussed being discussed with TAG was
that we were getting more variety of color across platform
Rossen: but capabilities of simple things like contrasting two
colors is very difficult
Rossen: One of the ideas was, hey, if we have a strongly defined
type for color that we can use across platform
Rossen: then we could look at exposing variety of functions either
on or around object
Rossen: and achieve objectives like a11y and other things
Rossen: Seemed like TypedOM is good place to start
Rossen: Color is a type we need to define strongly
Rossen: Luckily Lea and Chris jumped in, had been thinking about it
chris: In color 4 there was an appendix written in JS by which I
mean Pascal
chris: It's simple, does work, set of simple functions
chris: Also have utilities.js
chris: includes a contrast function
chris: Here's an sRGB_to_LCH
chris: it does it all in the right order
chris: It was useful for examples
chris: and useful for color 5
chris: but this is not a proposal for a color model
chris: not object oriented
chris: it's just something that works
chris: Here's color.js
chris: Until this morning was a private repo, now public
<leaverou> https://colorjs.io/
chris: Also not a proposal, but it's object oriented
chris: This is a JS API, you can use it in the browser or on the
server
chris: These examples are all live, you can edit directly in the web
page if you want
chris: Variety of color models, includes all in color 4 (except
device-cmyk()) as well as a few more
[leaverou demos]
chris: Notice these are in different color spaces
chris: Internally it goes into CIEXYZ, and then ??, and then gets
you a contrast
chris: You just say you want contrast between two colors, and it
just works out for you
chris: You can change lightness or chroma or whatever
chris: similar to things we do in Color 5
chris: Convert between color spaces
chris: interpolate between colors
chris: either discreet steps, or gradients, or that sort of thing
[chris reviews documentation]
chris: Color object. Can give a CSS string or use initializer with
coordinates
leaverou: Color space ID plus coordinates plus optional alpha
leaverou: or another color
chris: This is similar to color-5, adjusting named coordinates
chris: We've actually supported more than Color 4 supports
chris: might be interesting to see if any would be useful as future
additions
[chris notes there's bugs, especially in the documentation, since
this is pre-release]
chris: You can change color coordinates. Don't even have to change
coordinates of the color space you're in
chris: That's fairly useful
chris: We also do gamut-mapping
chris: because easy to get colors that are out of gamut
chris: We've worked on that quite a bit, have an algorithm that
works rather well
chris: Do a binary search to find closest color via chroma reduction
chris: and do speculative clipping
chris: 1st one we reduce chroma until it's inside the range
chris: 2nd one, at each stage, we see if we clipped here, would we
be close?
chris: and that works much better
chris: thinking to spec that in color-4 spec
chris: Interpolation
chris: range function allows that and getting intermediate stops
leaverou: Range function actually returns a function
leaverou: we can specify which space to do interpolation in
leaverou: You can see here examples of what each interpolation space
produces
leaverou: We also implemented longer/shorter/increasing/decreasing
args for the hue we were discussing
leaverou: although didn't implement dbaron's ? yet
chris: Lets us implement and check and see if it works. Very helpful
in writing spec
chris: Also discussing using Nan for keeping coordinates constant
leaverou: but we do keep Nan for chroma
chris: It's on GH and there's a link, and also a bunch of tests
chris: Any questions at this stage?
Rossen: First of all, this is awesome, thanks for sharing
Rossen: Looking forward to playing with the project
Rossen: that's exactly what I was hoping to see
Rossen: and you made this fantastic
<fremy> big +1 this is super great!
Rossen: Wrt functions like color-mix() etc.
Rossen: Let's say we start going towards adopting such a type in
TypedOM, where does that leave us?
chris: You'll have 2 ways to do it: declarative in color-5, and
imperative way like this
chris: imperative can have more functionality
chris: I don't think it's a problem that we have both declarative
and imperative
leaverou: ...
leaverou: Haven't done adjusters yet
leaverou: Accepts a color space as well, but not adjusters
chris: As general goal, would like to implement all of color-5 so we
can test, and do example, see how that works
chris: Another thing people might have noticed, there's a few more
color spaces here not in color 4
chris: Support high dynamic range coors
chris: There's a secret spec called css-color-hdr
chris: there was an issue around high dynamic range
chris: I said we won't do it, because too unstable
chris: but I did spec an extension to color-4
chris: and wanted to see that it works and coded it up
chris: I presented to ICC and got good feedback, currently
incorporating that
chris: will present to the WG later
chris: In the meantime, I'm incubating it in code to see whether
it's feasible
<leaverou> https://drafts.csswg.org/css-color-hdr/
AmeliaBR: Great library, very useful. Some similar things, but this
is a nice API with good features
AmeliaBR: Wrt what we should adopt into the actual Web platform
AmeliaBR: I do like the idea of having general color utilities object
AmeliaBR: That you can call without having to getComputedStyle
AmeliaBR: coordinating with TypedOM also good
AmeliaBR: so you can construct CSS color type or get it from a style
rule or a computed style
AmeliaBR: that would be great design
AmeliaBR: Probably don't want quite as many features as we have in
this library
AmeliaBR: Might want to integrate a bit more e.g. generated gradients
AmeliaBR: and easing functions would be its own object, to use more
generally than just color
AmeliaBR: Interpolator for data visualization
AmeliaBR: would be a great feature, use native interpolation that
CSS already knows how to do
AmeliaBR: with additional smarts like interpolating in different
color spaces
AmeliaBR: also useful to have
astearns: Anything else besides showing new cool code?
Rossen: How do you see this moving forward?
chris: Requirements, one of them for web platform API
chris: what features do we want, what would be nice, what would be
layered on top
chris: Rossen asked about contrast, that's important
chris: Converting between color spaces without having to understand
how it does
chris: not knowing about white points, not having to figure that
out, that's important
leaverou: There should also be way to access color before / after
gamut mapping because that affects the results
AmeliaBR: Especially important for finding contrast ratio
AmeliaBR: if colors are theoretically good contrast, but not on
user's screen, need to reflect that
florian: So is the plan to subset your project into TypedOM? and
then build your project on top of that result?
chris: Would be reasonable
astearns: If you can't build on top of the subset, then we chose the
wrong subset
Rossen: That was part of my hope
Rossen: exactly why I was provoking this type of discussion and
exposure in typed OM space
Rossen: Anything else left on color that you didn't cover?
leaverou: ICC profiles
leaverou: In theory, TypedOM should cover that as well
leaverou: but wouldn't that make it asynchronous?
TabAtkins: We already have a few things that need external
resources, don't have a great way to handle that
TabAtkins: but nothing else needs to be infected, just wait for them
via Promise
chris: Mentioned that we have a lot of stuff. Because we wanted to
test things against each other
chris: e.g. deltaE, implemented 5 different variants
chris: wanted to compare visual result, performance
faceless2: ...
florian: Feels like what we need is the various objects and methods
to let you get from one to the other, and create mixes
florian: don't necessarily need all the operations to get from one
color to another color
florian: maybe need ? and ?, but methods to get between them, but
TypedOM doesn't need
chris: Do need an intermediate way to go between colors
chris: You use colors together, not in isolation
AmeliaBR: Base case would be converting single color into other
color spaces
AmeliaBR: so you can convert two colors into the same color space in
order to compare or calculate
AmeliaBR: Devs can implement the formulas that use whatever
parameterization of colors that they need
chris: Yep
Rossen: I agree
Rossen: That was initial motivation here, exposing the type that
will allow you to at least hoist the color space and its
values
Rossen: Having this type, you can start adding libraries around it
that do a bunch of math
Rossen: As we go forward, can identify which math goes into native
platform and which stays as library
Rossen: but not having basic type is a blocker
Rossen: My hope and ask for you, is to start defining what this type
should look like
Rossen: what is minimum set of parameters and stuff
Rossen: I see Tab and fremy still editing TypedOM, so work with them
to move it forward
fantasai: I want to note that Typed OM has also not been published
since 2018.
Concern about attributeStyleMap updating the style attribute
------------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/997
TabAtkins: I'm not sure if this is an actual concern to worry about
TabAtkins: Wanted implementor advice
TabAtkins: When doing high-frequency updates, like during TypedOM
TabAtkins: use single transform object, setting over and over again
TabAtkins: but are seeing the style attr get updated in real time as
well
TabAtkins: so reserialization happening constantly as well
TabAtkins: We saw as a performance concern
TabAtkins: So is this actually causing trouble?
<AmeliaBR> isn't this an observer effect of having Dev Tools open,
maybe?
TabAtkins: Person seems to believe causing perf issues, I'm not sure
myself
TabAtkins: but if we are eagerly reserializing to style attr, not
great. Negates a major advantage of TypedOM
TabAtkins: Apparently we don't ???
TabAtkins: but if you look in inspector, do see it being constantly
updated
TabAtkins: But either way..
emilio: Mutation observer thing, it should fire mutation observer
callbacks except in some cases
emilio: afaict, internally we don't serialize until asked for
emilio: if that's devtools, then we reserialize all the time
TabAtkins: If that's true across browsers, then I can close as no
change, browsers are smart enough to handle appropriately
don't worry about it
fremy: Meaning?
TabAtkins: Browsers aren't eagerly serializing
iank: File a bug against Chrome? we should investigate this
TabAtkins: Apparently Chrome doesn't fire mutation events
TabAtkins: that's a bug in chrome
fremy: Because we still want to update the style attr, every single
time
fremy: Can we put something in the spec that says when?
AmeliaBR: It's on demand
TabAtkins: When someone asks for it, or is observing the style attr
fremy: So flag it?
fremy: Ok
TabAtkins: Sounds like the resolution should be, browsers should be
smart enough to lazily serialize style attr when necessary
TabAtkins: I can put a note in the spec
AmeliaBR: One thing to consider, should this be a general thing for
DOM attributes reflected?
AmeliaBR: Working with CSSOM or other things to be consistent?
TabAtkins: yeah.....
TabAtkins: existing string OM, not doing any restringifying, but
sure there are some reflected attrs
TabAtkins: In HTML... I'll check if HTML has wording on that
ACTION: TabAtkins investigate restringification of reflected attrs
across OMs
<RRSAgent> records action 1
fremy: Not always the user that gets the style attr
fremy: e.g. if you have a selector that depends on the style
attribute's contents
fremy: Should never happen. Shouldn't change the DOM when
recomputing CSS
TabAtkins: DOM has it internally tracked, doesn't need to update
everything to keep consistent except on demand
emilio: Style attr keep not a string, but a CSS declaration and an
attached string
emilio: When request string, we serialize it
emilio: Someone requests DOM attr, will get the correct value
smfr: Normally we don't specify internal details
smfr: Would just be a QoI issue about when serialization happens
smfr: Spec shouldn't say anything, should just specify web-exposed
behavior
TabAtkins: Agree
TabAtkins: I will close no change, review HTML to see if they have
any particular wording
* fantasai thinks a note is useful to implementers, to pay attention
to the issue, though agree shouldn't be specced
AmeliaBR: Only other thing is to make sure wording is clear wrt
event hooks
AmeliaBR: Should trigger mutation observers even if not serialized
until asked for
ACTION: TabAtkins write a test for mutation observer for style attr
changes via TypedOM
<RRSAgent> records action 2
Simplifying away calc() wrappers around single values
-----------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/968
TabAtkins: If serializing computed or used value of calc(), gets
simplified down
TabAtkins: at that point, you remove the calc() wrapper if
simplifies down to a single component
TabAtkins: This behavior doesn't happen in TypedOM
TabAtkins: it retains the calc() wrapper
TabAtkins: Not sure if we should try to adopt or not
TabAtkins: if particular impl concern, I don't have a strong
opinion...
AmeliaBR: From authoring side, if you wanted to go in and manipulate
the value in the wrapper and still have clamping effects
of calc()
AmeliaBR: e.g. calc(-5px) in property that's positive values only
AmeliaBR: Where the clamping value would be different with a plain
-5px. Not sure how clamping would be different in TypedOM.
TabAtkins: If you set a calc() it'll get that behavior, if you set a
simple numeric value it won't
TabAtkins: If you want to do math, can do it without having already
wrapped in calc regardless
TabAtkins: In particular, emilio brought this up in a CSS issue
emilio: I think getComputedValue is px value because can simplify
away, so I think everyone should do the same
emilio: Would be annoying in implementation to maintain that
information
emilio: about whether was wrapped in calc or not
TabAtkins: ok, propose to resolve that TypedOM reifies value as
simplified form
RESOLVED: TypedOM reifies values as simplified form (mirroring
getComputedStyle etc.)
<br dur=10min>
Using ObservableArray for the list-ish values in TypedOM
--------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/948
scribe: fremy
scribe's scribe: fantasai
TabAtkins: I tried to get better support for array-like classes in
WebIDL
TabAtkins: because we have three things that expose lists, and could
benefit from this
TabAtkins: but given I made no progress, I ended up using the legacy
"getter/indexer" of WebIDL
TabAtkins: but sadly that means that it's not an array
TabAtkins: and you cannot use forEach etc on them
TabAtkins: You have to convert them to an array first
<TabAtkins> https://heycam.github.io/webidl/#idl-observable-array
TabAtkins: but Domenic fixed this for me
TabAtkins: and we have the observable array type
TabAtkins: For the javascript user, it looks like an array
TabAtkins: but it still triggers callbacks that allow us to type
check things
TabAtkins: So I'd like to switch to that
TabAtkins: Unfortunately that would result in a breaking change
TabAtkins: Indeed, the value itself cannot be an array
TabAtkins: because it has to subclass the CSSValue type
TabAtkins: so we need to store the list in a "values" member
TabAtkins: For the math-value types, it's easier because it's
already a FrozenArray
TabAtkins: So I can just switch it
TabAtkins: Any objection to do this change?
AmeliaBR: So, if I understand, you now need to do "x.values[0]"
instead of "x[0]"?
TabAtkins: If I don't accommodate that by making a special behavior,
yes
AmeliaBR: Could we then make a putforward?
TabAtkins: Yes, we definitely can
TabAtkins: and we could do that by just updating the code to do that
and lookup in the array
AmeliaBR: Browser support?
TabAtkins: Yes, typedom is shipped in chrome
TabAtkins: because paint api
AmeliaBR: I would not like to break demos
TabAtkins: Yes, let's make the accommodation, it's not worth
breaking the demos
AmeliaBR: (restates)
TabAtkins: (yes)
fremy: I'm entirely in favor
fremy: Always thought it was really weird that ? and forwarding you
couldn't index it
fremy: so much cleaner for the API
fremy: not only improvement that you get an array
fremy: definitely in favor
fremy: and forwarding sounds like a no-brainer
TabAtkins: ok
TabAtkins: Any concern from implementers?
TabAtkins: Looks like no?
TabAtkins: Any objection to adopt the change in the issue, with
forwarding kept in?
RESOLVED: Put the list in a "value" property, and add a forwarding
for compat
Worklets
========
Ban data URL worklets
---------------------
github: https://github.com/w3c/css-houdini-drafts/issues/985
TabAtkins: Next topic comes from AnneVK
TabAtkins: You initialize a worklet by passing a url
TabAtkins: You can do that using a data url to avoid using the
network
TabAtkins: annevk says that this can be an issue
TabAtkins: for security reasons
TabAtkins: Blob urls would still work
TabAtkins: but data urls apparently have some issue
TabAtkins: Any comment?
AmeliaBR: Can we add a note showing how to use a blob url?
TabAtkins: Why not?
TabAtkins: Any suggestion?
RESOLVED: Ban data url from spawning a worker
Property Values API
===================
Make all the descriptors optional
---------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/994
AmeliaBR: With the at-property rule shipping, people started taking
a look
AmeliaBR: There were complaints that all the fields have to be
explicit
AmeliaBR: and this is not very css-y
AmeliaBR: In general, css does handle defaults better
AmeliaBR: and by making all these things be required, you remove
some behaviors
AmeliaBR: Reasons why people use this
AmeliaBR: - transition values
AmeliaBR: - prevent inheritance
AmeliaBR: - provide default value
AmeliaBR: You don't always want all three
AmeliaBR: and now you have to set all of them, which is not always
useful
AmeliaBR: Worse, you cannot say "this is a color or it is invalid"
TabAtkins: That default value thing is a different issue
TabAtkins: I agree we should fix this
TabAtkins: The other two cases
TabAtkins: the inheritance one is that in JS, true has a default
value is not logical
TabAtkins: and we don't want to default to inheritance, because this
is more costly
TabAtkins: but having the default be the revert of the normal choice
is confusing
TabAtkins: So, we think forcing people to think about this is good
TabAtkins: I think that issue is well settled, we really want to
keep this in
TabAtkins: For the syntax, we could use the unrestricted syntax "*"
as a default
TabAtkins: but I don't think that this is what you want
TabAtkins: because it cannot do anything useful for you with this
syntax
TabAtkins: If we make this required, authors get an error, and they
learn about this
TabAtkins: and they realize they could have a better behavior
TabAtkins: and "*" is not that common so I don't think it will be
common enough to warrant the default
TabAtkins: and there are other places in css where we force people
to specify a value even if we have an obvious default
TabAtkins: Like for example fonts
TabAtkins: we force you to say "serif" as fallback
TabAtkins: even though it could be implied
TabAtkins: but we thought forcing people to think about the fallback
is useful
AmeliaBR: You said that throwing an error makes more sense
AmeliaBR: but in the non-declarative syntax, this works differently
emilio: there are browsers where you can see CSS errors
emilio: ;-)
TabAtkins: I think this information is surfacable
TabAtkins: If some browsers have a less-than-useful way of surfacing
this, we can fix
TabAtkins: but I still think "hey this doesn't work" is better than
making it work less well
TabAtkins: AmeliaBR do you feel about this strongly?
AmeliaBR: Not a huge deal I guess, won't object
AmeliaBR: However, I think that the solution to the other issue is
very important
TabAtkins: Yes, that's another issue, and there is another thread
about that, and I think we are in agreement with what you
wanted?
AmeliaBR: Can you send a pointer?
TabAtkins: yes
<astearns> https://github.com/w3c/csswg-drafts/issues/5370
TabAtkins: So, it sounds like we should be able to resolve to close
this issue no change for now
TabAtkins: Any final objection?
RESOLVED: Keep all fields in @property required
Publication
===========
Rossen: We have lots of specs that are outdated and needs
republishing
Rossen: and most are just working drafts
Rossen: so republishing should be easy
Rossen: For example worklets
Rossen: No republication since 2016
Rossen: We only have one editor, iank
Rossen: and that is probably not a focus of his to update specs
Rossen: So, can we get another editor?
Rossen: Also, what other things do we need to do in worklets?
Rossen: because if not, can we get this to CR?
Rossen: (or, we merge it with html)
florian: I think we should update the working draft
florian: irrespective of whether we want to merge
florian: It only takes a few minutes to do
Rossen: there are a few issues in this spec
Rossen: but not much
Rossen: TabAtkins, anybody else could help contribute to this spec?
TabAtkins: I'm not sure
TabAtkins: Raymond Toy worked in web audio
TabAtkins: which use some aspects of worklets
TabAtkins: but not sure if there's desire to become editor
chris: there are also folks at mozilla implementing it
Rossen: who?
<chris> paul adenot, mozilla
AmeliaBR: Handing it over to the spec that explains the window
context makes sense
AmeliaBR: but I think updating the publication before sounds useful
RESOLVED: Update the worklet spec working draft
Rossen: We also need to republish layout paint typedom
Rossen: properties and values are ok though
fantasai: Can we talk about grid in the last few minutes?
Rossen: Yes, we don't need resolutions for the others
CSS Grid
========
Publication
-----------
<fantasai> https://drafts.csswg.org/css-grid-1/#changes
<fantasai> https://drafts.csswg.org/css-grid-1/issues-cr-2017
Rossen: We need to publish a new CR
fantasai: Yes, we have DoC, tests for changes, etc...
fantasai: and there is a lot of them, so we should really update
fantasai: There are a few issues left over for the next revision
fantasai: oriol said it would be ok to republish
fantasai: and I support
oriol: (confirms)
Rossen: Any objection to republish CR of Grid L1 with these changes?
RESOLVED: Update the CSS Grid L1 CR
Received on Sunday, 16 August 2020 12:05:35 UTC