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

Minutes Paris F2F 2015-08-29 Part IV: Prioritization of Effort

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 16 Oct 2015 19:45:03 -0400
Message-ID: <CADhPm3sHziVABMzCZ06r_bxaq6m5=5F1btk1+Zq+eeAQG+fykw@mail.gmail.com>
To: public-houdini@w3.org
Prioritization of Effort

  - The group went through the specs to gather a picture of what
      specs the implementors were willing to put time in to build,
      which the authors present are interested in having, and which
      specs people were willing to put time into creating.
  - There was also discussion of the concerns of the implementors so
      that those can be kept in mind. The concerns included:
      - Lack of implementation resources.
      - A need to investigate how much should the implementors be
          forced to do the same thing versus how much should there
          be accommodations to allow the browsers to be difference
          because the cost/value analysis leads to the belief that
          it's not worth devoting time to change to be the same.
      - Performance.
      - That the parser won't describe what the browsers actually do.
      - Blocking browsers into certain implementations.
      - Ergonomics.
      - Allowing developer access to previously optimized pieces
          such as scroll.


  scribe: dael

Prioritization of Effort

List of Specs

  dino: It would be interesting to hear from people which specs they
        find most interesting.
  shane: I put this on here to provoke discussion.
  Rossen: Let's do it.

  dbaron: Should we start from a list of things we're working on?
  <smfr> https://drafts.css-houdini.org

    Box Tree API
    Async Style
    Custom Layout
    Custom Paint
    Properties and Values
    Font Metrics
    Rendering Pipeline
    Custom Context (script API)
    CSSOM 2.0
    Shorthand Properties
    Generalized Cascading Style Sheets [GCSS and Parser are
      connected...maybe the same]

  Rossen: Promise of box tree is it will explain the fragment tree.
  shane: Properties and values was the typed custom properties and
         apply hook.
  shane: Scroll wasn't spoken about this time, it's optimization and
         we talked about two models.
  rbyers: One set of APIs.
  shane: Rendering pipeline is ojan's.
  shane: Shorthand property we've only spoken in parsing.
  shane: I suspect GCSS is part of the parser.
  heycam: Apart from that the parser API isn't worked on.
  Rossen: glazou was working on that one and he's not here.
  ojan: GCSS is a specific proposal to expose CSS parsing and
  Rossen: The parser maps exactly how your described GCSS. That's
          what we discussed in Sydney. There's something else more
          interesting that if I want to hook up my own parser, how
          do I do that, which is not something we talked about but
          it is interesting. Once we have the people working on the
          parser here let's discuss.
  <bkardell> heycam and rossen: tab and i are "here" and lea

  shane: Anything missing?
  iank: No.
  Rossen: We can go around the room through implementors...
  SimonSapin: Is this interest in implementing, in working on the
  Rossen: I believe that if there are specs that generate a lot of
          implementor interest we should work on those. If you have
          specs with no implementor interest and you put spec effort
          there, what's the point?
  Florian: What about author interest?
  Rossen: I don't feel we have enough representation of author
  Florian: We have franremy and I'm a part of Vivliostyle.
  dauwhe: Various industries are represented here.
  ojan: I don't think we can represent users and authors.
  Rossen: Let's see where we get. We can further poll people.

