W3C home > Mailing lists > Public > www-style@w3.org > February 2016

[Houdini] Minutes Sydney F2F 2016-01-30 Part I: Agenda and Goal Setting

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 21 Feb 2016 14:45:29 -0500
Message-ID: <CADhPm3s5YZsciwopMbd51MSSPA8r43-AMvgi3t4EDN96sQD64w@mail.gmail.com>
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.

Agenda and Goal Setting

  - Rossen opened the meeting with a conversation to re-dedicate the
      group to the ambitious goals that Houdini was started with by
      looking at how C++ handles extensibility and how CSS can move
      in that direction.
  - Box Tree API was brought up as potentially unnecessary, though
      others believed that it could be used as a umbrella spec used
      to describe the foundations that other specs will reference.
  - There were two approaches mentioned for handling early-stage
      specs: A spec with a lot of issues or a ReadMe without a spec.
      - Both approaches had proponents so the selection between the
          approaches will be in the spec author's hands.
  - RESOLVED: Change the name of 'CSS Async Style' to 'Composited
              Animation and Scrolling'
  - Several specs were mentioned as close to FPWD, specifically
      TypedOM, Worklets, Properties & Values, Paint and the group
      decided to work on getting those to FPWD during the F2F.

====== FULL MINUTES BELOW =======

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016

  Rossen Atanassov (Microsoft)
  L. David Baron (Mozilla)
  Bert Bos (W3C)
  Rick Byers (Google)
  Tantek Çelik (Mozilla)
  Emil Eklund (Google)
  Simon Fraser (Apple)
  Joone Hur (Intel)
  Koji Ishii (Google)
  Dean Jackson (Apple)
  Ian Kilpatrick (Google)
  Peter Linss (Hewlett-Packard)
  Cameron McCormack (Mozilla)
  Simon Pieters (Opera)
  Elliott Sprehn (Google)
  Shane Stephens (Google)
  Surma Surma (Google)
  Alan Stearns (Adobe)
  Xidorn Quan (Mozilla)
  Ojan Vafai (Google)
  Jet Villegas (Mozilla)
  Ian Vollick (Google)
  Philip Walton (Google)
  Levi Weintraub (Google)
  Greg Whitworth (Microsoft)
  Steve Zilles (Adobe)

  Tab Atkins (Google)
  Dael Jackson (Invited Expert)

Scribe: shane

