- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:38:25 -0400
- To: public-houdini@w3.org
Agenda
------
- This discussion to set the agenda held no technical details.
Script API
----------
- There was conversation about how much communication should be
limited in order to ensure that the APIs don't cause
significant slowdown.
- There were several proposals for way to avoid a slowdown
including not guaranteeing persistency and killing scripts
aggressively
- Generally there was agreement that there was no way to be
unrestricted and have any kind of decent performance.
- The choice was framed as between being effectively part of
the computation interface and having the ability to modify
individual results or being a part of the thread and
having access to the data, but having more restrictions.
- RESOLVED: Add an ED for CSS Script API (name TBD).
- RESOLVED: Name it Isolated Workers
Elephants in the Room
---------------------
- There was a desire to make sure that everyone's concerns and
worries what may be problems and pitfalls of Houdini.
- One major concern was that exposing these hooks would lead to
bad performance.
- This potential pitfall should be kept in mind with all of
the Houdini projects.
- A potential mitigation would be to make sure that there is a
feedback loop for authors to discover what is causing a
slow down.
- Another expressed desire is that manageability be taken into
account so that bug fixes are easier.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Rick Byers
Tantek Çelik
Dave Cramer
John Daggett (phone)
Rob Flack
Simon Fraser
Dael Jackson
Dean Jackson
Brian Kardell (phone)
Ian Kilpatrick
Chris Lilley
Peter Linss
Cameron McCormack
Simon Pieters
Liam Quin
François Remy
Florian Rivoal
Simon Sapin
Elliott Sprehn
Alan Stearns
Shane Stephens
Ojan Vafai
Lea Verou
Ian Vollick
Greg Whitworth
Johannes Wilm
Steve Zilles
Regrets:
Daniel Glazman
agenda: https://wiki.css-Houdini.org/planning/paris-2015?&#agenda
scribe: dael
Agenda
------
Rossen: Welcome everyone.
Rossen: First thing is the agenda.
Rossen: So we have a couple of topics that will go as first thing.
Is there any time restrictions or preferences from anyone
here?
shane: We had the jdaggett request.
Rossen: jdaggett what time is better for you?
jdaggett: Discussions after 2pm your time would be better.
jdaggett: I'll be here for around 2 hours and I can be on from now
after 2pm your time.
Rossen: So we'll do font metric and line related in the afternoon.
<jdaggett> rossen: guessing "deadrange" is in there too
Rossen: Other preferences for topics?
SteveZ: No layout Saturday afternoon
Rossen: Can we do it this morning?
several: Yep.
Rossen: We had the two items prepared for this morning, scripts
API which is one of the Ian's...iank. There was a topic
elephant in the room.
Script API
----------
<iank> http://bfgeek.com/css-Houdini-drafts/css-script-api/Overview.html
iank: Basically we've been thinking a lot about how all the APIs
will work with script. One thing we noticed early on is a
lot of the APIs are very valuable. Take a hypothetical
layout.
iank: You could remove yourself during the middle of layout which
would cause a lot of issues for at least us. So we needed a
way to make the world sane for these APIs.
iank: Two options: run everything in the main execution context
and lock things down or create separate execution contexts
the APIs could run in.
iank: We didn't investigate locking down the path much because it
ties you always to the main thread which isn't desirable if
a UA wants to move all the custom paint code. Second is
playing whack-a-mole with locking down. Does that match
other people's thoughts? Other concerns?
Florian: I'm wondering if there is a generic example. What you
said about paint made a lot of sense, but when it's
custom values I'm not sure the same apply.
iank: It would.
shane: I think, one point is the concerns are less at style time,
but the same concerns to exist.
iank: I can't remember what but there was something we could do to
break the style engine.
shane: The phase with the most potential is with custom style. The
advantage of building in a custom style environment...you
get to work with more pieces of the style engine so the
transitions engine will work for you. You get the step
computations retained. You can make use of the type system,
you get all this because you're embedded in the style
engine. If you're in a main thread you'll have to do more
of the work yourself.
shane: You can't be in a main style thread and expect to be
invoked. So you don't get a chance to participate in those
parts.
TabAtkins: And you can't expect to be called in the middle, you
can screw everything up.
iank: A good test is if you're doing an apply style hook on an
element and it will stay display: none, all bets are off.
Florian: Okay.
shane: The choice we have is being effectively part of the
computation interface and having the ability to modify
individual results or being a part of the thread and having
access to the data, but having more restrictions. And not
having the ability to participate as well.
iank: We thought some sort of separate execution context was the
way to go. The next question that came up was how many of
the separate execution contexts should we have. It would be
nice to constrain the world in such a way that if you're
doing custom layout you're constrained to yourself.
iank: This has severe implications for us and a few other UAs and
the execution costs are expensive. It would be 200kb for it
and takes 1ms to spin up. We don't think we can get around
the memory.
iank: This led us to think separate execution per phase.
dino: All instances of that phase?
iank: Yeah.
dino: So if you're loading multiple custom layouts they all share.
iank: Yeah. This obviously has consequences for if you have a
custom layout high on the tree and low on the tree it can't
communicate. If different UAs have different painting
behavior this could lead to UA dependent behavior if authors
don't write their functions in a specific way.
shane: We'd like to lock down script relations in a certain way
and then UAs could do what they want. It's hard to lock
down JS like that. There's no way to do it and still have
useful libraries.
shane: There was offline discussion yesterday about requiring
browsers to maintain at least two contexts and to randomize
them to force browsers not to have problems.
dino: So if you run a custom layout the proposal is .5 that you'd
end up in one event.
esprehn: We kill aggressively and it's worked well.
smfr: What is the lifetime of a context?
iank: Basically we think, but want feedback, you can kill if you
background a tab.
shane: That would be up to the UA.
flackr: If you apply the randomization, you're not promising any
consistency to the user. The UA could do what they want.
dino: What if they want persistence?
iank: There's two ideas there. First is to stash everything in
your computed style object that goes down the tree. The
other is to have an explicit API that's similar to the cache
object.
shane: Already at this point if you want to use the JS library in
this context it won't work on unmodified.
shane: Our job here is to work out which set of things are the
most powerful and what will we sacrifice and what won't we
for this. It's a hard call.
iank: I think the ideal doesn't exist, it's a whole bunch of trade
offs.
iank: Between what performance and API characteristics that we
have, etc.
smfr: The spec doesn't address the UI Workers case. Should there
be a spec that covers all the cases?
iank: This spec has empty execution contexts and that would be an
extension. I wrote this not thinking about the compositor.
vollick: I thought the same thing looking at this where I hoped I
could use it for the compositor.
iank: To the API in the spec, this is out of date. Also I can
change the name from CSSWorker. Basically it's a standard
dedicated to work on a global scale with everything ripped
out. You don't have UI specific things, you have the empty
worked global scope. I think we want to get rid of the self
attribute too.
iank: We also don't want to import scripts as well.
iank: It's empty global scope and for each type of worker it would
extend this and insert the global API.
iank: We have to do a bunch of thinking about promises etc. How
you load scripts into these workers, you get a reference to
this type of worker from the context. You can see in the
example you can import scripts into these contexts.
iank: Because of this we don't specify how many are running or
where. So if the paint worker, we have 2 or 4 and they're on
a different threads, that's fine. You could load them each
time.
iank: We think when loading the scripts into these execution
contexts, we'd like it if we can wrap in an anonymous use-
script mode so they're a little more locked down.
iank: And that's basically the API.
smfr: What is the use of it being an event target? On global scope.
iank: I think we want to remove that because you can't do anything
with it.
smfr: And the CSS worker's target?
iank: You may want this...so initially I had import script as not
returning a promise and it would throw. You may want this as
an event target if an error was caused in the script. That's
the only reason I can think of.
smfr: So it's error handling.
iank: Yeah. If we think we don't need it, fine. Similar to
abstract worker.
<franremy> * question: How do we deal with name conflicts if they
have to share the same context? Do we have something
planned for namespacing, like to avoid conflicts
between shared libraries but different versions?
<franremy> (to clarify my question, I meant in case multiple
frameworks/scripts want to register a custom layout)
<TabAtkins> franremy: Name conflicts are only possible if you're
trying to persist by writing to some global scope,
which is difficult to do.
<franremy> TabAtkins: Okay, so you argue people should wrap their
code in a module and not expose anything. That's fair,
thanks.
<TabAtkins> franremy: Nah, we plan to do that for you.
<TabAtkins> franremy: Wrap the code in an anonymous "use strict;"
function, so you lose easy access to the global.
<franremy> TabAtkins: great, question answered
<heycam> franremy: I think that loses "this", but you can still
refer to say Number
<heycam> franremy: and communicate through setting properties on
that
<TabAtkins> heycam: Yeah, stashing on shared prototypes is still
available, which is what the "randomize the contexts,
reset them aggressively" is intended to address.
* heycam wonders whether you can actually Object.freeze all of the
things on the global, and then the global itself
iank: Any other feedback?
iank: Is this the right approach?
dino: The API seems fine. It's missing when they're creating,
which I guess is what we discuss.
iank: We need to lock down the lifetime. We want to leave it UA
dependent.
TabAtkins: I suspect we want to put some guidance in. Something
like killing or just to put a note in there.
Florian: Not only say you shouldn't guarantee persistency, but you
should screw it up.
dino: I'm interested in how you do things, not how you stop things.
shane: We do have an agenda item for that.
shane: I guess we should talk about what should be allowed.
There's data that needs to be passed for an element.
dino: A paint operation might want to save to an offscreen canvas.
There's lots of stuff to discuss there.
shane: Maybe an important question is do we see a need for
communication between different elements on the page. We
can see in the pipeline for an element you have to pass
data and individual elements need to store data.
iank: We don't want elements to pass between because it allows us
to do the validation. If you have communication and it
leaves you in a bad state it doesn't know there's an error.
smfr: It seems the first thing people want to do require
communication between elements.
shane: If we went outside the DOM hierarchy it wouldn't work.
ojan: When do you want communication?
dino: Coordinated layout.
smfr: You want siblings grow the same size.
ojan: You want an arbitrary descendant to be the same size over
here.
TabAtkins: You want multiple tables to have their columns be the
same width.
ojan: Our model has been providing primitives for what the
platform is so next time we want to have a new layout mode
we don't have to bake it into the browser.
Rossen: I agree.
smfr: You're dangling a carrot in front of web dev and it won't do
what they want it to do, which is the tension.
iank: One API we could allow that would let invalidation work is
before layout the ability to do a tree walk so you could set
up a whole bunch of information and that would make
invalidation work.
iank: The risk of that...the other risk with allowing arbitrary
communication between phases, doing something between two
threads is hard.
Florian: SimonSapin, can you comment on that because I think Servo
has more experience on that.
iank: We're discussing what are the multi-threading implications
if we allow arbitrary communication between the box tree in
the middle of layout.
SimonSapin: The way it works now layout can work parallel with
script except during style computation because the
layout has access to DOM and we don't want to change
what happens. Once style computation which includes
constructing the tree, the script can walk on that
tree and continue talking the DOM. I suppose we could
do some layout on that layout tree. We would have to
do something else to have the API accesses.
Florian: Is it a single thread doing layout in parallel?
SimonSapin: Many threads.
Florian: So arbitrary communication would cause synchronization
problems?
SimonSapin: They're not completely arbitrary. Each of the children
will need data.
Florian: Can we allow custom JS doing this to communicate between
nodes?
SimonSapin: In custom layouts if we're accessing parts of the tree
that would prevent layouts. We split into different
operations such as compute the height of the element
which may include computing the height of the element.
And on each of these there are different restrictions
on what you can access.
ojan: In terms of use cases, I've had a few in mind. One is
implementing something like flexbox or grid. The complicated
approach is doing a constraint based layout system. What
I've been picturing is you own the whole thing so you do the
constraint painting yourself.
Rossen: That's one of the things I've been having a hard time
wrapping my mind around.
smfr: I haven't looked at the CSS layout much and maybe I'm not
thinking in the right terms, but I'm thinking as an author I
want to do these cool things and this isn't right.
<dbaron> I think the layout API could also work where a custom
layout says which part of its subtree it's taking
ownership of laying out (e.g., of just its children, or
of a deeper subtree than that).
dino: This seems like an okay direction and let's discuss the spec.
SimonSapin: Maybe the API could allow communication when possible,
but still have an additional case where you don't know
anything in the initial places. Only in the last
version will you have access to all of your subtrees.
It's not going to be perfect.
Rossen: I think this is a good thing to discuss in custom layout.
I think we're starting to dive into what's required for
layout. For the general point of view of restraining
layout and communication, I think that what you've
proposed makes sense for me.
dbaron: I was saying in IRC, it seems like the layout API could
work in a way that the custom layout could take ownership
of laying out a deeper sub tree or just its children. One
is useful for grid, one for complex layouts.
TabAtkins: It's something you have to opt into.
Florian: This is related to custom style computations where you
may need access to your parents and if you do that
changes the part opposite then you have access to.
shane: From what SimonSapin was saying, you haven't done parallel
style.
SimonSapin: It's a top-down pass.
SimonSapin: Yes, it is parallel.
Rossen: iank in your prototyping, have you had any reasons to
share data?
iank: Not specifically but only because we've been building
layouts in the web.
iank: One would build a stripped down flexbox and compared it to
native under the same conditions to look at the
characteristics and see how performance changes. It didn't
do too bad. It's a micro venture, but with a few performance
tricks it was half as fast. Which for JS with no
optimization that's pretty good.
Rossen: Anything else on this topic?
iank: Do we need an ED and what to call it?
shane: We need a spec that talks about this, it's clear. This spec
that iank has provided, should we make it an ED?
Rossen: Objections to adding it to the charter?
RESOLVED: Add an ED for CSS Script API (name TBD).
dbaron: We may want to spend a few minutes discussing name.
dbaron: It may be good to pull API out.
iank: CSS Script
Florian: CSS workers
franremy: Do we have to have CSS in the name?
iank: Just call it script.
dbaron: Isolated Workers
RESOLVED: Name it Isolated Workers
Rossen: I just want to pull up the agenda quick.
Rossen: So we'll move on to the gregwhitworth topic and then
prioritization and passing data.
Rossen: Starting in a pipeline, we'll go through the afternoon
topics and that should take us through the day.
smfr: I'd like to add a discussion about scrolling and UA workers
Rossen: There's a topic on Saturday.
ojan: I'd roll that into async style.
Rossen: [goes over Saturday]
SteveZ: Can we do pagination Saturday morning?
Rossen: My thinking was if all the font stuff doesn't fill today,
we'll pull it into the afternoon. If not we'll do it
Saturday morning.
<leaverou> agenda+ Github issues topic from yesterday (context:
see discussion in #css)
<TabAtkins> +1 to lea's GitHub suggestion, let's talk about this
today or tomorrow in the context of Houdini.
<SimonSapin> Rossen, agenda+ using one source repo per spec, using
github for issue tracking?
Elephants in the Room
---------------------
gregwhitworth: This got added when we started on properties and
values. We found a lot of what we're trying to
accomplish ends up having to fight the pipeline. I
wanted at a minimum to let people know that are
following along to know what other large hurdles we
have to see something that actually works.
gregwhitworth: For example the performance issues we could see,
not in a single custom layout, but if fruition is
seen down the road and everything is being
controlled you start to realize the mess. I'm not
saying it will be realized and I'm thrilled iank is
working on this.
gregwhitworth: Another example is parsers and values. If you have
a layout library it's going to mess with it.
Authors are starting to talk about it and I want to
make everyone aware there are large elephants and
small elephants and we need to mark them.
gregwhitworth: Google and us have talked about the performance
hits, but I'm looking for a round table discussion
about if anyone else has seen large issues we need
to address so we're not just throwing useless APIs
together.
dino: We have a significant fear that this is have a bad effect of
what this could do to the web. People are complaining about
web performance.
dbaron: The flip side is people are doing some of the things these
APIs are for and they do them worse.
gregwhitworth: That was our concern and that's not the direction
that we're heading. We're finding use cases and
solving them instead of native APIs.
dino: The fear isn't the developers are currently trying to do
things like this, it's that web pages will import their
bodyscripts that have 50 ad networks. It's not the good
developers I'm worried about.
smfr: People write a lot of bad JS. The browser engine can't
optimize around the scripting hooks. Which is a contrast to
declarative where the browser can optimize. We're reluctant
to expose new hooks without good reason.
vollick: We'll have to have some sort of admission control. Maybe
we need to do it in other places then the async.
smfr: But if you abort the script the user has a bad experience.
ojan: The APIs are actually hard to use. A naive user couldn't use
them. It's because they're low level and the ergonomics
aren't awesome. I don't necessarily view that as a bad thing.
The people writing code will be framework authors.
smfr: People find stuff and use it and copy paste.
ojan: Flexbox is my example of what we have today that doesn't
work. It's full of these hook values and part of the reason
is that one API had to solve every case and we didn't give
people an out. The libraries don't have to address every
case.
shane: The problem you're worried about, we have that already. I'm
not sure we're widening the scope. Where you see ad
networks that trash a webpage is when the only avenue they
have is non-performant. These people aren't stupid, they
have no other choice.
dino: It's not that they're stupid, it's that they have to do a
hack to get it done.
shane: They have no other way.
smfr: I don't think ad networks will write custom layout, but
they'll use hooks.
shane: If you can only do layout with a layout hook they can't.
ojan: I think this will be more useful once we've talked about the
specs proposed. The thing that they do where they query all
the positions, you can't do this with these APIs. I'm less
concerned about an ad network destroying the whole page.
Currently one ad network can do something to make the whole
reasonable page fall over. These APIs you can only make your
page horrible.
gregwhitworth: One of the elephants that we hit is collisions. How
do we handle name spacing if they're all in various
ways?
gregwhitworth: We don't need this for 45 min, but I'm glad you
have similar worries. But I always like to point to
the flip boarding and people are bypassing
everything to feel like they've done something so
I'm open to exploring it further. I'm open to
continuing these conversations. I want it know this
could end the web if we do it wrong.
dino: Flip boarding throws everything out to deal with the problem
space. You don't have the anything goes of the web. We're
not saying don't look into it, but even if you're only doing
layout, every time we add script it makes some things better
and things we don't know about worse.
rbyers: I don't think I agree. I think we're catching up. The
problem you're describing we need to tackle as browsers
spec from Houdini. Houdini adds complexity, but maybe we
should discuss as browser vendors how to deal with those
problems. There's low hanging fruit.
rbyers: There's a whole application monitoring industry for people
to figure out what's going on in the wild. Maybe search
index should take performance in account. Maybe there
should be cues like frosting out the window when an app
slows things down. There's tons to do, but it's orthogonal
to Houdini.
flackr: I think Houdini makes this easier to check performance.
This lays out script and boxes, they don't have hidden
complex costs. We could lay out a heat name.
rbyers: So we should keep in mind these performance principals
whenever we design something, Chrome just got a developer
tool so you can tell CPU time per origin. Maybe we can
agree to let all performance be track back-able. Or all
features are designed with performance principles in mind.
smfr: What we do, you get nickeled and dimed as you layout over
elements. If people do custom layout you get that and you
end with slow performance, but you can't blame one thing.
shane: Part of that is the depth of the trees people use. My hope
is these APIs will help slow that down.
TabAtkins: The two major Android layouts are flat, but do complex
layout that would require significant nesting in
flexbox. Being exposed like Houdini allows flatter DOMs.
shane: A native app with 100 widgets would be heavy weight for
mobile, it's not uncommon to see them with 1000 or more.
The layout we provide isn't what people want and so they're
doing a lot of nesting.
Rossen: That's also true for XAML as well for how the framework
works. You can hook on any callback. You have the
primitive non-primitives like grid and you can operate the
way they work.
Rossen: From talking to some of the people who work on it, I was
trying to cull their feedback on the performance.
Surprisingly enough it was almost never layout, their
frames weren't bound by custom layout. Most of their run
time is impacted by things outside the box.
Rossen: Even with such an extremely open API platform, there's not
a lot of evidence that people are shooting themselves in
the foot.
Rossen: It's not clear that XAML developers are comparable to web
developers, but you can have an open platform and be
performant as long as the code we write is reasonable.
tantek: Building culpability into the system as part of creating a
feedback loop is the right approach. Any smart
architecting, we'll get things wrong. If you build in that
culpability of what's slowing things down, it enables at
the UI level the frosting effects you mentioned.
tantek: At that point we give the opportunity for browsers to
surface to the user or give them options to kill that
thing or block it.
tantek: Responsible iteration is how you'll solve this.
rbyers: What I'm encouraged by is there's discussion about how
performance relates to business metrics. The people making
money on the web realize it's correlated with performance.
If we design in a way that encourages it, the internet
will take advantage of it. We failed on this before, I
think we have a lot of catching up to do.
tantek: If there's culpability, that's great.
gregwhitworth: One other, while we're scoping I would love to take
manageability into account. There is a website that
I spent two days doing a bug fix because how they
had designed and nested and minified. Manageability
for anyone viewing is rather important. We're
adding more help, but the bugs we get will be more
complex.
Rossen: Are you proposing something actionable?
gregwhitworth: I don't have an exact answer, but when we do this,
I don't want to make it worse. We have source maps,
maybe we could tie those in. So yes, it's slightly
a rant.
Rossen: Anything else on this?
<break=15min>
<tantek> this is the article I referenced:
http://www.theverge.com/2015/7/20/9002721/the-mobile-web-sucks
"The mobile web sucks " which ironically illustrates the
problem of bad web development practices are what are
making the mobile web suck.
<tantek> Jeremy Keith's analysis/critique of said article:
https://adactio.com/journal/9312
<tantek> Jeffrey Zeldman's broader piece on the subject:
http://www.zeldman.com/2015/07/29/publishing-versus-performance-our-struggle-for-the-soul-of-the-web/
"Publishing v. Performance—or, The Soul of the Web"
<tantek> And even harsher critique of The Verge:
http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/
<tantek> context: Vox Media publishes The Verge
Received on Friday, 16 October 2015 23:39:26 UTC