- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Jul 2018 18:07:03 -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.
=================================================
Layout API
----------
- RESOLVED: Abspos parented to custom layout elements have static
pos computed similar to flex and grid children (static
pos rect coincides with parent rect) (Issue #775)
- RESOLVED: The rules for abspos containing blocks is not changed
with the presence of custom layout. (Issue #775)
- RESOLVED: Custom layout must return all fragments, otherwise
return an error and fall back to block layout. (Issue
#775)
- RESOLVED: Use Promises and add a note about error handling (Issue
#750)
- RESOLVED: No change on Issue #437 (percentageInlineSize /
percentageBlockSize)
- RESOLVED: Intrinsic size in orthogonal flows are taken according
to the writing mode of the containing block, and
intrinsic size calculations have to be consistent with
all other places in CSS (per CSS Sizing). (Issue #776)
Typed OM
--------
- RESOLVED: Add frremy as co-editor on css-typed-om, move nainar to
former editor
Custom Paint
------------
- RESOLVED: Deferred to L2 (Issue #763: optional arguments in paint
functions)
- RESOLVED: Custom Paint to CR
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-July-2018#proposed-topics
Scribe: heycam
===== FULL MINUTES BELOW ======
Layout API
==========
Missing fragments and absolute children
---------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/775
<div style="display: layout(foo);">
<div id=child1></div>
<div id=child2>
<div id=abspos></div>
</div>
</div>
iank: In the Layout API, it's possible to have multiple children
iank: In the example in the issue, the second child has an abspos
child in it
iank: Its containing block is higher up in the tree
iank: Inside of layout, we only lay out the first child, and return
it
iank: What should the behaviour of the abspos be?
Rossen: Is there an expectation for anything to happen to the child
box?
iank: In the current API, you can just leave out children
iank: and they don't lay out
eae: Effectively it's display:none
eae: so wouldn't it make sense for their children not to show up?
Rossen: There are two things
Rossen: either the abspos child will be lifted outside the scope of
the display:layout function grandparent, or not
Rossen: If it's lifted outside of it, I'm assuming layout will
happen in the normal way
iank: Your assumption is that it will display the abspos child
somewhere else
Rossen: If it's position is outside the scope of the display:layout
Rossen: Would all abspos elements reach their containing block,
during custom layout?
Rossen: You can have a bunch of inner levels of custom and normal
layout
Rossen: Will there be a discontinuity in that process?
Rossen: My assertion is that it shouldn't
Rossen: One potential problem is that if you rely on something as
part of the custom layout, in that interleaving, and that's
not calculated, you might get wonky results
Rossen: e.g. if you don't lay out child 2, and the abspos position
depends on child 2's position, you'll have to synthesize
something for the static pos
Rossen: but that's about it, or you might have something that is
switching writing modes or whatnot
Rossen: but again my assertion here is that this shouldn't have an
effect apart from residual things like static pos
iank: I'm fine with that
iank: What should happen with the static pos?
Rossen: (a) we don't want to have a loss of content, regardless of
what happens to the custom layout parent
Rossen: i.e. the abspos box should not just disappear, unless you
explicitly say so
dbaron: So you're saying it should have its normal abspos
containing block, and the custom layout is never an abspos
containing block.
Rossen: No
Rossen: My assertion is the box with abspos element will always
generate a box, and it will be parented to the appropriate
containing block, which may or may not be custom layout
Rossen: Distinction is propagating through custom layout layers,
second is ending up at a non-custom layout containing block
Rossen: So besides calculating some invalid or default static pos
iank: Something along the lines of pretend that it did generate a
(0, 0, 0, 0) fragment
fantasai: For custom layout, unless we want to let it control the
static pos, we could certainly just use the rules in
flexbox
fantasai: which is you pretend that the static pos rectangle is the
whole flex container (the abspos’s parent)
Rossen: What happens if a flex item is the whole area
fantasai: If display:layout and child2 are both doing custom layout
Rossen: The outer one is the containing block
fantasai: The parent gets used as the static pos rect
...: if you didn't lay it out
Rossen: Then its parent
fantasai: But that box still needs a position
fantasai: Why isn't there a box?
dino: On child2 if you put display:none, what happens to abspos?
Rossen: Same as always, it wouldn't display
dino: Why is different from not laying it out?
Rossen: We shouldn't introduce things that are like display:none
just because didn't lay out a box
fantasai: It should just be (0, 0, 0, 0)
dino: Sure
fantasai: The box should still exist, and you just happen to not
position it
Rossen: Just becomes a position and an empty rect
dino: If it had a position, you'd use that
Rossen: Which is what I would expect
iank: Yes
Rossen: If my containing block is some span e.g., didn't have
anything else than the abspos, it still has a position
calculated for it
eae: Makes a lot of sense
Rossen: The static position of an abspos element, with a custom
layout parent, is based on that parent's fragment's box
fantasai: Similar to how static pos of a box that is parented to a
flex container uses the rectangle of the flex container to
calculate it static pos, rather than any hypothetical
"would have been" layout like block layout
Rossen: The summary here is that the static pos of abspos elements
parented to custom layout is the same as in CSS, based on
the rectangle of that parent
fantasai: Similar to flex/grid, not block
fantasai: In block and layout they use the hypothetical position if
they weren't positioned
fantasai: For flex and grid, we don't try to calculate where it
would have been, instead pretend you would have coincided
with your entire parent
RESOLVED: Abspos parented to custom layout elements have static pos
computed similar to flex and grid children (static pos
rect coincides with parent rect)
Rossen: Next problem, you've computed static pos, that's great. You
end up with a custom element that has position:relative
dbaron: There's an easier piece we should resolve first
fantasai: Proposal is that custom layout does not interrupt
propagation of abspos
dbaron: It doesn't change the rules for when something is an abspos
containing block
Rossen: The abspos is never exposed to the custom layout in any form
iank: Other potential thing is about the behavior of the second
child, in this case
iank: You are thinking that child2 should get laid out with
available size zero, and would still show up?
iank: It's specced as not showing up
iank: That might be something easier to resolve on
RESOLVED: The rules for abspos containing blocks is not changed with
the presence of custom layout.
Rossen: Next is, if the containing block is custom layout
fantasai: If you don't explicitly lay out a child the layout engine
resolves its size and position to zero
frremy: I'm fine with that, but it will not show up
frremy: I think that's ok, but if I don't put return it, I don't
want it in the layout
frremy: Similar to display:contents or something
frremy: If I don't want to include a particular element,
implementing something like -webkit-line-clamp, I don't want
them generating
dbaron: If I were to try to think about how I wanted custom layout
to deal with being an abspos containing block, I feel like I
would want to two different options probably
dbaron: Don't necessarily need both options in v1
dbaron: One of them would be: I want a custom layout, might be an
abspos containing block, I want it to handle things I'm the
abspos containing block for using the default rules
dbaron: I don't want to handle those in my custom layout, just handle
the in-flow contents
dbaron: Other option: I also want to take over layout for the
descendants I'm the abspos containing block for
dbaron: and in that case, in many cases I'd want to get those sets
of children separately
dbaron: i.e. process the in flow ones first, then the abspos ones
iank: I could imagine an API that is two additional callback
functions, one where you're routing children, yes pass this to
parent, no keep this one to myself
iank: and an out of flow layout pass, which gives you the children
you're a containing block for
iank: and go ahead and apply whatever abspos rules you want
frremy: That's useful for the grid polyfill
frremy: If you set grid-column on them you still need to be able to
place them in columns, even if they're abspos
frremy: Doesn't have to be in the layout step, could be a separate
step
Rossen: Only problem I have with this, is if you select which
children you want to handle, that goes against the
resolution we just had before
frremy: What does grid do?
Rossen: The API proposed, here are the children going through, I
want to keep certain ones ... unless we specify we're not
even going to expose abspos to your children
Rossen: because you really don't need to
iank: I think it's a niche use case, a callback for routing
Rossen: But that's a more advanced feature
Rossen: So, current issue is, element with custom layout, it's also
a containing block for abspos, there's a descendant abspos,
and the custom layout does no layout. what happens to the
rest of the children?
Rossen: One of the assertions we should have here is that that
child, at that level, is just a normal first level child, it
has to be laid out
Rossen: It shouldn't be any different from other ones
Rossen: So if I have two children that are inside of this custom
layout, one is an immediate child, one is a descendant,
regardless how deep the descendant is, it's something I need
to handle at the first level
Rossen: If I can decline layout for a first level child, I should be
able to do that for the abspos descendant too
Rossen: Might be different for layout logic, that's your business
Rossen: But the point is that I have a collection of children
fragments that came up to me, if I decide to drop them all,
I can
Rossen: From that point of view I don't think we need anything
specific to abspos, but we still need to be clear as to what
the rules are
iank: Yes, we can discuss that
fantasai: The original issue, we've got an element whose static pos
we need to find, static pos is not the custom layout in
this particular case, because it's a child of a child of
the custom layout
fantasai: Custom layout is responsible for laying out the child,
when it does, that box will determine the static pos of
the grandchild
fantasai: If the custom layout doesn't lay out that child, we still
need to know where the static position is
Rossen: We resolved that
fantasai: We resolved that for a child of the custom layout, this is
for a grandchild of the custom layout
fantasai: It's different because if we don't run layout on the child
of the custom layout, we don't know where it is
fantasai: It's a regular in-flow child of the custom layout, inside
that is the abspos
fantasai: The abspos's position is dependent on the size/pos of
child2
fantasai: We don't have answer for the size/pos of child2
Rossen: My point in the beginning is that the static pos of the
abspos, is the origin
Rossen: This is relative to its parent
Rossen: If the parent doesn't compute to anything, it will be to the
origin of its parent
Rossen: At some point there is some ancestor where that origin is
defined
fantasai: We didn't resolve on that
Rossen: This is how custom layout is defined to work, relative to
parent
fantasai: I know it's relative to parent
dbaron: I think we need a definition of what happens if custom
layout decides not to lay out something
dbaron: In our engine, layout code can't not lay out something
dbaron: I suspect other engines are probably similar
dbaron: If you get laid out at (0, 0, 0, 0), whatever it is, it
should be defined somewhere
dbaron: Once we have that definition, it resolves this.
[-- break 20 mins --]
Scribe: fantasai (with heycam for fantasai)
fantasai: Key question is what dbaron said, what do we do to
fragments which are not laid out?
frremy: A common use case for not laying out a child is when you
want, e.g. lay out items until you run out of space and then
have a continuation marker (like ...)
frremy: you want to just stop laying out at that point
frremy: Should try to address this in custom layout
frremy: makes sense to not generate a box for items that aren't laid
out
frremy: rather than defaulting to (0,0,0,0)
frremy: So prefer to define same as 'display: none' or define
something else similar
frremy: or throw an exception for now and figure it out later
frremy: Don't think it's useful to create a box that's zero-sized,
this isn't useful
frremy: and not generating the box is sometimes useful
Rossen: I think not showing things is useful
myles: max-lines is similar
Rossen: Should be able to not lay out. If we don't lay out anything,
the question is would we absolute generate no fragment/box.
Would we end up with an empty size and origin position?
Rossen: We still have to answer questions like from the OM, what's
the size/position
Rossen: So what would make the most sense?
frremy: Compromise would be to have a box at zero/zero, but it just
doesn't paint
iank: Agree that we should say it doesn't paint.
iank: but what about the rest of the subtree?
iank: Do we return zero for everything all the way down the subtree,
or do we continue with layout?
fantasai: For max-lines specifically, from an implementation
perspective, I think it does make sense to lay everything
out
fantasai: That's a use case where you want to hide and show things
dynamically, not having to re-layout would be useful
fantasai: More generally I'm not sure
fantasai: If you're not going to display the stuff
fantasai: but you could display:none things you don't want to display
Rossen: But this is a layout time decision
eae: For max-lines it would be nice to not reflow things that aren't
going to be displayed, unnecessary work
koji: This could create next fragments, it's more about
fragmentation, when the next fragment container is missing
fantasai: You could make the same argument here
fantasai: We will support fragmentation
iank: It might be reasonable to say layout doesn't happen, and all
CSSOM APIs return zero, getClientRects doesn't anything
iank: Saying all this without impl experience, might change opinion
based on experience
iank: Everything returns zero, empty array for line boxes
dbaron: I think this is a magical semi-displayed case
dbaron: I'd rather have a layout and have the APIs return a
consistent state
iank: We could also define a consistent state
dbaron: Sounds messy
iank: I'm a little bit torn, agree with fremy that use cases for
this are very valuable
Rossen: Another lens to use for reasoning, how would you serialize
your collection of children in the case that frremy gave?
Rossen: e.g. for accessibility purposes
Rossen: Would want accessibility tool to walk the same tree as
what's visible
Rossen: Would you synthesize things in the AT or what?
iank: Not accessible to normal users, so shouldn't be accessible to
AT
iank: The way to make this decision would be, what should happen in
the max-lines case?
iank: Could also punt this for now, get impl experience
iank: Our current behavior is that you need to return all the
fragments. Otherwise we'll fall back to block layout
Rossen: That's nice. Very predictable and verifiable
iank: We should investigate, then reopen this issue.
Rossen: In which case, this is an error
iank: Yep
Rossen: Fix your code. Make it work.
heycam: I think it might be easy to accidentally lose your custom
layout
Rossen: Exactly
heycam: Might be that you change your ordering in certain window
sizes, and then it breaks
fantasai: I think if you can't loop correctly over all the items in
this list ...
Rossen: You shouldn't be doing custom layout.
iank: Grid iterates in a particular order
frremy: But here you need to iterate in the right order
Rossen: Sounds like for this level of where we are, this is a
reasonable error case handling
Rossen: It is simple, it's easy to describe, and should be easy to
fix on the script side
Rossen: With that, plus previous two resolutions, then we have a
clear answer to what happens with abspos children
Rossen: If we need to get more sophisticated later, we can
Rossen: Implementation experience may suggest a better pattern
frremy: Would need to feature detect somehow, whether the browser
supports laying out all the boxes or not
iank: Need to resolve on this, then: if you don't return all the
fragments, we return an error and fall back to block layout
iank: Falling back to block layout is what happens if the layout
function throws an error
iank: You can check by ...
heycam: What about existing content, that falls back to block
currently and throws an error, and then later it starts to
drop content
fantasai: Could fall back to content disappears?
fantasai: But we don't like dropping content
Rossen: We could fall back to 100em bright red...
iank: Two ways to deal with that.
iank: One is to use-count
iank: Other, if that number is sufficiently high, we can add a
layout option
iank: It's a bit heavy handed
iank: but we can use-count it to check
...
philipwalton: Could put a note in the spec explaining what we're
planning to do
Rossen: This is simple, easy to spec, easy to explain, easy to see
if you messed up. Can revisit later. It's a good solution.
RESOLVED: Custom layout must return all fragments, otherwise return
an error and fall back to block layout.
Generator vs. Promise design for the API
----------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/750
iank: Did some benchmarking
iank: The Promise solution is slightly slower, but not that much
slower
iank: That makes me lean towards Promises solution
iank: Advantage of generator is that it's faster, don't have to kick
the ? every time
iank: there's some overhead for doing that
iank: However, I think that's acceptable from an author expectation
perspective
iank: If it was 30-40% overhead, that might be a concern
iank: but turned out to be not as much of a problem
Rossen: What did you test?
iank: Test was 100 custom layout elements
iank: Went about 6 layers deep, and had two child nodes at each
level and 4 leaf nodes
iank: tree structure, roughly 100 nodes
iank: used our perf testing framework
iank: I did a synchronous version of the API, didn't have any
generators, promises, etc. Just executed synchronously
iank: That was about 650 runs per second
iank: Our current impl was about 430 runs per second
iank: so 50% off the synchronous one
iank: Promises was 450 runs per second
iank: Might be able to get it faster, push around 500 or something
iank: We do lose a lot of performance by allowing async here
iank: so something else to consider
iank: One thing we could revisit later is, asynchronous layout
engines
iank: we could potentially get performance by exposing synchronous
versions of layout APIs
iank: so leave that door open
iank: I'll need to do some work, spec wise, to get it so that an
impl can run this synchronously
iank: Still requires a queue to go through layout requests
iank: Once I've got that written down, make sure it makes sense to
everyone
frremy: What if you await Promise that never returns?
iank: When you call layoutNextFragment(), pushes a request onto an
internal queue. If layout engine has exhausted that queue
iank: It'll keep queuing its own tasks, flush that queue and check
if resolved promise is done
iank: If [missed]
iank: Summary of the engine is, layoutnextfragment()), pushes onto
internal queue for custom layout instance. Layout engine will
enqueue a microtask.
iank: Lay everything out and then queue itself again in case extra
work
iank: if it finishes, then... if promise is resolved, then done
Rossen: So, resolution is to switch back to Promises
Rossen: Any additional comments or objections?
eae: Can we add a note about error-handling expectations?
ACTION: iank to add note about error-handling expectations
RESOLVED: Use Promises (and add note)
Naming for percentageInlineSize / percentageBlockSize
-----------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/437
fantasai: Could also do inlinePercentBasis / blockPercentBasis
iank: This is what you resolve percentage sizes against
Rossen: “percentResolutionBasis” is kindof what this is about
Rossen: but that's kinda verbose
frremy: Issue was that there was some confusion, wanted to make it
less confusing
iank: It's easy to guess what the other names are, wanted to keep
this one consistent
iank: e.g. availableInlineSize / availableBlockSize
Rossen: inlinePercentBase / blockPercentBase
Rossen: Let's close this no change
Rossen: Get an option more people would be excited about
RESOLVED: No change
Intrinsic sizes and orthogonal children behaviour
-------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/776
iank: I can say what I expect
iank: I expect that Sizes is the intrinsic size contribution of that
child in the parent's writing mode
iank: Different engines will calculate it differently
Rossen: That sounds overly vague for it to be any kind of definition
in the spec
fantasai: You're trying to say that the result of that should be the
same thing that the layout engine uses for intrinsic size
calculation
fantasai: whether it's shrink to fit on [various things], intrinsic
size keywords, ...
fantasai: They should all return the same thing, which is the thing
returned here, and just be clear about which axis we're
grabbing from
fantasai: I think we can put that in the spec, and is definite
enough to not be vague
fantasai: It's exactly what we're doing in the sizing spec in a
number of cases: we don't define how to calculate the
intrinsic size, but we require it's consistent across all
the places we use it
Rossen: I agree
RESOLVED: Intrinsic size in orthogonal flows are taken according to
the writing mode of the containing block, and
intrinsic size calculations have to be consistent with all
other places in CSS (per CSS Sizing).
Typed OM
========
TabAtkins: No open issues to discuss, just a bunch of edits I need
to make
TabAtkins: Unless someone has an issue to discuss
Chris: List of changes, DoC?
TabAtkins: No
fantasai: We should get TabAtkins's edits, publish a WD, issue a
Last Call, wait a few weeks, and then go to CR
TabAtkins: We have an implementation, one of our engineers is
working on it.
Rossen: Firefox?
heycam: Not of Typed OM
heycam: Q4 someone should start looking at it for Firefox
fantasai: Is Blink shipping the implementation?
eae: Yes
dino: Does it have benefits? Is it faster?
TabAtkins: Much faster for animations, e.g.
shane: Performance numbers in the intent to ship
tantek: You do that without it being in CR?
tantek: Without anyone else implementing it? wow.
shane: Depends on various factors, but yes.
TabAtkins: Bunch of edits, but biggest task is filling in
serialization of properties appendix
TabAtkins: And that's easy for someone else to work on
Rossen: frremy ?
frremy: Sure.
RESOLVED: Add frremy as co-editor on css-typed-om, move nainar to
former editor
Custom Paint
============
fantasai: Wasn't Paint supposed to be a CR?
[people can't remember what's going on]
[WD was published:
https://lists.w3.org/Archives/Public/www-style/2018Apr/0036.html ]
fantasai: Are there any open issues on the spec?
iank: One open issue.
fantasai: Then let's close it and go to CR.
Optional arguments in paint functions
-------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/763
TabAtkins: Somebody wants optional arguments in paint functions
TabAtkins: It's a very reasonable request
TabAtkins: However, this falls under the more general issue of
optional bits of syntax in custom properties
TabAtkins: which is currently not allowed because of issues around
parsing ambiguity
TabAtkins: So we need disambiguation support first
florian: Is this a hard problem, or we need to solve it but haven't
yet?
TabAtkins: latter
TabAtkins: Definitely not impossible
TabAtkins: Support for more syntax-y things is slated for L2
fantasai: So proposal is close deferred to next level?
TabAtkins: That's what I would like
Rossen: Any other opinions?
RESOLVED: Deferred to L2
Publication
-----------
fantasai: Is there anything else is needed for the spec?
iank: No
TabAtkins: TypedOM has changed how it handles image values
TabAtkins: which might affect this, but it's not affecting this spec
Rossen: Any objections to taking Paint API to CR?
Rossen: No? Resolved.
RESOLVED: Custom Paint to CR
Chris: DoC? Changes List?
<dbaron> there were 3 or 4 edits since the last TR version
<dbaron> https://hg.css-houdini.org/drafts/rev/3a0546211ec0
https://hg.css-houdini.org/drafts/rev/61ae417ae9ee
https://hg.css-houdini.org/drafts/rev/acb3d3f259ce
[discussion of administrative stuff to get to CR]
fantasai: I can help IanK make the DoC and stuff
CSS Animation Worklets
======================
TabAtkins: Nobody is here. Let's skip
ACTION: iank to move spec to houdini repo
Implementation
==============
Rossen: Demos and then lunch?
Rossen: Or pressure IanK to do edits
shane: We could spend the afternoon on getting the specs to CR.
RESOLVED: IanK, shane, Tab, fantasai, and ChrisL to stay the
afternoon and get specs to CR.
dino: Other browser implementations of custom layout / paint / etc?
Rossen: Custom layout only in Blink
iank: Experimental. Going smoothly, might do an origin trial later
this year
iank: If authors like it, don't find any issues, will push for CR.
heycam: We won't be looking at custom paint or layout this year.
Pushed to next year
dino: So everything we've discussed today is only implemented in
Blink, nobody else. That's scary.
iank: Paint API is simple to implement.
dino: Worklet is tricky
ChrisL: You need worklets for Web audio anyway
dino: It's all new to us
dbaron: For us the big obstacle might be TypedOM
dbaron: Feels like biggest dependency of custom paint
iank: You can do a stripped down version of Typed OM, which
everything returns CSS style values, and upgrade up
iank: People can feature-detect that.
dbaron: I think that would be fine if we were shipping before you,
that'd be fine
dbaron: But if shipping 6mo to 1yr later, then we need to implement
the same featureset you have, otherwise won't work
dbaron: One question is whether there should be an alternative in
the API that doesn't use typed OM
fantasai: If you're going to do that, why not just use what iank said
iank: Polyfill we've got out at the moment, doesn't use a whole
bunch of typedOM stuff
iank: If you just ship the style value part, should still work
dino: How many WPT do you have?
iank: Quite a few
iank: For layout 80-100, more like 150 by the time we're done
iank: paint API has 65 atm
iank: Has a lot grouped in together into one test
iank: Unsure about typed OM...
iank: It's got like 4000
[discussion of tests]
Rossen: WebKit?
dino: We'd probably do it in order.
dino: Clearly we need TypedOM for paint, and also will give a lot of
immediate improvements for developers
dino: Other things, unsure how we'll prioritize
dino: You see articles about people saying how cool Houdini is, but
not so many people giving loud feedback about how they need
this particular feature
dino: Hard to gauge what people want more than anything else
dino: Dunno how we'd prioritize, other than TypedOM coming first
Rossen: We're in the same boat
Rossen: It's going to be a sprint or two for us to put things
together
Rossen: Google spent significant time and resources getting to where
they are
iank: Main cycles for us were typed OM and worklet infrastructure
iank: Paint stuff was relatively trivial
iank: Layout stuff isn't particularly difficult once you've got the
rest of the infrastructure.
iank: Reason worklet took so long is because we were waiting for ES6
modules to land
iank: So we had working in a few months, but took awhile to get up
to spec compliance
iank: If we didn't have the ES6 dependency, would've been a lot
faster
iank: Paint was just a quarter
Rossen: Paint seems easiest once you have the infrastructure
iank: Typed OM was biggest engineering investment
iank: Paint and layout are trivial after that
florian: TypedOM was difficult because big, or because churn?
shane: Both
shane: We spent a lot of time adjusting spec and implementation in
response to feedback, which others won't have to do
Rossen: So, I think summary of implementation status is blink has
quite a bit ready to go, Firefox has started on some of the
properties and values, logical next one would be typedOM
Rossen: WebKit and Edge have not started
philipwalton: From developer feedback perspective, I don't hear
people asking for typedOM, I hear a lot of requests
for paint to animations, and lot for custom properties
support
dino: I would've assumed that what people want nowadays is custom
layout
dino: They write their react code, and want to do everything
themselves.
philipwalton: That was my perspective, but some developers want
that, not everyone.
philipwalton: You can't polyfill layout, but you can fallback nicely
for paint stuff
philipwalton: So that's what developers want now
philipwalton: The things they can do now, they want to do
florian: Also, these things can be easy enough that individual
developers to do it
florian: But layout is harder, so more likely waiting for a library
to be developed; fewer individual users
leaverou: My impression is also what Philip said. Primary concern
devs have is transitioning and animating custom
properties, not just via properties and values API
leaverou: I've presented this API at several talks
leaverou: The most common question I get is, why do we have to use
JS for this? Why can't we have it in an @rule?
florian: Type declarations, you mean?
leaverou: Yeah
frremy: Greg and I have been talking with devs. They're mostly
unhappy about perf and not having proper APIs for things
they want to do, not trudging through bad APIs
...
Rossen: When you compare teams with highly-skilled devs on products,
they will put anything they want, write their own middle
layer if they need
Rossen: Some person supporting small website, won't be writing
custom layout
iank: A bunch of things Material Design team wants to do, are easy
in paint API, very difficult without it
Rossen: OK. Anything else to discuss for houdini?
dino: Are we meeting at TPAC?
dino: Also why do we consider separating the groups because ppl are
in both of them?
TabAtkins: Not exactly true
florian: ... split tracks
TabAtkins: Yes, should meet at TPAC
Rossen: I have room for Thursday, we have dedicated
florian: So effectively 3 days for CSSWG at TPAC
fantasai: The way we have scheduled this year is super uneven
fantasai: Expect a lot of topics on the agenda for CSSWG at TPAC
[Meeting closed]
Received on Wednesday, 18 July 2018 22:08:02 UTC