Author and Implementor Interest

  brucel: The things people have retweeted have been custom paint,
          custom layout and font metrics. As a totally
          unrepresentative sample.
  leaverou: My impression is the box tree is high interest for
            authors. There are a lot of people making their own and
            they would like to know more.
  leaverou: With custom properties you don't make polyfills. You use
            a different property name, whether the property is
            implemented or not. They're talking about polyfills that
            work with how CSS is going to work. They're using the
            same language features.
  franremy: I agree, that's also something that's nice. You ask
            people to use prefix names and they don't like it. But
            we have preprocessors and they could be used to change
            the names people want to use into a custom property.
  leaverou: The purpose of the polyfill is it tests if the feature
            is there, uses the name if it is, and uses the feature
            if it's not. Preprocessors don't work like polyfills.
  franremy: You only run the normal code if you detect it's not
  leaverou: The custom won't be dropped if the native is there.
  dbaron: Or you could not register the callback if it's not there.
  leaverou: I get that, but it's up to the author using the polyfill.
            It seems they're using it regardless of if there is an
  ojan: You're saying there's author interest for parsing. We don't
        need more than that, we're off topic.
  leaverou: The new CSSOM as well.

  leaverou: I was asking TabAtkins, but it would be useful to be
            able to say what would this value resolve on this
            element. In my conic gradient we were trying to resolve
            to that.
  TabAtkins: This is related to if we want to only output computed
             values, you can say please tell me what I need to get
  shane: Sounds like it would end up in the CSSOM.
  Rossen: Anything else to surface as user impacted feature.
  leaverou: Custom paint would be useful too. Those would be my top
            three picks.

  franremy: From my point of view, given other preferences for
            custom layout and paint, it makes sense to prioritize
            animation on custom properties. You don't get very far
            without it.
  franremy: One other thing I don't see expressed here is I have
            this feeling we should have something on the matrix
            where you can get when the value of property changes and
            you can do what you need to on the matrix to set other
            custom properties.
  franremy: I think it would be interesting to have a way to say I
            want to listen to elements that set these events and I
            want to listen them so I can set properties. The apply
            chain isn't in the matrix.
  Rossen: Let's constrain to the board. The one thing missing is the
          CSS input extensions.
  rbyers: I forget what we decided. I've been lumping that into
          scrolling and async.
  franremy: I advise toward custom layout.

  <TabAtkins> When we did this sort of "prioritization" thing in the
              CSSWG, we did it by email, so people had time to think
              about things, and we compiled it afterwards and
              discussed the results.
  <TabAtkins> I'm unsure how valuable off-the-cuff results will be.
  <TabAtkins> Particularly since processing the results and
              weighting/whatever won't be done live.

  dauwhe: Probably the things that interest us are the font metrics,
          custom layout, and the box tree is a foundation for the
          fragmentation issues.
  Florian: I'd double down on that.
  plinss: Plus some of these are specs that others would depend on.
  Florian: To be able to use that we need the OM and the sync thing.
           It's not that I don't want it, we'll get it anyway.
  dauwhe: Some of them are infrastructure.

  plinss: I'm good with what's there.

  ChrisLilley: I put a slightly high priority on the spec I'm
               co-editing :)
  Rossen: Do you want to be counted as a user?
  ChrisLilley: no.

  astearns: I could do Adobe as a user. CSSOM, font metrics. I think
            franremy's point we might want to spend time on.
  Rossen: As is, these are the only things we have, so let's do

  <bkardell> in terms of usefulness - there's a lot in the wild that
             is variant already https://github.com/bkardell/research

  Rossen: Let's start with SimonSapin and do per browser.
  SimonSapin: We're looking at this in terms of what is required for
              the web and we can implement in JS with this APIs.
              That's the CSS implementation that we're sharing with
              other browsers. So custom layout.
  SimonSapin: Maybe the parser, I'm not sure.
  SimonSapin: I guess the properties and values.
  Rossen: This is from Servo?
  SimonSapin: Yeah.

  dbaron: I guess my take is the highest is custom layout and custom
          paint and what they depend on which is properties and
          value and the custom context. I don't know how much of the
          box tree it depends on.
  Rossen: We can layout without the box tree?
  plinss: You can do very restricted layout. Ideally you want access
          so you can look at bits of the tree.
  dbaron: heycam does that make sense?
  heycam: Also properties and value independently from being a
          pre-requisite, but to start building the usefulness. I
          don't know what the parser API is meant to do, but I might
          be interested.

  shane: As a side note, a lot of us have trouble knowing about the
         parser because we don't have a proposal. I'd like to
         encourage anyone with any interest to make progress in
         terms of concrete proposals.
  shane: I'd personally like to see use cases and example content.

  heycam: In terms of usefulness, but I don't want to vote for...
  Rossen: I want to make sure we're ranking in the right mindset.
          It's what are we spending out time on, not so much what's
          interesting. If you go and sign up 5 new developers to
          work on something, this is your vote.
  heycam: Then I will leave it at that.

  ojan: I'm not sure we at Google have consensus. We have things
        that are important enough that we're spending cycles on it.
        Custom Paint we clearly think is valuable.
  ojan: Custom layout is important but we're concerned is harder for
        the edge cases.
  ojan: Let me go through and other Google peeps can say if I'm
  ojan: Scrolling we hear a lot of demand for.
  rbyers: For this group what we want to focus on our work is
          dependent on async style.
  ojan: I was going to put async style on that list..
  ojan: The rendering pipeline we're in practice working on. And
        CSSOM 2.0 we want to see move forward.
  ojan: And of course the dependencies which are properties and
        values, custom context, and it's not clear to me box tree
        yet because there's no spec.
  rbyers: Maybe the data point is what are we writing code for or
          close to.
  rbyers: Async style, custom paint, we're writing for scroll but
          I'd keep that off the list, custom context.
  shane: We are actively working on rendering.
  shane: It's hard to make implementation request on custom layout.
         The other things are starting to look like we can start to
         load them.
  ojan: In terms of implementation we are actively working an async
        style and shortly after this F2F we're working on custom
        paint, CSSOM 2.0, and properties and values and custom
        context. We actively plan to write code and landing it on
        trunk for those things behind a flag.
  rbyers: You could tick scroll customization. If you want to tick
          what we're working on. But I'm blocking it until we get
          consensus on async.

  smfr: Custom paint is the low hanging fruit.
  smfr: That depends on properties and values to some extent and
        custom contexts.
  dino: I'd like to add CSSOM 2. Independent of all the other specs
        that is something that would make the web better today. I
        would comment that this is what the users would get benefit
        from fastest. I also prefer doing incremental advances and
        what's what scares me about custom layout. It's this huge
  dino: That custom layout relies on everything else is terrifying
        and goes back to our fear that it's giving users another
        place to run script that will damage.
  rbyers: I want to echo what you said about incrementalism. There's
          a nice pipeline here that we can give users benefit
          quickly and things that will take longer and we can work
          on at the same time.
  dino: I think custom paint will give a dramatic improvement from
        what people are doing.

  Florian: I'm not sure it's that I want box tree because it's a
           dependent of custom layout, but because the box tree
           gives me more powers.

  Rossen: I would go with CSSOM. I'm happy dino went first because
          he said what I wanted to about shipping small things that
          help developers do a better job.
  Rossen: The next would be properties & values.
  Rossen: I would say custom paint.
  gregwhitworth: I want the parser. I know I'm the only one, but I
                 would love to have it. You don't have to tick it,
                 but I would love to see progress.
  Rossen: I think that would be it.

  zcorpan: I've been away from work, so I'm not entirely sure what
           our team is ready to start on. I'm not sure if brucel has
           more insights.
  brucel: I don't implement.

  Rossen: I'd add the rendering pipeline.
  brucel: I'd say the rendering pipeline for authors.
  zcorpan: I'll abstain or I could put some random ticks, but that's
           not helpful.

  rbyers: bkardell, can you come up with a list from a developer
  bkardell: They're all super sexy. The parser is potentially really
            valuable. It's mostly down there, the things we need to
            expose. It's also the kind of thing standards bodies are
            really good at. We have a high potential for success.
  bkardell: I think the box tree is really...I don't know it would
            give people the immediate value but it's involved in so
            much that investing the time is important. The rendering
            pipeline and CSSOM 2 are both good. I like the custom
            layout thing as well.
  bkardell: The rest are kind of equal to me.
  bkardell: I think font metrics is hard and over my head. I think
            it's valuable, but I don't feel qualified to speak on it.

  gregwhitworth: Do you have any interest in working on the parser?
  bkardell: I'd like to, but not alone.
  gregwhitworth: Can I jump on as an editor or I can help write it
                 or whatever needs to happen to make the parser
  shane: One reason implementors don't have interest is we don't
         know what it is.

  ojan: All the authors are saying they want this thing, I think we
        don't have a representative groups.
  gregwhitworth: The people that the Houdini specs are geared toward
                 have the desire. We constantly say we're gearing
                 toward library frameworks. We should get more
                 opinions, I agree, but these are valuable.
  ojan: If you think we shouldn't talk about this, it's fine, I'm
        curious from the implementors in the room, what you see the
        risks are that would make you not want to ship. I want to
        surface the bigger problem early. I'm not asking for you to
        commit that if we did this you'll ship, I want a sense of
        the important problems.
  shane: I would like that discussion.

