[CSSWG] Minutes Virtual F2F 2020-07-31 Part II: CSS Typed OM, Property Values API, Worklets, Grid [css-typed-om] [css-property-values-api] [worklets] [css-grid]

  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
      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
  - 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


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:
             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
  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
  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
  [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
  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
  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
  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,
  TabAtkins: Person seems to believe causing perf issues, I'm not sure
  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
  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
  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
  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

  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
  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
  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,
  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


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
  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
  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
  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
  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
  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


  Rossen: We have lots of specs that are outdated and needs
  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


  <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:36 UTC