- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:45:03 -0400
- 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.
===== FULL MINUTES BELOW ======
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
Specs/Proposals:
Box Tree API
Async Style
Custom Layout
Custom Paint
Parser
Properties and Values
Scroll
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
parsing...
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
spec?
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
interest.
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
supported.
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
implementation.
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
pixels.
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
these.
<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
wrong.
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
unknown.
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
prospective?
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
happen?
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
users.
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
little.
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
concerns.
Rossen: Let's go around the room. SimonSapin want to start for
Servo?
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
algorithms.
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
thing.
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
requirements.
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