Implementation Interest

  Rossen: Are we done with the priority conversation?
  dino: Yeah, I just wanted to hear from other implementors and
  Rossen: I think we should have that conversation. There was one
          more column we designated which was specing interest.
          Where people will put their time to spec and model and
          figure out where they should be. It's worth getting that
          data point.
  ojan: So I suggest we go down by the spec and ask if someone is
        interested in working on it before TPAC?
  Rossen: A show of hands is good.
  shane: This is people committing cycles to work on this before
         TPAC, which is end of October.

  Rossen: [goes through specs]

  Rossen: Okay, I think we captured the data. How we'll use it, I
          don't know.
  astearns: On the work between now and TPAC, I encourage people to
           check things is and file issues on github.
  Rossen: I second that.

  Florian: I find it interesting that font metrics has user interest
           and not implementor interest.
  Rossen: Shorthands doesn't have anything on it and scroll has very
  Rossen: Box tree looks like it won't move
  Florian: I'm interested in having it move.
  Rossen: You are an editor.
  Florian: Okay, I thought that was a separate spec.

Implementor Concerns

  Rossen: We can go back to the discussion for more interest on the
          implementor side. We can do small groups and come back,
          break, or adjourn.
  ojan: I'd like a summary from each implementor about their
  Rossen: Let's go around the room. SimonSapin want to start for

  SimonSapin: The main one is to avoid specing something that
              prevents parallel layout or parallel-everything. For
              rendering pipeline that we've seen earlier today I
              think other people on my team will have something else
              to say. I don't think we have resources to implement
              any of this in the short term, unfortunately.
  Rossen: So resource bound.

  dbaron: I share SimonSapin's concern, but another is a general
          concern about how much...we're moving into an area where
          we are going to be exposing things where engines might
          differ today and the question is how much do we want to
          force everybody to do the same thing and how much do we
          want to allow those differences to stay and what the cost
          of unification is to the value we get from it.
  dbaron: Do we want to spec to require us to do something that will
          take us a year to change our architecture or not depending
          on the value? There are some things that I think we'll
          want to do, but thing like custom layout where everyone
          moving to the same would be prohibitive so we want to make
          sure we do something that accommodates everyone.

  ojan: For the most part we're gung ho about custom paint and
        layout. I have a personal concern about we'll see what
        happens when we try and implement them. The thing we're most
        hesitant about is the parser. We'd be hesitant about a
        generic browser that isn't what the browser actually does.
  rbyers: We'd concerned about performance too. If we build it and
          it's full of performance footguns, we might not want it.
  smfr: CSSOM has this promise of faster performance and no obvious
        downsides. Custom paint is like multiples canvas so that can
        be without obvious performance. The scarier things are like
        custom layout and box tree and async style.
  ojan: What I've heard is you have the concern about letting script
        slow down. Are there other concerns?
  smfr: I share some about blocking browsers into certain
        implementations. I think it's good to standardize in places
        like rendering. Font metrics is up in the air because we
        still don't have a good model. We could expose this and
        developers write bad code. I have concerns about the spin up
        costs of custom context and what will happen if you have
        many running.

  gregwhitworth: I think my major concern is the performance.
                 Especially the context switching and being able to
                 spin up multiples. Also the complexity. And getting
                 to the author endpoint, the ergonomics looks
                 disgusting. I know we want libraries to take it,
                 but it looks horrible. We have web components
                 hitting JS and with all we have going on it will be
                 heavy weighted.

  Rossen: From an implementor PoV I resonate with dbaron and
          SimonSapin where we're trying to lock down to what seems
          to be high level, but historically this has been a
          playground where we've been able to differentiate.
          Preventing any of those will prevent implementation from
          one browser or another. For example our box tree is
          completely different. That will be a major advantage or
          disadvantage for us.
  Rossen: So custom layout is another huge worry. I mentioned it in
          Sydney, but we have bitter experience with allowing
          extensibility on grid layout. Even though we're doing it
          through script layout, people were messing up fairly rigid
  Rossen: The other scary thing is all the scroll manipulation.
          We're optimizing and integrating heavily for scrolls so
          they can be offhanded to the lower level compositor and
          they're even lower level for us. Same thing goes for
          rendering. A lot is broken into different places and we
          want them independent and they don't have access to
          anything. It's a render only thread.
  Rossen: I'm sympathetic to custom paint, I'm also scared for it
          because it's sync point and that kills performance.
  dino: And you made those decisions because you want the user
        experience to be awesome and now you're handing that power
        to the devs at the expense of users.
  Rossen: Exactly.
  Rossen: Script isolation and all the partition, I'm also concerned
          about how that will work. The last thing that is more or
          less about the dynamics of the efforts. We're starting to
          build a lot of expectation and I'm not sure we're going to
          follow-up in any reasonable time line.

  astearns: To that point, one of my concerns is that some immediate
            incremental improvement might be at risk because there
            is a future framework in which they fit better. So
            there's all sorts of scripts that do a lot of
            contortions to figure out the first dominant baseline.
            It would be useful to give them that. I agree it's more
            useful in this Houdini pipeline. I don't want to push
            for the perfect place when there's a small incremental
  Rossen: We will be bringing ideas back to CSS that can be
          specified in CSS. What you're suggesting is a perfectly
          good API that we can write here and have it go through the
          CSS working group. Things don't have to be only worked on
          here. The more things we can bring back that are easily
          doable and beneficial the better.

  bkardell: I definitely hear everybody's concerns and I have the
            same as a non-implementor. I wanted to take one second
            to point out recently TabAtkins was on a podcast and he
            articulated this well. One of the real benefits of doing
            this hard work is the CSS working group is kind of in an
            unsustainable place of too much work, too few people,
            too many implementors. The more powers we can give to
            authors potentially it alleviates work in the working
            group and pressure on the implementors and that's
            another factor to keep in mind.
  <bkardell> *also the less likelihood that we will get it wrong :)
  zcorpan: If we start exposing the internal model of the browser it
           makes it harder for us to get interoperability on the
           internal model because changing it means breaking sites
           or having to maintain your legacy that you exposed to
           scripts when changing your internal model.

  Rossen: Is that satisfying?
  ojan: It was helpful to me.
  Rossen: I think it is powerful and useful because we're all
          upfront about the elephants in the room.
  ojan: I agree with almost everything everyone said...they are
        potential risks and we'll know as we build.

  franremy: About freezing the internal model, we could always take
            some liberties and be close to the model. I don't think
            web authors need to know everything about how the
            browser works. We can always mitigate it with
  Rossen: Okay, thank you.

  rbyers: To reply to dino's point, we have these concerns about
          we've optimized to the best user experience. I don't think
          any of us are trying to create an awesome experience for
          developers, we want to have one for users. It's a trade
          off between the users of today's web vs tomorrow.
  dino: What I said is a political stump statement. It was never
        intended to suggest that other people don't care about users
        or that providing features to devs won't help users in the
        long term.

  Rossen: That takes us to the end of the agenda. We can at this
          point adjourn and reconvene during TPAC. A huge thank you
          to Mozilla for hosting us. Huge huge thumbs up everything
          has been fantastic.
  <bkardell> yay mozilla, the video was really nice too.
  Rossen: Thank you and see you at TPAC.
Received on Friday, 16 October 2015 23:46:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:25 UTC