- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Jul 2018 18:06:55 -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.
=================================================
Properties and Values
---------------------
- RESOLVED: Add custom property observers to L1 of Properties and
Values. (Issue #555)
- The PR in issue #767 (Multiple base URLs) should be merged in and
a WPT added if there isn't already one.
- RESOLVED: Add # to Properties and Values grammar syntax with the
same definition and abilities as +. (Issue #768)
Layout API
----------
- RESOLVED: No change in behavior [around constructors for layout
fragments], add a note as to why constructors are not
exposed. (Issue #760)
- RESOLVED: Add a new LayoutFragmentResult object with a
constructor. (Issue #760)
- RESOLVED: Keep the layoutNextFragment name. (Issue #760)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-July-2018#proposed-topics
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins-Bittner, Google
L. David Baron, Mozilla
Brian Birtles, Mozilla
Tantek Çelik, Mozilla
Emil A Eklund, Google
Elika Etemad, Invited Expert
Koji Ishii, Google
Dean Jackson, Apple
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, Invited Expert, TAG
Myles C. Maxfield, Apple
Cameron McCormack, Mozilla
Xidorn Quan, Mozilla
Francois Remy, Microsoft
Alan Stearns, Adobe
Shane Stephens, Google
Lea Verou, Invited Expert
Philip Walton, Google
Eric Willigers, Google
Scribe: heycam
===== FULL MINUTES BELOW ======
Properties and Values
=====================
Editors
-------
TabAtkins: One thing is editorship, since Shane is leaving
Rossen: Who are the current editors?
Rossen: We currently have Tab Atkins, Daniel Glazman, Alan Stearns,
and Greg W.
astearns: This surprises me.
Rossen: There are currently two issues in this spec
TabAtkins: There are a few in GitHub.
shane: 16 open, a few need edits.
TabAtkins: We can run over them.
Observer for property being applied?
------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/555
TabAtkins: This has been something we're aiming for at some point
TabAtkins: You want to be able to observe when and where a given
custom property is put on an element
TabAtkins: Right now the best you can do is you can do some
processing on a custom prop, tell what grammar it's meant
to have
TabAtkins: You can't say that for every element with this property,
do this JS
TabAtkins: Only way right now is to walk the tree and ask the style
for every element, not great to do in a tight loop
TabAtkins: We already have things like this
TabAtkins: xidorn pointed out you can use the transition events to
get at this
TabAtkins: but that's hacky, clearly
TabAtkins: we're planning on this for level 2
TabAtkins: At minimum, to observe specified values
TabAtkins: and older proposal shunted out is for computed value
hooks, don't know if we want to do that immediately
TabAtkins: We have to define in more detail how that interacts with
animations and transitions, which is complicated
TabAtkins: so at least getting the specified value out of things is
probably worthwhile
TabAtkins: So we could put it in this level, or wait to the next
level
iank: This would only be useful for non-inherited properties
iank: otherwise you are going to walk the whole tree anyway, because
everything is ...
TabAtkins: You would only do it for everything that doesn't have the
initial value.
shane: Unless, like observers, they're applied per element
shane: in which case the inheritance doesn't matter
iank: I think the use case is that you want to do some
computation ...
TabAtkins: Here's an example from a script that does this
TabAtkins: A bunch of things they need extra JS for
<TabAtkins> http://endtwist.github.io/kerning.js/
TabAtkins: So I think it will be find on specified values for now
iank: We're getting someone ramped up to finish the P&V
implementation
iank: had it landed behind a flag for 18 months now
iank: getting it finished off next quarter
iank: Given the number of cool demos, shipping it before Christmas
Rossen: End of 2018
iank: Probably earlier
Rossen: The reason I'm asking, is the current proposed feature for
Level 1, that's fine, it's still a WD
Rossen: so I'm curious whether you're pressing to start shipping, we
might need to start stabilizing this spec
Rossen: With that said, I think it's still worthwhile to take this
in L1 and see if we can make progress
TabAtkins: Anyone else have implementation?
heycam: We have half an impl, might pick up again in Q4 but probably
not ready to ship in Q4
TabAtkins: I'm going to fill in the parser section on how to parse a
grammar string
TabAtkins: obvious but handwavy
TabAtkins: I have a lot of edits to apply to the spec
Rossen: For this particular issue, we are resolving to have the
observer for custom properties in L1, see how it goes
Rossen: Concerns or objections?
fantasai: I would say mark it as risk, I know we're not in CR now
Rossen: We can do it once we get closer to CR
dbaron: One other comment is, I think this is at a stage where it's
ok to be adding new features, as long as they're reasonably
solidly specified off the bat
dbaron: So I think it's ok to add this if the text gets written
relatively soonish and gets reviewed relatively soonish
<fantasai> +1 to dbaron
TabAtkins: I can promise to have the text written, and do as many
other edits as I can, by the end of this month
fantasai: Stabilizing for CR takes time, we don't want freshly added
text that is shaky
dino: The way this spec is now, it allows you to specify a way to
interpolate custom props
iank: You can define it to be non inherited
iank: and also give it an initial value
TabAtkins: And a level of grammar checking
dino: Parse errors
TabAtkins: Yes
iank: A lot of demos at the moment are using it for animation, Ana
Tudor has a bunch
<iank> Ana Tudor demo: https://codepen.io/thebabydino/pen/MrZvNm
(chrome canary + flag)
iank: that's probably the biggest value as a standalone spec
TabAtkins: This feature will be a huge uptick in use cases, when you
can tell what elements have that property applied
TabAtkins: So you think it should go in L1 to increase the value of
the spec
dino: I'm not necessarily saying that
dino: but I'm fine with it
philipwalton: Do we have any other observers?
philipwalton: Are we thinking too small just looking at custom
properties?
TabAtkins: Possibly
TabAtkins: The API shape that's in my head right now can definitely
work with any property, just a string name
TabAtkins: Only defined it for custom properties at the moment, but
no objection to widening it if there's reasonable use
cases and no major implementation issues
TabAtkins: I know we handle custom props a bit differently from
regular props
TabAtkins: If you have use cases, please put it into the issue
philipwalton: I think a lot of these use cases would be handled by
calc() on the property
dino: Might be nice to put more examples in, beyond animations
dino: parse errors, non-inheriting, ...
TabAtkins: Definitely.
iank: [demos Ana Tudor's demo: https://codepen.io/thebabydino/pen/MrZvNm ]
dino: So she's registering custom props for height, shadow,
width, ...
iank: Specifying things as angles, numbers
iank: and then she's plumbing them into a huge transform effectively
iank: So you can see scale effects, ...
iank: all driven by one big transform, but animating different parts
of the animation separately
iank: and then setting a bunch of animations on it
TabAtkins: It's being driven by one big transform prop, but
independent animations on bits of it
TabAtkins: This is a one element demo
ericwilligers: This is one of the motivations for the separate
translate/scale/... props
frremy: She also has a demo animating gradients
TabAtkins: Several examples of gradient animation
RESOLVED: Add custom property observers to L1 of Properties and
Values
Multiple base URLs
------------------
github: https://github.com/w3c/css-houdini-drafts/issues/767
TabAtkins: There was a question of how should URLs resolve in a
typed custom prop
TabAtkins: If you give it an image type, how should you absolutize it
TabAtkins: The resolution was to resolve like it would a real
property, relative to the file it's in
heycam: So where it was declared
TabAtkins: Yes
TabAtkins: As opposed to an untyped property, in which case the URL
gets resolved in the property declaration where it gets
substituted in
TabAtkins: Now on to issue 767
TabAtkins: Here we have two separate custom props, in two different
style sheets
TabAtkins: declaring relative URLs. And in a third style sheet,
using the two together in a background-image
TabAtkins: The question is, how will these resolve according to
where the custom prop was declared?
TabAtkins: The answer is yes
astearns: There's a PR in the issue
iank: This is Anders in Oslo, working on Blink
fantasai: Seems reasonable to me
dbaron: Even better would be a WPT
iank: Anders will definitely add one
TabAtkins: No resolution needed then
astearns: Should Anders be an editor?
TabAtkins: He's not in the WG yet
eae: Probably not yet
Allow comma-separated lists in registered properties
----------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/768
TabAtkins: The request is from Sam Richard, pointing out a lot of
properties are comma separated lists
TabAtkins: Right now the grammar for custom props allows just values
separated by spaces, no repetition
TabAtkins: I think it's reasonable to allow top level comma
repetition
TabAtkins: Would be happy to put this into the syntax spec
fantasai: Do we have the ability to repeat without commas?
TabAtkins: No
TabAtkins: Not currently
fantasai: Then I think those two should be added together, so people
aren't forced to add commas just because they want
repetition even when it would be inappropriate to use
commas
TabAtkins: That's probably reasonable
TabAtkins: The grammar work to allow commas like a CSS grammar is
similar to the work for space repetition
TabAtkins: Will have to add a way to make that unambiguous, require
the repeating part at the end or something
birtles: We also need to specify how to animate the lists, if
they're mismatched lengths
<dbaron> (animation types are in
https://drafts.csswg.org/css-transitions/#interpolated-types )
fantasai: Currently do you have multi valued properties at all?
TabAtkins: Yes
TabAtkins: Right now, you can do space separated repetition, but
only of the entire thing
fantasai: So you would add comma repetition of the entire thing
TabAtkins: We don't have brackets yet
fantasai: You just need a hash
TabAtkins: That would only allow <length>#, not [<length> |
<percentage>]#
TabAtkins: Can only repeat a single term
fantasai: That's a limitation currently for space separated values
TabAtkins: Yes
TabAtkins: At minimum, just adding that would work out ok though
TabAtkins: The big issue is to define what the default list
animation behavior is, and possibly allow a way to change
which behavior you want there
fantasai: Don't you have that question for <length>+ as well?
TabAtkins: I'm not sure how that one animates
TabAtkins: I think they just have to match in length right now
dbaron: So that's the "simple list" definition in Transitions
dbaron: The least common denominator thing is a generic thing that
repeats the list
dbaron: There are other things like for shadows with values used to
fill missing spots
dbaron: filters should have something similar
TabAtkins: I think it does
frremy: I think we should try to find an easy way to handle
animations now in L1, then look at more complicated
animations in L2
frremy: I feel like we should have an easy answer in L1, try to find
use cases for more something complex
TabAtkins: So we can use simple list behavior now, then figure out
what we need for later
TabAtkins: Objections to adding the # multiplier to L1 grammar?
dbaron: Adding both the # and +?
TabAtkins: + is already in the grammar
Rossen: Any objections?
fantasai: So add # with the same definition and abilities as +
RESOLVED: Add # to Properties and Values grammar syntax with the same
definition and abilities as +
Properties and values API generally, again
------------------------------------------
dino: Google has implemented it behind a flag, hopefully by the end
of the year
dino: Mozilla has a vague implementation
heycam: Two vague implementations
dino: So maybe for Q4 you'll have three vague implementations
dino: ;)
iank: For our implementation, most of the work was teaching the
animation subsystem how to animate these things.
Layout API
==========
TAG feedback
------------
github: https://github.com/w3c/css-houdini-drafts/issues/760
iank: This is a bunch of assorted TAG feedback
iank: A lot of editorial stuff, but 3 or 4 issues we can talk about
iank: The first one is having a constructor for layout fragments
iank: In summary, currently today the only thing that can produce a
layout fragment is the rendering engine
iank: Call on the child, say lay out this fragment, it does some
work, and gives back a fragment
iank: The useful information is the width and height of the
fragment, and you can return it in your list of children
iank: Do we want a constructor for this?
iank: We can add this, I'm not objecting, but the constraint is that
this isn't a valid fragment you could return to the engine
iank: Just a placeholder for testing
Rossen: The current design has a fairly rigid assumption of who can
produce fragments
Rossen: and be responsible for their lifetime
Rossen: and it's not the script, it's the layout engine
Rossen: Exposing a constructor, you are fooling the user that they
have control over it
Rossen: so I would push back on this issue with that reasoning
eae: Unless it's a valid fragment, it would be more confusing than
it's worth
Rossen: Again, it would lead down the path of considering those as
user space objects when they're actually browser objects
dbaron: What would it mean to have a real constructor for a fragment?
iank: What Travis brings up here is events in the platform
iank: Synthesizing an event through the system
iank: This is quite often used for testing
iank: It's not a real event
iank: They're already second class citizens
iank: For us, I'm struggling to come up with use cases for
synthesizing events like that
Rossen: Again, the fragment projection we give back to the user is
just an interface with a bunch of functionality to
interrogate properties
Rossen: It's meant to be a black box that you can move around and
that's it
iank: The things you can read from it are the width, height,
baseline info in the future, and basically just position it
iank: If the child is also a custom layout it can pass information
up via structured cloning
iank: but that's basically it
iank: dbaron or plinss anything to add?
plinss: That's reasonable
Rossen: Probably something that they didn't grok entirely, and they
look similar on the surface but they're not
plinss: In general the TAG likes to see constructors on everything
plinss: but I agree here
astearns: Would it make sense to add a note saying usually we have
constructors but not here?
Rossen: If it's lacking explanation let's add that
RESOLVED: No change in behavior, add a note as to why constructors
are not exposed
iank: The second point, is that we return an options bag from layout
iank: which does some magic
iank: Explicitly you return the child fragments, auto block size,
some other info
iank: The engine goes and synthesizes a fragment for you with
correct internal representation
iank: Should that operation have a constructor, so you can create a
new layout result fragment
iank: and check if that operation fails
iank: There are some cases where that operation could fail
iank: For example, you pass it auto block size, create a new result
fragment, at the moment it's just an options bag
iank: and then inspect what your output box size is going to be,
maybe do something different based on that
iank: The other thing that can fail is when you deserialize the
extra data you can pass up the tree
iank: When you try to structured clone that, like adding a
SharedArrayBuffer or something
iank: currently we just say it threw an exception
iank: With a constructor the user could detect that it threw an
exception
iank: I think it's reasonable, but would need to work out what the
constructor's option bag argument would be
iank: It's not entirely clear to me yet
frremy: When I tried it, something I found frustrating is you can
have a big option you want to give, only a few props on the
object can't be serialized
frremy: then you have to clone the entire object yourself, by
removing the stuff you can't serialize
frremy: Maybe would be nicer to set null for props you can't
serialize for example
iank: I think that's a bigger ask
iank: Structured clone is painful for people to use
iank: Would that have been useful? there's a bit out of your control
iank: Would it be useful to ensure that operation doesn't fail?
frremy: Something like JSON.stringify, with a callback to handle the
unserializable stuff
iank: That would be a slightly larger change in the HTML spec
frremy: I don't think having a constructor would change anything
frremy: Only solution is to clone
iank: Would it have been useful to just get say the auto block size?
frremy: Not sure
iank: I think that's a reasonable ask, shouldn't be too much work,
not sure many people would use it
iank: Can always add it and use count it, remove if it's unused
iank: We need to add a constructor, not just returning a
FragmentResultOptions, but a constructor for a type like
FragmentResult
iank: then run all the steps for user and layout, structure clone,
sanitize the output
iank: By running the constructor you could catch an error that would
happen during that process
Rossen: As to the larger question, about expectations of what
happens if the script starts throwing?
iank: I think we just fall back
iank: I think that larger question is just a misunderstanding,
editorial
Rossen: Objections to adding the new LayoutFragmentResult object?
RESOLVED: Add a new LayoutFragmentResult object with a constructor.
iank: Final piece of discuss-able feedback here
iank: Confusion about layoutNextFragment name
iank: Do we want to go back to layout?
Rossen: No
Rossen: That's like call everything object
iank: David or Peter?
dbaron: I already disagreed with Travis on that one
frremy: I like that "next fragment" knowing that you're getting a
fragment
frremy: "layout" is too general
iank: Rossen and David want layout
plinss: I tend to prefer verbosity
iank: Ian and Francois don't care
Rossen: Other opinions or objections?
RESOLVED: Keep the layoutNextFragment name.
Received on Wednesday, 18 July 2018 22:07:55 UTC