Agenda and Goal Setting

  Rossen: Looking at the wiki, the agenda is light.
  Rossen: Yesterday, Shane & I were chatting about how to kick off
          meetings. I gave him a quick sketch that I've been using
  Rossen: We're going to use that sketch now to give us some focus
          for what we're after and what we want to pursue.
          Afterwards we'll hopefully end up with an actionable

  Rossen: When we look at the web platform, we have a platform of
          network, parsing, DOM, CSS, layout, composition, render,
  Rossen: If we think about this at the level of extensibility, if
          you're a C++ dev then you can make changes to the entire
  Rossen: If you look at this from a JS point of view, though - DOM
          has pretty much 100% ability to interact with the model,
  Rossen: With a well defined public object, Element, and a good API
  Rossen: So extensibility in DOM is pretty well covered.
  Rossen: In CSS, you have CSSOM, you can access stylesheets and
          play with style sheets, however if you want to extend this
          you can't - you can't define your own properties or
          values, interact inside the cascade, etc. So CSS is
          *somewhat* available but there's a lot missing.
  Rossen: Layout you can do a bunch of read-only callbacks. These
          are on the element, you can't interact with layout object
  Rossen: Composition and rendering you get basically no access,
  Rossen: although perhaps Canvas is in this level.
  Rossen: Input has some primitive events that you can use to try to
          participate in the pipeline, but it's not overall well
  Rossen: So bottom line, if you want to extend the platform e.g. by
          adding a layout feature...
  Rossen: In JS, you are forced to loop through the whole pipeline
          so it's very inefficient. If you want to add the feature
          in C++, you just add it.

  Rossen: So what are some of the mechanisms that make things easy
          in C++? There are a couple of things working for us:
  Rossen: (1) strict rules, experts, code reviews
  Rossen: (2) well defined internal objects to hang extensions off
  Rossen: If we were to try and lift that extensibility to the JS
          level, our current efforts in Houdini have been focused on
          extending e.g. paint - participating in paint.
  Rossen: We've also talked about custom properties and values.
          There has been some interest (but no action yet) in terms
          of the parser.
  Rossen: There's been efforts and interest in the input pipeline,
  Rossen: and we've discussed layout and layout API.

  Rossen: So when I look at this picture, the one thing that is
          immediately obvious is that this well defined Element,
          although it corresponds to the DOM, it is not just DOM. It
          gives you a lot more - lifetime, etc. - and you can use it
          to impact the platform in various ways.
  Rossen: For the rest of the platform, we have some kind of object
          internally in all our implementations - for now I'm going
          to call it the 'view' object. They're similar to Elements (
          collections of properties and values) but distinct.
  Rossen: All of the CSS properties we have today are applicable to
          the Element object but not to the View. In CSS we have
          this problem where whenever we add a new property there's
          a giant matrix of interplay with other properties.
  Rossen: The view object, at least in our implementation, has
          really well defined properties, but they have nothing to
          do with the Element. Things like width, height, custom
          rendering methods, etc.
  Rossen: A lot of what we're doing internally is trying to figure
          out how to focus most of the intensive stuff (animation,
          etc.) from layout down. We do this by trying to only
          animate or change the view object properties.
  Rossen: Unfortunately this is not always possible.

  Scribe: leviw

  Rossen: Layout and paint APIs are applicable to the view API.
  Rossen: Given that there's not much of an agenda for the few days
          that we're here, lets go back to the procedural things for
          these meetings.
  Rossen: We can try to spend some time this morning discussing the
          big picture and what the things we're looking to achieve
          are. What the things we believe should be there.
  Rossen: ... things like the view object.
  Rossen: We did something like this in Paris where we sampled the
          developers and....

  Scribe: shane

  Rossen: If we're as ambitious as we were a year ago, we shouldn't
          be shying away from the really hard problems.
  Rossen: Layout, input - these are going to be hard problems.
  Rossen: We don't need to figure them out completely now, but
          shouldn't be putting them away completely either.

  rbyers: Even if not exposing view object, what can we say about it?
  Rossen: Actually there's a spec that we're going to work on -
          process model for Houdini - that will outline how all of
          these things fit together, explain the role of view
          object, etc.
  dbaron: How does what you're calling the view object differ from
          what we were talking about as the box tree?
  Rossen: It doesn't - I'm keeping it vague deliberately - not
          necessarily a single box per view object. Speaking for our
          implementation only, we have different objects based on
          element type and box. They might be present but aren't the
          box itself - e.g. parts of the box, things for composition
          or manipulation.
  Rossen: So I'm not imposing a name, but I'm trying to avoid
          calling it a Box for now.
  Rossen: But in terms of referential integrity, it's mostly the box
          which would be backing up the view object.

  heycam: Has it been discussed before how fine-grained the view
          objects are?
  Rossen: Yes, in the context of the box tree. e.g. what are all of
          the inline fragments that are not necessarily backed by
          HTML elements, but ranges of content instead? Definitely a
          type hierarchy of objects that can be exposed to implement

  rbyers: One piece missing: compositing. We don't have anything to
          explain this, but can't explain e.g. scrolling without
          compositing. Need some kind of compositing API.
  Rossen: What sorts of stuff would go in here?
  rbyers: Our opinion is that there should be an API that lets you
          run script in a way that is typically synchronized with
  rbyers: It's known as async style, or as compositor worker. Async
          style is a weird name because it encompasses scrolling
          things too, which are not CSS related.
  SteveZ: I'm confused by "scrolling is not CSS" - most of this
          diagram is not CSS.
  shane: Is it just a naming thing?
  rbyers: You could ask same question about layout - is it really
  rbyers: I'd like to believe that part of what we're doing is
          enabling CSS to be swapped out,
  rbyers: not that we necessarily should.

  Rossen: Let's go through the specs. Aim is to get something to
          look at today and tomorrow. One idea is to spend the time
          getting specs ready to ship as FPWD - seems quite
          actionable. Allows people to continue implementation
  Rossen: I'm looking to see how we can move from 'we can' to 'we
  rbyers: One powerful idea - these are all complicated topics.
          Can't solve just with design and speccing. So for me, 'we
          are' is 'we are shipping features that are built
          internally on these primitives'.
  shane: Does it help improve confidence in the APIs if we are doing
         this with Chrome?
  smfr: It does to the extent that it shows the APIs are viable but
        also there's a risk of lock-in.
  rbyers: We need to be very humble about changing to keep up to
          date with evolving specifications.

  Scribe: iank

  shane: I'm just going to take us through the specifications that
         we have on drafts.css-houdini.org
  shane: I'm going to make some strong statements here:
  shane: Box Tree API, I get the impression that we don't need this
         spec anymore, we don't need this Box Tree API. There for
         two reasons, (1) as a measurement API (2) to help support
         some of the layout API to do fragmentation cases.
  shane: The first of the two use-cases is not very useful, as we
         need a frame of lag between the frame, (2) is better to
         roll directly into the layout API.
  shane: I don't think we should keep working on the API.
  rbyers: Should we still have some spec that talks about views?
  Rossen: I hope that this would be the "umbrella" spec, which talks
          about the main building blocks for the specs.
  Rossen: It's a framework, it makes it easier to talk/argue about
  Rossen: I'm impartial about the Box Tree API for that reason.

  shane: Should we resolve to drop the Box Tree API spec?
  plinss: I think that this is premature.
  plinss: I don't think we should resolve not to do this.
  shane: We want to drop the "API" part. The "umbrella" spec should
         define what the internal "view" object is and does, talk
         about its lifecycle, actions, etc. The ways of accessing
         that, in the future we may want to do that; however at the
         moment, we have better APIs like IntersectionObserver etc.
  shane: The fragmentation use-cases, building new boxes, etc, we
         should roll these into the Layout API.
  plinss: The other specs need to be able to reference these things,
          I don't care about the document that they go in.

  SteveZ: The API suggestions there didn't work, we should point to
          where these things will be defined in this document.
  shane: The "umbrella" spec should provide a really good model
         about these things.
  iank: I think the "umbrella" spec should cover most of these things.

  shane: CSS Async Style; is currently empty, people know this as
         Compositor Worker, a really solid explainer document would
         help a lot.
  shane: Same for the Layout API; create a Layout explainer.
  dbaron: It's also useful to have a history for things that we
          thought about.

  ojan: Can we just have an emeritus section?
  rbyers: Can just place these in the folders which have the spec?
  shane: Yup.
  shane: We will have a README.md for async style, and then
         eventually a spec.
  ojan: A good example of this is IntersectionObserver for this,
        nice easy explainer that is accessible for devs and spec
        authors, with the spec for spec authors.
  shane: We should leave it at the more understandable rather than
  shane: I think the CSS Paint API is pretty good at the moment.

  dino: Can we change Async Style to something that makes more sense?
  shane: Lets just call it Compositing for now.
  zcorpan: It was pointed out that there is already a compositing
           spec. (compositing and blending).
  esprehn: Composited Animation and Scrolling?

  RESOLVED: Change the name of 'CSS Async Style' to 'Composited
            Animation and Scrolling'

  Rossen: Concerned that we'll still have things on the list,
          because they're too hard, and pushing them off to later.
  shane: I don't think that is happening.
  esprehn: Instead of having an ED, we should just have an explainer.
  Rossen: I'm not pushing back on this, I just don't want to push
          things hard away.
  esprehn: I think that we want to think about this more.
  dbaron: I don't think that that has to be done in an explainer,
          you can do this in a spec, with a bunch of issues.
  esprehn: I find those hard to parse.
  SteveZ: I think that there are two issues (1) easy for new people
          to understand, (2) driving work forward; for (2) I don't
          think that the type of document will matter.
  dbaron: That there is a bunch of stuff that we agree on, that
          isn't written down anywhere.
  shane: We sort of have this issues in CSS.
  dbaron: Less as TabAtkins and fantasai write this all down.

  dino: Can we agree that putting them anywhere is better than
        putting them in the minutes?
  shane: They are just a place for people to talk about them
  shane: Think about them however you want.

  shane: CSS Properties and Values API; first part of this is pretty
         solid, people can start implementing this, the one concern
         that we have if the apply hook is worth it? We should just
         drop apply hook for now; and see if we need it later.
  heycam: What things does the apply hook do?
  shane: Adjust style properties of an element based on another
  rbyers: Scroll API, I think that we want a spec here, I should
          write down an explainer here. On blink we call it scroll
          customization, or scrolling extensibility.
  rbyers: On the naming of these, they are all about extensibility,
          CSS Layout Extensibility API?
  shane: TypedOM. There's solid ideas here, by no means complete,
         very large surface area.
  shane: Font Metrics, very much like parser, lots of talk, but
         nothing written down.
  iank: Worklets, are pretty good, rebuilt on modules, would like to
        sit with other implementors and talk about anything that
        might be content.

  shane: Paint, Worklets, Typed, P&V all have drivers, should get to
  shane: Make TabAtkins drive parser API more.
  Rossen: glazou is already driving it.
  shane: Sure lets leave it that way.
  shane: Async Style, vollick to create explainer.
  shane: Scroll API, rbyers create explainer.
  shane: Layout, iank & Rossen have been working ideas on this.

  jet: We have been getting requests for a css binary representation
       for pre-compute selectors and other things.
  shane: That could be another spec.
  rbyers: That could be a use-case for the parser API.
  Bert: Is the goal to make it faster or to make it smaller?
  jet: These are people that see CSS as the next target for
       something like WebASM.
  shane: We've had experiments in the past were if you simplify some
         rules, you get some things faster.
  ojan: We did some experiments with HTML parser were it got 20x
        faster. could do similar things for CSS.

  shane: Second question that I had is that do we want to go through
         each spec in one big group or split up into smaller group.
  astearns: I think smaller groups make sense for explainers / for
            things with FPWD makes sense for the whole group.
  ojan: Would like to get TypedOM, Worklets, Properties & Values,
        Paint to FPWD so that we can get implementations.
  shane: Do we make this our primary goal is to get paint to a
         primary goal?
  Rossen: get we get a show of hands?
  <everyone raises hands in the air>
Received on Sunday, 21 February 2016 19:46:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC