W3C home > Mailing lists > Public > public-houdini@w3.org > October 2015

Minutes Paris F2F 2015-08-25 Part I: Script API, Elephants in the Room

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 16 Oct 2015 19:38:25 -0400
Message-ID: <CADhPm3vWb05PE8HTUpGehMfL+t6ygmZm38j=4tz-RaYxrs174Q@mail.gmail.com>
To: public-houdini@w3.org

  - 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
      - 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.


  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

  Daniel Glazman

  agenda: https://wiki.css-Houdini.org/planning/paris-2015?&#agenda
  scribe: dael


  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

  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
  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
  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
  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
  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
  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,
  <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
  <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
  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
  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
  SimonSapin: They're not completely arbitrary. Each of the children
              will need data.
  Florian: Can we allow custom JS doing this to communicate between
  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
  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

  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

  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
  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
  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?


  <tantek> this is the article I referenced:
           "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:
  <tantek> Jeffrey Zeldman's broader piece on the subject:
           "Publishing v. Performance—or, The Soul of the Web"
  <tantek> And even harsher critique of The Verge:
  <tantek> context: Vox Media publishes The Verge
Received on Friday, 16 October 2015 23:39:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 16 October 2015 23:39:27 UTC