- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 21 Feb 2016 14:47:25 -0500
- To: public-houdini@w3.org
- Cc: www-style@w3.org
=======================================================
These are the official Houdini Task Force minutes.
Unless you're correcting the minutes,
please respond by starting a new thread
with an appropriate subject line.
=======================================================
Properties & Values API
-----------------------
- The group decided to go issue by issue and see if enough
decisions can be made to resolve on FPWD for the spec.
- Due to implementation complexity, the spec won't introduce
parse-time errors.
- It was agreed that registerProperty() and unregisterProperty()
should not trigger a CSS reparse and instead invoke whatever
happens when you change style rules through the CSSOM, but the
spec text needs to explain it better.
- Apply hook will drop to the next version of the spec.
- More formal description of registerProperty required, but won't
block FPWD.
- A better example using a typed custom property to define a color
will be added (available here:
https://github.com/w3c/css-houdini-drafts/issues/77)
- setProperty will be dropped in V1 in favor of just having types.
If there's sufficient demand it can be added back in later.
- The following types will be in the spec:
- color
- image (maybe)
- url (maybe)
- lists of values
- transform functions (maybe)
- url
- integer?
- angle
- time
- resolution
- shane will look over animatable types and see if there's any
others that should be added.
- The spec will need to do substitution into transition/animation
properties before animation so that this example works:
animate: var(--props) var(--dur);
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016
Scribe: dbaron
Properties and Values API
=========================
Spec Overview
-------------
<shane> link to spec:
https://drafts.css-houdini.org/css-properties-values-api/
<shane> link to issues:
https://github.com/w3c/css-houdini-drafts/issues?q=is%3Aissue+is%3Aopen+label%3A%22CSS+Properties+and+Values%22
shane: There's things to look at; the spec itself, and issues list.
shane: We'll start with spec itself.
shane: Let's go through inline issues and then those in the issue
tracker, and work out how to resolve and edit now, or
decide it can remain in FPWD.
shane: So that all issues that need to be done for FPWD are done
shane: Sound good?
shane: We've been through this spec a couple of times, but if
people are interested we can go through section by section
smfr: How about a high-level refresher?
shane: Properties and values API adds 3 things
shane: (1) the ability to provide a type for values of custom
properties, which are the types familiar with, through
registerProperty where you provide a syntax, e.g. <length>,
<number>, refer to existing properties
shane: ... or |-separated list of things
shane: (2) as a consequence of having types, allows custom
properties to be animated
shane: (3) (which I propose we drop) provides an apply hook that
allows modifying the used value of other properties as a
result of computed value
Rossen: Computed?
shane: Right, computed, not used.
smfr: How does animation work?
shane: Just through the types, no customization.
shane: There's interest in customization for future levels.
registerProperty and unregisterProperty
---------------------------------------
shane: Going through issues:
shane: First issue is: when you call registerProperty and
unregisterProperty, you need to reevaluate a bunch of stuff.
shane: ... what we want to say is that you need to re-parse
specified values of properties which are impacted ...
properties named in register/unregister, and recompute
style based on those changes.
shane: So if I say registerProperty("foo"), I need to find
references to foo (existing custom property).
esprehn: Need to reinterpret tokens.
shane: Need to recompute style.
shane: I wasn't sure how to write that.
heycam: What's the existing wording?
dbaron: I think most existing wording is around static situations.
esprehn: Invoke wording about how variables change?
heycam: What happens with .style setters, zcorpan?
zcorpan: They set a string, gets parsed, becomes part of cascade.
heycam: So it updates style sheet, and implicitly recomputes.
shane: One thing that isn't completely clear is that registering a
property can change a declaration from compute-time invalid
to being parse-time invalid.
heycam: So this introduces parse-time invalid for custom
properties?
shane: Yes.
shane: --foo: url('donkey'); color: red; color: var(--foo); is
computed-time invalid.
heycam/dbaron: but color: var(--foo); is always valid at parse
time.
dbaron/esprehn: Agree var(--foo) shouldn't become parse-time
invalid as a result of registerProperty.
esprehn: The thing you want to refer to is re-invoke the
"Substitute a property" algorithm.
<esprehn> https://drafts.csswg.org/css-variables/#substitute-a-var
<esprehn> we want to modify that to support types, and whenever
the type changes, you run that algorithm again.
ojan: Why do you want a parse-time error?
shane: It's only a weak desire, but adding understanding of
computed-time invalid was something I hoped we could undo.
ojan/dbaron: It adds a lot of implementation complexity.
shane: Okay, let's not do it.
esprehn: None of this happens at parse time -- tokens that get
substituted in.
esprehn: Type information just says that if you register, check
that the tokens are the right type.
ojan: With --foo: red; --foo: url('donkey'); we'd need to keep
both around in case somebody called registerProperty on foo.
shane: So you need to keep around multiple?
shane: As long as it's ok for custom properties to fundamentally
behave differently from standard properties...
ojan: I like the simplicity, but makes it hard to get polyfills
right.
shane: Implementations can choose to do another parse run after
registerProperty.
heycam: If the type information were at the top of the style
sheet, could avoid sudden change.
heycam: Local to the style sheet.
shane: Too much of a restriction -- polyfill would have to infect
all style sheets.
dino: <barely audible>
shane: If you have a handle on a style rule through the CSS OM,
that shouldn't change.
dbaron: We don't have lazy parsing of declarations.
shane: Neither do we.
esprehn: Can't evolve the API, e.g., can't write the old thing
first and then overwrite with the new thing
heycam: Do typed things work inside @supports?
shane: We haven't decided.
shane: It's clear we need this to happen.
dbaron: We need to be very careful if you can put things in
@supports that change what engine supports.
heycam: I think parse-time rejection would be ok for us.
shane: Calls to registerProperty will require reparsing.
heycam: ...
dbaron: It requires storing the whole cascade of token streams,
not just winning one.
ojan: I'm reluctantly ok with this for blink now that we've talked
about it. Need to tell authors to call registerProperty up
front.
shane: If you call registerProperty halfway through, you might...
<shane> https://github.com/w3c/css-houdini-drafts/issues/63
shane: we need this (github comment link) to be true
<zcorpan> https://github.com/w3c/css-houdini-drafts/issues/63#issuecomment-177034609
[heycam and shans clarify example and heycam agrees with comment]
ojan: What happens if you try to register same property twice?
iank/esprehn: It throws.
ojan: I think this is a bad idea, but I'll propose: what if you
say that registerProperty on a property that's been parsed
threw?
iank/esprehn: racy.
ojan: yeah, ok.
shane: Come back to issue of how to phrase correctly.
dbaron: I *think* it *changes* the specified value
shane: Or can fix after FPWD.
dbaron: Or at lunch.
shane: Do we need the pseudo attribute on ....
shane: Oh, wait, we're going to drop apply
shane: Issues 2, 3, 4, 5, 6, 7, 8, and 9 don't matter
ojan: Thing I'm sad to lose about dropping apply, need apply hook
for polyfilling something like flexbox, since children of
flexbox get coerced to display:block -- need apply hook to
do that.
ojan: Similarly for grid.
iank: Also potentially another hook before layout, creating
anonymous boxes.
ojan: But supportive of dropping for v1, not mission critical for
paint.
surma: Wouldn't you polyfill flexbox with layout worker, not with
paint?
ojan: But if we had layout, you'd need apply hook.
shane: When I remove it from here, I'll move it to a level 2 spec.
heycam: High-level question; how will authors be polyfilling
properties -- can't use official property names -- will
they work like they do with prefixes, and then have
another line that's the -- version?
shane: Depending on how we can get custom paint and custom layout
to perform, we may never need the not -- version.
shane: I think it'll almost certainly be true of custom paint.
shane: Many examples of people constructing complex DOM trees that
are much better replaced by custom paint.
shane: People can write custom border/background polyfills that
are permanently polyfills.
ojan: The thing I said makes no sense -- really developers will
just need to switch over at some point, since we won't have
magic that makes foo override --foo.
dino: Maybe people will want to use the implementation version if
it's there
zcorpan: I was thinking you would use the standard property in
@supports and unset the -- version there probably
<zcorpan> though one can do @supports (not (foo)) { x { --foo:
... } } instead
shane: If supported, could also registerProperty to an
always-invalid thing so declarations dropped at parse time.
shane: Houdini issue #67 -- seems like we can go to FPWD without
an algorithmic description -- just a set of requirements.
iank: Covers corner cases like which error you get when you do 2
things wrong.
heycam: Seems good enough.
setProperty
-----------
shane: We need to add an example -- using a typed custom property
to define a color that's then used as a single stop in a
gradient to animate a single stop.
(shane types example into github issue #77;
https://github.com/w3c/css-houdini-drafts/issues/77)
[discussion about difference between "<color>" and "<'color'>" in
parser syntax]
<zcorpan> Value: <color> --
https://drafts.csswg.org/css-color-4/#the-color-property
dbaron: In this particular case they're the same.
ojan: So this consistency is to match something that's only in
specs today and not exposed to authors?
dbaron: "<'z-index'>" references the values accepted by z-index;
"<length>", "<number>", etc., are types.
[esprehn and shane discuss implementation details]
[esprehn doesn't like this]
esprehn: It's not that simple in all engines.
(Apple bison parser)
heycam: It seems like you already have setProperty in the OM
esprehn: Why is this a v1 feature rather than only types?
dino: Yeah.
shane: I could drop it and go back and improve the set of types in
the spec.
ojan: Between impl complexity and weird syntax worth dropping for
now,
ojan: and get back if we get developer demand.
shane: It makes it impossible to tie a custom property syntax to
an existing complicated property (e.g., shorthand).
shane: Can't do things like the background shorthand.
shane: This would be a single longhand custom property that you
want to substitute into a shorthand later on.
zcorpan: It seems a bit weird; might make harder to introduce real
shorthands to API later on.
shane: I can see weird; not clear how it makes it harder to
introduce real shorthands.
shane: Just for interaction with existing ...
shane: In terms of paint use cases this is unimportant.
shane: We need a more primitive level of type to do animation
properly, so let's just drop it.
iank: If we ever do it, "<'--foo'>" shouldn't be valid.
shane: We have <length>, <number>, <percentage>,
<length-percentage>, <custom-ident>, any ident
[shane explains each]
shane: We obviously need to add <color>.
dbaron: Should we look over list of animatable types in
transitions?
dbaron: Maybe have <integer> vs. <number> -- most of the rest of
https://drafts.csswg.org/css-transitions/#animatable-types
is more complex.
zcorpan: <angle>
dbaron: and maybe also <time>
zcorpan: <frequency> ?
(discussion, probably not)
smfr: What about lists?
ojan: How do urls ... what's their type?
ojan: It turns into image in most cases?
[discussion about <image> type]
dbaron: I think if you add <image>, you should probably also add
<url> as an independent one.
zcorpan: <resolution> (dpi/dppx).
shans: Transform functions.
esprehn: That's not a v1 feature.
shane: There's strong animation use cases.
shane: Not any harder than other ones.
surma: does that include ???.
esprehn: ...
shane: That's already in the typed OM
zcorpan: <position> type for background-position.
dbaron: Probably not go down that rabbit hole.
shane: We could have some form of rounding behavior for integers
in typed OM rather than having different types,
shane: and avoid having separate integer type.
shane: I'm inclined to drop <integer> at this point.
ojan: I think most critical thing is how soon to get multiple
interoperable implementations, so would like to cut for v1.
shane: We can drop angle, time, resolution, integer, url... keep
lists of values, transform functions.
[shane edits comment on new github issue he's creating;
https://github.com/w3c/css-houdini-drafts/issues/99]
surma: What about timing functions for animations?
shane: We're allowing use of the existing animation framework, so
don't need that here...
zcorpan: <image> contains <url>; doesn't make sense to drop <url>
and keep <image>
esprehn: For just animations, smaller list, but custom paint wants
<url> and <image>
<zcorpan> <image> = <url> | <image()> | <image-set()> | <element()>
| <cross-fade()> | <gradient>
https://drafts.csswg.org/css-images-3/#typedef-image
dbaron: I'm worried about hacks where people use <image> when they
mean <url>.
shane: Do we even need <image> rather than just <url>?
iank: One thing I was thinking for custom paint is that you have a
handle you can draw to canvas rather than the bytes.
iank: I think they're actually 2 separate things -- keep <image>
but don't allow getting at the bytes
ojan: This is not the existing image type
shane: It is... the typed OM representation of the image type.
heycam: I have some reservations about <image> vs <url> and
treating them differently.
heycam: If you could accept all CSS meta-syntax, if you decomposed
<image> into how it was defined in the spec, it would be
weird if it was defined differently.
ojan: Say image url and transform functions are maybes, and we'll
get back to them once discuss custom paint.
shane: For some of these (color), how it's animated is the same
across all properties, but for lists of values, there are
different sorts of animation behavior.
shane: Transforms has non-repeating list and repeating list.
shane: It's fairly standard; list valued properties adopt one or
the other.
shane: One last issue, github issue #79 in css-houdini-drafts;
https://github.com/w3c/css-houdini-drafts/issues/79
shane: This example works per the custom properties spec,
shane: but once we have typed properties, it won't work.
dbaron: I don't see why it doesn't work.
dbaron: I think ticking transitions/animations happens before
computation -- transitions/animations affect computed
values.
shane: Maybe this is an implementation detail?
shane: If everybody is clear that this should produce an animation
of width, maybe just put example in spec.
ojan: Question for implementors: does this animating make sense?
dino: The whole thing is crazy.
surma: People will try transitioning on their custom properties.
ojan: This example and the one above it should behave the same.
dbaron: It makes sense to me that they both work.
shane: I'll import second one as example directly into spec.
shane: To go back... want to ask one question about issue #99
shane: Specifically, dino and smfr, which is better for you?
Better to have a list of things or to reference property
names?
smfr: I prefer explicit list; referencing properties is harder for
us.
smfr: Angle, time, and resolution are just simple combinations of
number + unit -- seems sad to defer them.
shane: OK, can just put back on.
shane: A little grunt work to get spec ready -- would like
volunteers to help with that.
dbaron: I can help.
Rossen: Do we need a resolution to publish?
shane: Let's make edits first, then come back for resolution.
<br type=lunch>
Received on Sunday, 21 February 2016 19:48:25 UTC