[CSSWG] Minutes Lyon F2F 2018-10-23 Part IV: Constructable Style Sheets, Scrollbar Styling, CSS UI [css-scrollbar] [css-ui]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Constructible Style Sheets

  - This spec is being managed in the WICG
(https://wicg.github.io/construct-stylesheets/ )
      but was appearing to be close to closing issues and moving it to
      the CSSWG.
  - As the group reviewed the current spec they developed new issues
      and questions, so this will stay in WICG for now to iterate and
      get close to no open issues. Issues/questions raised in the
      meeting include:
      - What happens if you adopt on the shadow root and then import
          into another document
      - Web compatibility and how to handle issues where a style sheet
          is rejected, then discovered to be okay
      - Adding add/remove methods instead of forcing the author to
          manipulate the FrozenArray
      - Add a note explaining how imports kicked off by the style
          sheet impact the load event
      - Is there a need to create a style sheet that takes a URL?
      - Use of FrozenArray vs style sheets

Scrollbar Styling

  - RESOLVED: getComputedStyle() resolves <color> values same as other
              color properties, but other keyword values return as the
              keyword. (Issue #3237)


  - Some implementation effort has been put into the appearance
      property which uncovered some fundamental assumptions that
      aren't agreed upon (Issue #3024).
  - The core of the question is if the property should just have
      auto|none as values, if there should be a list of supported
      appearance values and a none, or have auto, none, and a
      limited set of values as required for web-compat.
  - Google developed a use counter to try and limit the number of the
      -webkit appearance properties it supports, so there will be more
      detailed information in 3 months. Preliminary information from
      zcorpan will be added to the github issue


Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: fantasai

Constructible Style Sheets

  <dbaron> https://wicg.github.io/construct-stylesheets/

  rakina: Making CSS style sheet objects directly constructible and
          also use them with shadow roots
  rakina: 3 new methods on document
  rakina: createCSSStyleSheet(), will return promise of CSS style sheet
  rakina: One synchronous createEmptyStyleSheet()
  rakina: And one createsomethingsyncsomethingobject()
  rakina: allows @import rules
  rakina: For using constructed style sheets there will be a new
          attribute on document or shadow root interface
  rakina: ...
  rakina: Constructed style sheets can be added to adoptedStyleSheets
          on document or shadow root
  rakina: same as stylesheet constructed on
  rakina: constructed style sheets are part of document style sheets,
          are after the document or shadow root's stylesheets from the

  rakina: Blink has a working implementation and has resolved most
          issues. Interested in shipping
  rakina: Open issues regarding usage of style sheets in
          [https://github.com/WICG/construct-stylesheets/issues/ ]
  rakina: and also issues of style sheets from style elements and link
  rakina: Interested in shipping style sheets that aren't used in
          multiple documents
  rakina: and ....

  TabAtkins: Detail of the API, for review
  TabAtkins: We resolved in the issues...
  TabAtkins: We have 2 constructors, async and sync
  TabAtkins: async allows anything from normal stylesheet
  TabAtkins: And matching JS modules semantics
  TabAtkins: It downloads all the imports and waits for them to finish
             before fulfilling the promise
  TabAtkins: Can use straight away when all data is ready
  TabAtkins: Synchronous version does not block
  TabAtkins: Blocks but disallows import
  TabAtkins: No waiting for network requests
  TabAtkins: Wait for parsing of stylesheet only
  TabAtkins: Thought that because style sheets might be large we might
             not want sync
  TabAtkins: But if we don't do this, ppl will want sync
  TabAtkins: And they will do it by split style sheet text into rule
             chunks and assemble them
  TabAtkins: So made sync function
  TabAtkins: Does have implication for CSS parsing API
  TabAtkins: that Greg and I have been planning to work on
  TabAtkins: Because "maybe this is big, we should make it async" ...
             should reflect this the same way
  TabAtkins: If you can build something out of sync pieces, don't
             worry if the larger thing is also sync

  bz: I'm still a little confused about the multiple document part
  bz: In particular if you're allowing this in the shadow root, they
      can change which document they're associated with
  TabAtkins: So issue 23?
[https://github.com/WICG/construct-stylesheets/issues/23 ]
  bz: You're planning to resolve this by disallowing ? what are you
      disallowing exactly?
  TabAtkins: If you want to use a style sheet in a shadow root, you
             have to create it from the shadow root not the containing
  rakina: No, you can create from the containing document
  TabAtkins: So what happens if you adopt on the shadow root and then
             import into another document?
  rakina: We don't handle that already
  rakina: If you're adopting something, then you need to check if the
          adopted style sheets are still valid or not
  rakina: If not on the same document tree, then won't be used
  TabAtkins: Was going to suggest requiring it constructed from
             shadowroot, but then can't use same stylesheet on
             multiple elements
  bz: I don't know that you want to solve this right now?
  TabAtkins: Can you file an issue?
  bz: There's no link to file issues?
  <rakina> https://github.com/WICG/construct-stylesheets/issues
  ewilligers: We linked to some issues from agenda, so try to get to
              the repo from there?

  rniwa: I think there are some bikeshedding to be done, it's kind of
         strange to have 3 methods like this
  rniwa: Also seems strange to formalize on sync vs not,
  rniwa: Supporting or not supporting import is pretty significant,
         names should reflect that somehow

  rniwa: Bigger issue is that multiple shadow roots in more than one
         distinct document can refer to a single constructible style
  rniwa: That can lead to some weird relationships between documents
  TabAtkins: We currently disallow adopting a style sheet if its
             document isn't the right document, I believe

  domenic: My concern is web compat
  domenic: If we silently disallow, and then suddenly figure out how
           it works, that's bad
  TabAtkins: It should definitely throw an error

  rniwa: But what happens when shadowroot that already uses the style
         sheet goes to use it
  TabAtkins: Moving around, we haven't thought of
  rniwa: We can resolve those issues

  rniwa: I'll add that, another thing I'm a bit concerned about is
         frozen approach
  rniwa: I think there are cases where you might want to add style
         sheets in a different class hierarchy
  TabAtkins: They can do that in constructors
  rniwa: Would be better maybe to add/remove style sheet that modify
  TabAtkins: Take the frozen array off the dom property, turn it into
             a normal property, and then assign it and it freezes
  <Domenic> sr.adoptedStyleSheets = [...sr.adoptedStyleSheets,
  rniwa: I understand that, but perhaps the API that ..
  rniwa: It's not that we don't want to have a list of style sheet,
         but better to have an add/remove API instead
  TabAtkins: Having discussion of how list APIs should work on the web
  TabAtkins: Tried to make this simple so that we could figure it out
  TabAtkins: Not against adding sugar for making this, but would
             prefer to defer until we figure out how to do arraylike
             objects better
  rniwa: This is different from other style sheet list
  rniwa: This would be very different from document.stylesheets
  rniwa: From author's perspective, you have stylesheets added by
         style element and link element
  rniwa: Those show up in document.stylesheets
  rniwa: Have another property that has document.adoptedStylesheets,
         would expect it to work the same way
  domenic: The frozen array api is a superset, except it's missing the
           .item method which hopefully nobody uses

  chrishtr: I believe spec does not say what is the relative timing of
            resolving the promise and display to the screen, is that
  TabAtkins: Those are two separate issues. You can't assign the
             promise anywhere, have to wait for it to finish, then
             take the style sheet out and put it in
  Rossen: The promise gives you the constructed object. Not part of
          the collection yet.
  chrishtr: OK, get style sheet from promise and then assign it

  emilio: ...?
  TabAtkins: Runs in JS, doesn't block more than anything else
  emilio: Whether the promise blocked the load event
  bz: Real question is whether imports kicked off by the style sheet
      would block the load event
  bz: Which is how ? works
  TabAtkins: There's no case that an async construction API blocks the
             load event
  TabAtkins: Until you put it into the document style sheets, it
             doesn't do anything
  TabAtkins: It's just an async call that ...
  bz: Not clear, spec needs to say that it's not blocking
  Domenic: Given how unclear the spec is, need to say explicitly
  TabAtkins: We can add a note, sure

  TabAtkins: Question about applying issue before document finishes
             loading, that's unsolved
  bz: Normal loads and imports block load
  TabAtkins: Because they already apply to the document. The imports
             are trying to apply
  emilio: Why would it be different from document......
  Domenic: ...
  Domenic: Equivalent of being connected is done after you apply the
           style sheet
  emilio: You would never trigger a load for an unconnected link
  emilio: What happens if you adopted somewhere unconnected shadow root
  Domenic: It's sill disconnected
  Domenic: Agree it's different from normal, but it's reasonable
  Domenic: It's nice that it doesn't block the load event
  TabAtkins: Don't see how it could block the load event

  Rossen: rniwa, anything you're looking for in terms of resolutions
          before you leave?
  rniwa: I don't think we need any resolution today

  Rossen: e.g. using frozen array vs style sheets
  Rossen: Do we want to go through specific issues or close the topic?
  rniwa: Either works fine
  rniwa: I don't have a preference for frozen array just because it's
         a new thing we want to try
  TabAtkins: They're not new
  rniwa: For consistency sake, because other lists of style sheets are
         not using frozen array, I think we should use the same as the
  Domenic: We're trying to work away from legacy ??
  Domenic: Current best idea is to use frozen arrays, because so API
  TabAtkins: Can you file that as an issue?

  rniwa: One more thing, we probably want to have another create style
         sheet that takes a URL
  rniwa: Pass it to this api
  TabAtkins: We didn't do that because fetch() takes a lot of options,
             and if we don't reproduce all those options it's limited
  TabAtkins: and if we are reusing, then it's duplication, might as
             well just use fetch()
  Domenic: ...
  Domenic: Other apis have taken a promise as a response, pass
           directly ?
  Domenic: This is the pattern we've seen
  rniwa: All the @ rules are automatically fetched using CSS, not
         overwriting that
  rniwa: Not sure it's useful to support all fetch options
  TabAtkins: Dealing with cross-origin stuff, etc.
  Domenic: There are attributes in HTML that reproduce part of the
           fetch() api, could reproduce that in JS...
  <Domenic> The pattern is, like WebAssembly.instantiateStreaming()
            etc., to accept a Promise<Response>, then you could do
            e.g. document.createStyleSheetFromResponse(fetch("..."))

  Rossen: Any specific resolutions that you're looking for? Also, are
          we continuing to work on this in WICG or should it be pulled
          into CSSWG
  TabAtkins: We didn't anticipate getting a bunch of new issues here
  TabAtkins: But they're good issues
  TabAtkins: But means goal of driving down last issues and promoting
             it isn't satisfied here
  TabAtkins: Given that we have broad browser interest, do we thing we
             should move over to CSSWG or leave in WICG?
  <heycam> +1 for bringing it to CSSWG

  dbaron: Do you want it to be in CR?
  TabAtkins: Soon. Want to resolve all issues asap
  TabAtkins: Want to resolve all the shadow dom issues that depend
             on it
  dbaron: Moving it into the WG comes before CR. :)
  Domenic: We prefer to iterate in WICG and get field experience
           before moving it
  Domenic: So I would keep it there

  dbaron: I just filed two issues. I didn't know this spec existed
          until an hour ago
  bz: ...

  Rossen: Sounds we don't move it to the WG just yet
  Rossen: Going to close this topic for now
  Rossen: Hope you got enough input from the WG
  Rossen: For those interested please follow the spec now
  <astearns> https://wicg.github.io/construct-stylesheets/index.html

Resize Observer

  astearns: There's a session tomorrow about resize observer, find it
            tomorrow if you are interested

Scrollbar Styling

  tantek: We did FPWD already
  heycam: Not sure who put this on the agenda, but I can make a demo
          if ppl want
  tantek: We have an implementation in nightly

Resolved value of scrollbar-color
  github: https://github.com/w3c/csswg-drafts/issues/3237

  heycam: Question about what should happen with getComputedStyle()
          and the scrollbar color
  heycam: Not sure we want to use resolved value
  heycam: Strange to have auto value become something else
  heycam: Would like to use the actual computed value

  dbaron: Is there a distinction between "auto or computed color" and
          auto and used color?
  emilio: We resolve computed color
  heycam: I don't think we should resolve auto to a color

  tantek: Also this is two colors, not just one
  tantek: We had two properties, folded to one
  tantek: Can also say if you want dark or light theme scrollbar colors
  tantek: so not just a color property, a bit more complicated
  fantasai: So if you specify a non-<color> keyword, return that
            keyword, otherwise return the same kind of resolved color
            as other color properties
  <tantek> resolved colors (plural)

  RESOLVED: getComputedStyle() resolves colors same as other color
            properties, but other keyword values return as the keyword.

Demo & Feedback

  [heycam demos Firefox's implementation]
  <gregwhitworth> very, very cool heycam
  <heycam> gregwhitworth: thanks!
  <heycam> gregwhitworth: (thanks should go to xidorn!)

  tantek: Based on this implementation experience, we're pretty happy
          for light and dark for colors, and being able to specify
  tantek: Dark is interesting for web apps that have a dark theming
          regardless of what the OS theme is

  tantek: Regarding width, having just thin vs not has been sufficient
          for the use cases we've needed
  tantek: We haven't implemented the <length> value and would be OK
          with dropping that
  tantek: Don't know if there are other implementers that have thought
          about this since Sydney


Appearance Property
  github: https://github.com/w3c/csswg-drafts/issues/3024

  florian: zcorpan has been working on spec for appearance
  florian: Lot of good work. Very detailed investigation of what
           property values do what
  florian: Research on which values have specific behavior, which need
           to be just not "none"
  florian: There is a lot of interesting details we should talk about
  florian: But need to address fundamental issue
  florian: There have been different assumptions from different ppl,
           need to crack that problem first before discussing specific

  florian: As appearance has been specified in css-ui
  florian: Has two values: auto and none
  florian: auto turns HTML elements that have particular native look
           and feel into that look and feel, and none turns it off
  florian: That design doesn't have more values, but can have more
  florian: Similar to how you've specced it on your value, could say
           that e.g. button turns things into button
  florian: Or can say that some additional values are accepted but
           turn into auto
  florian: You do not have auto
  florian: And you have a finite list
  florian: Which implies you need to do something special for HTML
           elements that have special rendering but don't have a
           corresponding keyword

  zcorpan: I want to point out that I've received from implementers
           that they want to limit the property, what it applies to
  zcorpan: Currently in most implementations you can turn any element
           into any appearance
  zcorpan: but they want to limit that to whatever is required for web
  florian: Yes
  zcorpan: So that button can only apply to buttons
  zcorpan: So I tried to look at web compat through http-archive
  zcorpan: What combinations of values are used
  zcorpan: e.g. some pages set button on a select element
  zcorpan: In Safari/Chrome/Firefox make it a button
  zcorpan: But in Edge it doesn't do anything except make the drop
           down arrow no longer render
  florian: That is not covered by the spec I have, but is compatible
           with that model

  florian: What is an example of a value you have found is not needed
           for web compat?
  zcorpan: Didn't add inner-part of meter/progress elements
  zcorpan: implementations ...
  florian: Do you have an example of a value that is supposed to apply
           to an element (not a pseudo)
  zcorpan: Everything that is in UA style sheets by default on actual
           elements is in the spec
  florian: I think we have previous resolution of this WG that we did
           not want to do this
  florian: We did not want to have the full list of everything.
  florian: We *can* spec that, but it means every time HTML adds a new
           form control, we need to add a new value
  florian: So far as I have heard, especially from MSFT, not all
           values that were used in UA style sheets were needed for
           Web compat
  florian: If we are going to specify the full list of all the values
           you need to write the UA style sheet
  florian: That is a thing we can do
  florian: But so far we've indicated that we wouldn't do that
  florian: And if list needs to be shorter than what's needed to UA
           style sheet
  florian: And if it's shorter, you still need to be able to write
           your UA style sheet
  florian: This is where 'auto' comes in. Everything that doesn't have
           a corresponding value in the short list has 'auto' in the
           style sheet,
  florian: Then author can turn it off with none

  <gregwhitworth> can someone clarify the action of this - is this to
                  get the webkit props into CSSUI?
  <Rossen> gregwhitworth, yes

  florian: Another issue is that some of these values and pseudo
           elements are needed to coordinate with values assigned to
           particular non-standard pseudos
  florian: And WG strongly does not want to add those
  zcorpan: In FF and Chrome, it's possible to have values only
           supported in the UA style sheets
  zcorpan: So if there are internal parts of form controls that have
           stuff in the UA style sheet, we can just do that
Scribe: TabAtkins
  fantasai: I think that's not something we should be trying to do in
  fantasai: Only when we have to.
  fantasai: This doesn't seem like a case where we must have this
            model, where values are only valid in some contexts.

  fantasai: Why aren't we able to go with a model where we have none/
            auto/[few more]?
  fantasai: And a pile of keywords that compute to auto?
  fantasai: That seems a lot simpler than adding a bunch of values
            that can only be used in UA stylesheet.
  zcorpan: I think the model is in principle the same.
  zcorpan: In my proposal I don't actually have the auto keyword, but
           otherwise it works the same.
  florian: Given that "auto" is the initial value in my proposal, if
           you don't have it you don't have the same model.
  zcorpan: Yeah, it's different, and I agree. Mostly because it's
           different from what's today.
  zcorpan: Mozilla tried to implement and had webcompat problems with
           the initial value being auto.
  fantasai: You can make initial be "none", then have UA stylesheet
            set it to "auto" on all necessary elements.
  florian: What was found incompatible was having no valid but "auto".
           If you have a few extra values, it might work.
  florian: Models are different where if you don't have auto, you must
           have the entire list, even if you only expose some part
           of it.
  florian: CSS says every element has a value for every property, you
           can expose it via gCS().
  <emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=1333482
  <emilio> (fwiw)

  zcorpan: The non-exposed values are only on internal pseudos, not
  fantasai: I don't know why we have to standardize any values the web
            can't see.
  zcorpan: Not saying we need to, it's an impl detail.
  fantasai: But still every form control needs a non-none value, and
            ideally the author should be able to set it *back* to that
  zcorpan: Yeah, revert.
  florian: But revert isn't a value on its own.

  iank: I think we'd like to reduce the number of values we currently
  iank: Last week tkent (maybe?) added some high-precision
        use-counters to track these.
  iank: So in about 3 months time we'll have very accurate usage data.

  dbaron: I think some of what's going on here is that a bunch of
          people have constraints that haven't really gotten thru to
          the other side.
  dbaron: I think it's not particularly clear to me or to engineers at
          Mozilla why we want to do things that deviate from the
          already-existing stuff.
  dbaron: Every time the group makes a bigger deviation, that
          increases the risk of having to spend more time dealing with
          the fallout.
  dbaron: So how many months do you want to spend on it (and thus
          delay work on subgrid)?
  <gregwhitworth> +1 to what dbaron said

  florian: I think there are 3 possible models.
  florian: 1 is we specify all the values, including the ones on
           pseudo-elements, because you need them all for a UA
  florian: 2 is we specify the subset for webcompat, leave undefined
           the rest, and specify some mechanism about having values
           that exist only in the UA stylesheet (and what that implies
           for computed values, etc.)
  florian: 3 is we replace this heap of values with an "auto" value
  florian: Reason to not do what's currently implemented is that it
           depends on different, UA-specific lists. And the model
           depends on the full list.
  florian: So creating the full list looks like a lot of work.
           Creating a mechanism to hide it is also a lot of work.
  florian: If we want to make a new cascade-hiding mechanism, we need
           to actually do that. Can't just spec "appearance" assuming
           it exists.
  florian: I assumed it didn't, so my two possibilities were #1 and #3.
  florian: Looks like a reduced list is desirable.
  florian: So that rules out #1. So we're left with reduced list with
           "auto", and reduced list with cascade-hiding mechanism.

  <tantek> why are we bothering with anything appearance except for
           -webkit- compat?
  <tantek> As the person who introduced the appearance property, yes,
           it was an attempt to do something we thought we wanted at
           the time but have long since abandoned.
  <tantek> We should spec it for the compat spec and that's it.

  franremy: This property was created to do something nobody wants
  franremy: Making an arbitrary element look like a button.
  franremy: First we found we don't need that, second it's bad.
  franremy: In Edge we implemented some values, but it doesn't do
  franremy: We just parse a bunch of values because the stylesheet
            needs them.
  franremy: I don't think we need to go further.
  franremy: So if the model we want is just to allow disabling the
            rendering, then let's find that subset we need (we already
            have that list implemented), then do auto for everything
  fantasai: I agree with fran├žois
  <florian> so do i

  zcorpan: So what Edge does is kinda like the approach I'm aiming
           for. And Edge doesn't support "auto" itself.
  zcorpan: I think, Florian, you keep coming back to having to spec
           the full list...
  florian: Or hide the values; UA-sheet-only isn't a real thing that
  zcorpan: They're only on internal pseudo-elements, not web-exposed.
  florian: They're exposed via gCS().
  florian: I'm confused why you keep saying our models are the same.
  florian: Even if they're restricted to pseudos, we still want to
           reduce the list - Ian does.
  zcorpan: Agree.
  florian: And so if we reduce, what do we return from gCS()? That
           must be specced.
  florian: We already know we want less than the full set.
  florian: So we have some number of HTML elements that have a value
           we don't want to expose. What do we do for those?
  zcorpan: My understanding is that all the elements with an
           appearance, we'd specify a value for those.
  florian: That's not what Fran├žois or Ian said.

Received on Sunday, 2 December 2018 11:26:21 UTC