- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 2 Dec 2018 06:25:17 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
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)
CSS UI
------
- 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
(https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-431339106
)
===== FULL MINUTES BELOW ======
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
DOM
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
document
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
sheet
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,
newStyleSheet]
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
platform
TabAtkins: Tried to make this simple so that we could figure it out
later
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
true?
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
element
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
other
Domenic: We're trying to work away from legacy ??
Domenic: Current best idea is to use frozen arrays, because so API
compatible
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("..."))
directly
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
=================
https://www.w3.org/TR/css-scrollbars-1/
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
colors
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
CSS UI
======
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
issues
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
values
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
compat
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
general.
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
elements.
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
value.
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
support.
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
stylesheet.
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
anymore.
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
anything.
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
else.
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
exists.
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