- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 9 Oct 2016 20:39:22 -0400
- 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.
=================================================
Next F2F
--------
- Pending room availability, Houdini will meet on 10 Jan in
Seattle.
AnimationWorklet
----------------
- rbyers walked the group through the updates made to the spec
which include addressing the worklet and address
synchronization concerns.
- There were concerns that this was exposing the ability for
webdevs to make bad choices. However, it was felt that this
was no worse than what existed currently.
- RESOLVED: AnimationWorklet moves to WICG
Serialization of TypedOM
------------------------
- RESOLVED: Turning a basic property into a shorthand or into a
list-valued property should work correctly and not
break things.
Properties and Values
---------------------
- RESOLVED: Replace deregistration with a note that we're likely
to add it later.
- RESOLVED: For the grammar accepted by syntax, accept option 3
(Just take the literal string. register("--foo-*",
...) succeeds, has to be written as "--foo-\*: ...;")
- There was interest in writing spec text to provide a generalized
resource mechanism by making a dictionary, though this quite
possibly will end up in level 2.
- RESOLVED: Use CSS grammar definition syntax for defining grammar
of custom properties.
====== FULL MINUTES BELOW =======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-September-2016
Scribe: jet
Next F2F
========
Rossen: Seattle Jan 11-13 for CSS
Rossen: MSFT hosting.
Rossen: Do we want 1 day of Houdini? When?
Rossen: I suggest Tues 1/10
Rossen: We'll arrange for 1/10 pending room availability
Rossen: in Seattle.
dbaron: Following meeting dates?
dbaron: April is tougher to schedule (easter & AC meeting)
Rossen: June or July in Japan also possible per Hiroshi
shane: let's defer summer scheduling until January?
AnimationWorklet
================
<nainar> https://github.com/majido/animation-worklet-proposal/blob/gh-pages/README.md
rbyers: We can scope down to bare minimum now
rbyers: but that we can get consensus on in ~6 months or so.
rbyers: Addresses synchronization concerns (eg. scrolling use
cases)
rbyers: ...but more synchronization can be a future level.
rbyers: Addresses Apple feedback via a worklet design.
dino: How does this cover parallax, spring, etc.
TabAtkins: Houdini version of Scrolling Animations spec.
rbyers: [goes over the Explainer]
rbyers: [shows demo of custom timing function for a fade-in
animation]
rbyers: We already throttle rAF based on visibility.
iank: Animation functions return TypedOM objects.
dino: When do animations fire?
esprehn: They start when the animator property is set.
esprehn: We resolve then apply keyframes when animator prop is set.
bz: It only returns a current keyframe?
esprehn: Yes, the JS returns one per callback.
dino: getComputedStyle() returns ___? run the animation loop first?
shane: You get a null start time if you query an animation before
a compositor round-trip
shane: ...that computes the actual start time.
dino: Explain root & children?
rbyers: [demo: parallax scroll]
rbyers: In this case, root is the document element
rbyers: and the children are the items animating.
bz: Is animator-root a comma-separated list?
rbyers: Yes.
rbyers: [demo: position-sticky]
rbyers: Chromium position-sticky implementation won't be built on
Houdini
esprehn: but authors can use AnimationWorklets for such use cases.
dino: Element transforms are clobbered by AnimationWorklet
mutations?
rbyers: Yes, just as with other animation libraries today.
rbyers: [demo: synced scroller]
rbyers: [shows how animator is slaved to another one]
rbyers: [shows running demos]
bz: Why is it hanging off window?
iank: That will change.
rbyers: [shows spring demo]
rbyers: That's it for demos.
rbyers: Open issues can be seen in GitHub.
rbyers: Spec will change to apply to all properties (not just
currently animatable ones).
rbyers: We want webdevs to be able to reason about performance,
eg., via console/devtools.
rbyers: We expect to be able to animate off-main-thread (ie, no
relayout-causing).
esprehn: Seems reasonable to animate on main thread when needed.
rbyers: Yes, but we should warn authors.
dino: webdevs might make choices that suck on platforms that they
don't test on.
dino: eg., watch performance?
rbyers: API specify root & all children, but not for different
children.
rbyers: Do we need that?
esprehn: will-change is now implicitly set for all animations.
dino: All the popular animatable properties create stacking
contexts already anyway.
rbyers: Are we past skepticism re: JS on the scrolling thread?
Current design moves to a separate thread, not the
scrolling thread.
dino: Safari on iOS scrolls on a UI process.
rbyers: Edge, Chrome going that way too.
dino: I think my concerns were re: declarative vs. imperative
model for these effects.
rbyers: We should do both.
dino: Fear of webdevs not using these tools correctly
dino: are we providing tools that are easily misused?
dino: With a declarative system, we can change implementations
under the covers
dino: but when we expose internals (eg, compositing thread) we get
constrained to that model in the future.
Rossen: And further, our architectures are a lot more different
than say, the Style system
Rossen: and we all do crazy stuff to get performance.
Rossen: Edge is moving scrolling lower-level in the OS (not a
separate process)
Rossen: and exposing these primitives limits our ability to do
that.
rbyers: For user-driven scrolls, you already have to synch every
frame?
dino: Not Safari nor Edge.
ojan: Compare a position:sticky polyfill today
ojan: that slow down scrolling
ojan: nothing in this proposal makes that worse.
rbyers: Now in a worklet, no synch guarantees, but higher chance
of keeping synch because of separate worklet thread.
RESOLVED: AnimationWorklet moves to WICG
<break length=20>
Serialization of TypedOM
========================
shane: Firefox canonicalizes values for unconnected nodes
dbaron: We always resolve ems but there are differences for
computed style when unconnected.
bz: Or display:none.
dbaron: But that's mostly just our getComputedStyle serialization.
esprehn: Would be a different serialization (like getComputedStyle
but without resolving things that require unavailable
knowledge, e.g., rem for unconnected font elements)
shane: 1st phase: canonicalization 2nd phase: resolve relative
units (eg, ems)
dbaron: How is canonicalization different from OM getters now?
shane: Today, either you never do canonicalization, or you do both
phases.
TabAtkins: Write out Value types for all of CSS over the next 2
weeks
TabAtkins: or just define the representation of everything.
shane: How about we do that now and come back later?
dbaron: OK...I just don't want us to invent new things unless
there's a good reason for them.
TabAtkins: Where there's no existing serialization, we'll define a
CSSOM serialization
TabAtkins: and TypedOM later on will use that.
gregwhitworth: Will this quantify serialization for specified
values?
shane: Yes.
TabAtkins: We'll try to match getComputedStyle when we can.
plinss: Don't carry over bad decisions.
dbaron: Problem with old CSSOM is that it was poorly specified,
and thus became UA-specific.
dbaron: Shorthands does not occur in TypedOM spec.
TabAtkins: Exist in Style values now.
shane: Shorthands will be a CSS Style value.
shane: We'll start with all longhands first.
dbaron: btw, background-position is a shorthand
Scribe: fantasai
TabAtkins: Have to make sure turning a property into a shorthand
doesn't mess everything up.
?: What does StyleValue.parse("backgroundposition", "center
center") return?
[answer missed]
TabAtkins: Need to make sure upgrade to a list value works smoothly
shane: Need to prepare 400 serialization things, then we can
discuss stuff.
RESOLVED: Turning a basic property into a shorthand or into a
list-valued property should work correctly and not break
things.
Properties and Values
=====================
Should property deregistration be possible?
-------------------------------------------
shane: Want to move on to properties and values issues.
shane: Last issue on agenda topics list is, should property
deregistration be possible?
shane: Currently can register and deregister type ? property.
shane: But people point out custom elements, the houdini of HTML
world, ...
[missed]
shane: Problems with deregistering type of custom properties.
shane: Requires an expensive flush.
shane: Or have to carry around a lot of extra values.
shane: Certain attraction to just not allowing property types to
be deregistered.
bkardell: What's the use case for deregistering?
shane: Don't think there was ever a use case.
TabAtkins: Because we wanted to have a declarative version of
property type registration at some point.
TabAtkins: When that happen, style sheets can go away and change.
TabAtkins: Mess around with typed OM.
TabAtkins: Didn't want anything to be time/order dependent.
esprehn: Requires reprocessing the entire sheet.
<dbaron> http://dev.w3.org/houdini/css-properties-values-api/
TabAtkins: Adding or removing a custom property requires reparsing
the whole sheet.
Rossen: What is problem of deregistering?
Rossen: Is there an actual technical reason to disallow it?
Rossen: I heard something along the lines of hard and
performance-taxing.
TabAtkins: Requires the same full-world reparse that adding does.
ojan: My feeling is the declarative thing you described, we can
add deregistering when we add that. Don't have to do it now.
shane: Can we resolve on that?
plinss: As long as we make sure we don't build on the assumption
it's not there.
shane: So maybe add a note that it will be added later.
RESOLVED: Replace deregistration with a note that we're likely to
add it later.
Need to define the exact grammar accepted by "syntax"
-----------------------------------------------------
<shane> (this is https://github.com/w3c/css-houdini-drafts/issues/112)
TabAtkins: Simon brought this up before ... algos here, e.g.
register property,
TabAtkins: Have to take a property name and parse it.
TabAtkins: Easiest way is to parse as an ident. Allows us to throw
if it's messed up.
TabAtkins: Do we have full CSS parsing? E.g. handle escapes,
comments.
TabAtkins: Or do we just do simplistic check for ident characters?
TabAtkins: Simpler concept.
TabAtkins: Useful possibly for other places in the platform where
we want to invoke CSS parsing, but don't want to invoke
comment processing etc.
plinss: My one concern is that you can use CSS escapes to put in
characters into the ident that otherwise wouldn't parse.
TabAtkins: We could take up a straight up string, use that
directly with no other parsing. Then have to manually
implement "is this an ident" check, e.g. no spaces.
dbaron: You can put escaped spaces into an ident.
TabAtkins: It's extremely weird, can't literally type it.
plinss: In general I think escaping should be kept where it's
meant to be used, e.g. no CSS escapes in JS.
plinss: Use a JS escape in JS.
plinss: In favor of not doing any CSS parsing here.
TabAtkins: querySelectorAll uses CSS escapes.
bz: That's a much more complicated syntax, makes sense to reuse
CSS parser.
...
bz: In this case plinss was saying just use any valid string as
the ident.
SimonSapin: In the APi it's just a property name.
SimonSapin: But in syntax definition of a custom property, using
syntax of custom ident with escaping and all that.
TabAtkins: Oh hey
TabAtkins: Example {syntax: "red | blue ";}
TabAtkins: What if I want "red | blue | 3d"?
TabAtkins: Understand that as an Ident that I want to do.
SimonSapin: Except it's JS so you'd have to do \\33 d.
plinss: That's why you don't want to mix escaping.
TabAtkins: This is invalid, not what I just said, cuz doesn't
match <custom-ident>.
TabAtkins: Even though technically possible to have a keyword "3d"
in CSS if you escape the three w eg --foo: \33 d;
TabAtkins: You can of course just take a <custom-ident>
{syntax: "red | blue | <custom-ident>" }
TabAtkins: But then you're being really weird.
TabAtkins: So I will change register property to not do anything
weird, just check it.
TabAtkins: Right now checking if ident and throwing syntax error,
then checking if already registered.
TabAtkins: Can get rid of first check.
TabAtkins: Oh, I remember why has to be an ident.
TabAtkins: registerProperty("--foo", ...)
TabAtkins: Need to check that the first one is a valid ident, so
that when you write your stylesheet you're writing
something useful
TabAtkins: Suppose I put registerProperty("3d", ...);
TabAtkins: Then .foo { \33 d: ...; } ...
shane: That would parse as invalid in CSS.
...
bz: So real question is "-- d"
bz: You can express that as --\ d: ...;
plinss: I think it's ugly, don't really see why anyone would want
to do that, but don't see why it's bad.
plinss: You didn't write CSS escape in JS string, because you're
not writing CSS, writing JS.
<SimonSapin> plinss +1
TabAtkins: Rules for CSS idents are somewhat arcane. e.g.
"--foo-*" be confused why it doesn't work
fantasai: I don't think authors will be confused. Most people know
a CSS ident is alphanumerics plus hyphens. Not gonna try
that, or if see that expect the star to be some kind of
magic syntax... if don't know about said magic syntax
wouldn't try to use it.
...
plinss: Need to escape that in the registered property. "--foo-\\*"
fremy: In CSS can escape any character, e.g. \o
plinss: My concern isn't people doing this, my concern is the
tools.
TabAtkins: If we throw on this thing, obvious right away.
plinss: Dunno what custom CSS preprocessors are doing right now.
plinss: ....
TabAtkins: Won't work with registerProperty.
shane: Three options, can we put it for a vote?
<TabAtkins> 1. Manually check for name chars, then check it's an
ident. (register("--foo-*", ...) will throw)
<TabAtkins> 2. Just parse as custom-ident. register("--foo-\\*",
...) succeeds, has be written as "--foo-\*: ...;"
<TabAtkins> 3. Just take the literal string. register("--foo-*",
...) succeeds, has to be written as "--foo-\*: ...;"
<dbaron> 4. instead of escaping the characters, escape from the
meeting :-)
shane: Currently CSS allows an ident to include *any* character in
Unicode, if you use escapes for certain ones. If you do
some half-parse-check thing, then you're introducing a
limitation through registerProperty that isn't in CSS.
TabAtkins: ident check would be reasonable-ASCII or above-ASCII
fremy: What do we do if you use getPropertyValue.
SimonSapin: Pretty sure getPropertyValue doesn't do any escaping.
Just compares strings.
plinss: Problem with #1 is that --foo-* is a perfectly valid CSS
property name. Can just use it by escaping * . Now you
prevent me from using it.
TabAtkins: getPropertyValue + this plus other thing are new enough
we can change it later if problematic.
[Votes:
<TabAtkins> 1
<dino> 1
<plinss> 3
<shane> 1, then 4
<fantasai> 3
<SimonSapin> 3
<dbaron> 3, then 1
<nainar> 1
<frremy> 3
<surma> 1
<gregwhitworth> 1
<iank> 4
<JakeA> 3
]
shane: No consensus!
shane: Any objections to doing whatever getPropertyValue does
right now so we don't have to change it?
SimonSapin: It does 3
RESOLVED: 3 (Just take the literal string. register("--foo-*",
...) succeeds, has to be written as "--foo-\*: ...;")
Provide generalized resource mechanism
--------------------------------------
<shane> https://github.com/w3c/css-houdini-drafts/issues/215
shane: Make a dictionary, use it later.
shane: @font-face does this.
shane: @keyframes does this.
shane: Seems like a useful way of providing bundles of info to
subsystems in CSS.
shane: Do we want to ? in custom paint sometime?
dbaron: Fun issues like scoped style sheets.
gregwhitworth: Does this feel like a requirement for v1?
shane: Would want to push to v2, but wanted to get other opinions.
gregwhitworth: Personally think everything else is really solid,
so bringing up something brand new with issues
dbaron mentioned, better push to v2.
eae: Use cases?
shane: Really nice things, you can specify paint resources in
custom paint, can ??? rather than having to pass image into
every single thing.
shane: But don't have to have for v1.
shane: Sounds like interest to put into spec prose?
[general nodding]
How to express syntax of a custom property
------------------------------------------
shane: Pretty much all I have.
shane: Saved easiest question for last
shane: Grammar issue
TabAtkins: How to express syntax of a custom property.
TabAtkins: Forcing authors to write CSS grammar in a string would
be confusing.
TabAtkins: Instead proposed using the constructors directly.
TabAtkins: E.g. if only take lengths, instead of taking string
that says <length>, would take CSSLengthValue (
represent a length).
TabAtkins: If take multiple lengths, take an array
TabAtkins: This doesn't work.
TabAtkins: We allow other types of combinations other than
alternations
TabAtkins: e.g. repetition.
TabAtkins: We'd have to invent new syntax for that.
TabAtkins: Also as we expand, we'll want to allow || and &&.
TabAtkins: Want to allow full range of CSS grammar to be used.
TabAtkins: Trying to base that on constructors becomes crazy.
TabAtkins: Seems better to use a grammar syntax designed to do
that.
TabAtkins: We have one already: the CSS Grammar Definition Syntax.
TabAtkins: So we shoudl use this.
dbaron: Are you starting with a subset?
TabAtkins: Yes, strictly.
TabAtkins: Single values, single bar, and the plus combinator. No
brackets either.
TabAtkins: But want to expand on that in the future.
fantasai: I'm strongly in favor of this. Authors who are working
with CSS will be most familiar with this, and it has the
full expressivity that we will want.
leaverou: Totally agree.
shane: Also lots of resources, easy to look up what it means, or
to be "I want to be like this property" and just copy the
grammar from that property.
...
bkardell: By using the grammar, you create a giant crib sheet,
people can go "I want to be like box-shadow, let me look
up that and copy it"
bkardell: Can you ask the constructors for the grammar?
TabAtkins: Right now in CSS, if you want another property like box
shadow, you use <'box-shadow'>
TabAtkins: If a dev does that, and then we change box-shadow in
the future, their code then breaks.
TabAtkins: If you have a CSS box-shadow constructor and ask it for
that, same problem.
<fantasai> +1
TabAtkins: Fine to copy from spec, cuz that's static.
<leaverou> +1
shane: At risk of calling down ire of Tantek...
[tantek joins IRC as if summoned]
RESOLVED: Use CSS grammar definition syntax for defining grammar
of custom properties.
shane: Break, then parser API. Official Houdini meeting is over.
TabAtkins: Parser thing gonna give intro to WICG.
<TabAtkins> SimonSapin: Parser API sketch
https://wicg.github.io/CSS-Parser-API/
Received on Monday, 10 October 2016 00:40:24 UTC