- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Mar 2015 14:19:18 -0500
- To: public-houdini@w3.org
Houdini-Related Presentations
-----------------------------
- ChrisL brought the work he and astearns had been doing on drop
caps and drop initials up as a good potential test case
since it was difficult to standardize on.
- glazou presented the need for more abilities for editors to
access CSS so that they can preserve information not
understood by the parser and to standardize parsing values.
- glazou also presented the complexities in creating polyfills and
how granting access to the box tree and the ability to
create new boxes will significantly improve the ability to
use polyfills.
- Considering the extensibility problem with a pipeline approach
was presented by iank, involving extending custom properties
as well as extending selectors, functions, @ rules.
===== FULL MINUTES BELOW ======
Houdini-Related Presentations
=============================
Scribe: shane
Rossen: Who would like to present something?
ChrisL: Me, for about 10 minutes
glazou: me, for about 15 minutes
Rossen: We have a couple presentations
<bkardell> TabAtkins, you should present the alias spec and I have
the Hitch pollyfillish thing if you wanted to show it
iank: me, for about 20-30 minutes
Dropcaps Presentation - ChrisL
------------------------------
Scribe: gregwhitworth
ChrisL: We recently did work around dropcaps and drop initials.
ChrisL: We've got these lines coming out of layout, and numbers
from font metrics. We then do an equation on them.
ChrisL: We should be able to polyfill these, this would be a good
test case for this as it was hard to standardize on.
ChrisL: You can ask the DOM for example, which fonts are on the
DOM. It will give you a list, but it's your guess.
astearns: We had to do some hacks to get this information.
astearns: 1. What font is actually being used to display the text?
astearns: 2. Font metrics from that font, ascent, decent...
astearns: 3. Where the browser is drawing the dominant baseline?
astearns: Those are the three bits we needed.
astearns: That will be beneficial for all types of typographic
things.
ChrisL: You may want a list of glyphs and those fonts.
astearns: It may make sense for a more simple API, you could make
it so that you can dig into the API for more complex
situations.
astearns: My thought is that you would ask the API for a certain
range.
ChrisL: I'm thinking of mainly the first cap scenario.
astearns: In terms of small initial steps, we can come up with a
font-metric API that does very little to begin with.
astearns: Maybe just giving the dominant baseline position,
astearns: Then we could come back with things that we find more
useful.
astearns: We maybe won't get to ascent, and decent if it's not
needed.
rossen: What do you mean by dominant baseline?
rossen: You have the range, and then based on the font metrics you
can determine the baseline.
rossen: When you have a complex scenario with different fonts, I'm
finding it hard to make this a simple API.
SteveZ: You know what line you're applying the glyphs to
ultimately.
SteveZ: For example, if you have multiple characters and they're
not evenly spaced, that's why we need to ask layout.
Roc: It sounds like you're wanting to expose the linebox, which
sounds like you want to expose the box tree ultimately.
Roc: Is that accurate?
Roc: Gecko actually has a private API for the developer tools to
expose the font used.
Roc: You actually need to be able to do layout based on any
changes done.
Roc: I have two concerns.
Roc: We need two APIs for triggering layout.
Roc: And it needs to be able to do multiple iterations of layout
since you'll be moving things.
astearns: I kept it very simple, it doesn't respond to layout, it
assumes evenly spaced.
johanneswilm: I understand your worry, but web devs will only use
this when necessary.
shane: I was going to say something similar.
shane: This will allow authors to have that control instead of us
making the decision for them.
ChrisL: The main set of people using this will be framework
developers.
TabAtkins: This is a good functionality that should exist.
shane: We see this in animation libraries as well.
* hober cautions against designing API intended for framework/
library use & not use by actual humans
<bkardell> drop caps work by adobe is expressed in css or through
a lower level api only?
ChrisL: We started off very simple, and this got very complicated.
dino: What do we do now?
rossen: Good question, let me reiterate the point of these.
rossen: These presentations help us see the use cases for us to
going and start chewing on for the road map on technical
discussions.
rossen: A simple scenario produced 30 minutes of technical
hurdles, but this will help us define the purpose of
Houdini.
glazou: These presentations are very important as these provide us
with adequate use cases we need to design.
glazou: It also allows us to define priorities.
dino: Who is keeping track of these ideas?
shane: Rossen and I.
rossen: This list should be done by the end of the CSSWG meeting.
<astearns> bkardell: the drop caps work we did uses canvas hacks
to approximate the data needed in some improvement to
the APIs
<shane> astearns: is the source code publicly available?
<astearns> shane: https://github.com/adobe-webplatform/dropcap.js
<shane> astearns: thanks!
<bkardell> astearns: so no parsing, but if you could have it sure
would have been nice
<astearns> bkardell: agreed
Needs for Editing - glazou
---------------------------
glazou: Let me start with editing.
glazou: These are problems that we started working on 15 years ago.
glazou: There are properties supported by some browsers and not by
others.
glazou: What I mean by that is that for some browsers this info is
stored by the CSSOM and not by others.
glazou: We really need a way to preserve all of the properties and
their values, even if they aren't understood by the parser.
glazou: The second most important thing.
glazou: It's everywhere in my code, parsing values.
glazou: Parsing 15px is trivial, but linear-gradient and animation
values are complex.
glazou: We don't have an object model for that.
glazou: Everything in a stylesheet should parse-able from script
at any time to retrieve an internal representation of it.
<bkardell> glazou: Also extra download / cross origin worries are
addressed by this
rossen: To repeat my question, do you envision this as an object
that is exposed through JS (similar to supports)?
rossen: Just for my mental model CSS.parser?
glazou: Yes, something like that.
glazou: Example: The selector is modified and you need to parse
the selector and reconstruct it and apply it.
glazou: This is very complex for editors that recreating this in
JS.
glazou: It would be faster and interoperable and work for everyone.
glazou: We're basically re-implementing something that the browser
already knows and can do.
<bkardell> If it could normalize the url value or have a way to
that would be super nice too.
glazou: Another thing that we need,
glazou: Being able to synchronize the changes from the CSSOM and
the layout effects.
glazou: I want to change multiple properties and not change layout
until I tell it to.
rossen: This is not a new problem, it's a transactional layout.
Roc: Do you want just visual effects, or layout changes?
Roc: We don't change anything until the layout is finished.
glazou: Just the visual effects, which is what the user sees.
glazou: You want to setup a layout for your application, sometimes
a partial set of these properties will create a mess on
the page and user will be lost.
glazou: When you set a fixed position, the object could be outside
of the viewport.
glazou: I want to be able to say css.stopFlushing, etc.
roc: I'm trying to understand what you want to happen instead.
rossen: Let me try to reinterpret this, is it more transactional
or batching?
glazou: I think it's batching
<TabAtkins> CSS.styleTransaction(function(){...}) // function is
called sync, it's just used as an automatic open/close
mechanism
bkardell: Could the transaction be throttled?
<bkardell> So if you don't flush, after a certain time it would
auto flush anyway.
rossen: This is getting more into the implementation, we want to
keep them more in the inspirational/use-case.
<bkardell> This kind came up at the breakout session at edgeconf
too.
<bkardell> Was anyone in the room there?
<bkardell> There were good ideas.
SteveZ: I don't understand your difference between transaction and
batching.
rossen: Transaction allows for multiple property changes.
glazou: I'm resorting to javascript to fix the holes.
glazou: All the editors are doing this.
Polyfills - glazou
------------------
glazou: The second issue is regarding polyfills.
glazou: Writing a polyfill is about two things.
glazou: First, extending the parser.
glazou: Inject an extension with appropriate selector grammar.
glazou: Pseudo element is very complicated as it is related to
layout.
glazou: You need to be able to inject something.
glazou: It's a chicken or egg issue, how do you inject them so
that layout sees them, etc?
glazou: If you're creating a new property, you want to see the old
CSSOM as well as the new ones you've created. Only the
polyfill knows.
glazou: So you need a polyfill for both execution and
serialization.
glazou: Access to the box tree, creating new boxes, etc. is what
you need to do correct polyfills.
<bkardell> It's not unlike custom elements - very similar.
rossen: So if you were to consider this, what API would you extend
to make this work?
glazou: Extend the list of pseudo classes so that it's a tool and
provide it to JS.
glazou: Show that we care about extending the browser, and
continue to iterate on it
glazou: I don't think we can fix or even think of everything to
fix from the beginning, it needs to evolve.
glazou: We've received requests from SASS and other library
authors, so we need to give them the hooks they need.
bkardell: I don't disagree with how you prioritize them.
bkardell: The parser is important to everyone that wants to
polyfill anything,
bkardell: And there are some lower level things that will help.
bkardell: The parser is important to anything that wants to
polyfill at the language level
<bkardell> But not necessarily at the functional level,
<bkardell> That is my point.
<bkardell> They can be taken up in parallel, related but separate.
rossen: In summary, we can work on scoping its behavior and its
needs.
glazou: We have many live examples on the web for this, and help
guide us.
<bkardell> The newer hitch for example treats the language level
as a preprocessor thing and that's still better
The Render Pipeline - iank
---------------------------
Scribe: shans
<iank> http://dev.w3.org/csswg/css-extensions/
<iank> https://wiki.css-houdini.org/explaining-css-layout
iank: We put some stuff up on the wiki ^
iank: There's also a talk I did at BlinkOn in November which goes
through some of the same stuff. Can link if people are
interested.
<bkardell> Please do link.
iank: We've been thinking about this extensibility problem as a
pipeline approach.
iank: The first stage in this is custom properties.
iank: Example in strawperson - simple API that lets you register a
property with a function that defines its effect.
iank: Not wedded to this but we should let people define
functional properties.
iank: TabAtkins has a document with other ways to extend the style
engine too,
iank: In this there's ways to extend selectors, functions,
@ rules, TabAtkins might want to talk in more detail.
iank: So that's the style level. The next part, which we've
touched on, is exposing things like the box tree and a
measurement API.
iank: One thing that potentially could be useful e.g. to polyfill
flexbox is being able to query boxes min/max content
contributions,
iank: Working out intrinsic width/height/aspect ratio of images.
iank: There's lots of detailed sizing data in the engine that you
can only get via osmosis, or not at all.
iank: Also, what roc was alluding to earlier today - how would we
do a full layout API?
<glazou> Just for the record, the first time I suggested making
CSS extensible was 17 years ago.
astearns: One tiny detail on custom properties and extending
parsing syntax.
astearns: Francois mentioned on the mailing list that it's much
more difficult for an author to add a new value to an
existing property than to add a new property.
astearns: Is this something we should solve?
astearns: Or just rely on custom properties?
astearns: e.g. having my-display: grid might be sufficient to
polyfill a grid.
<bkardell> 1 fallback seems sufficient to me.
<bkardell> We just have to define the right order.
Rossen: Regarding layout and layout extensibility. Our
extensibility model is based on COM. The Browser Helper
Objects (BHO) used to have something called layout
behaviors. It was IE extensibility since IE4.
Rossen: We killed it as soon as we could because we found out that
people are fairly bad at writing and extending layout.
Rossen: In our case, the thing that was the highest motivator was
that we made it synchronous rather than asynchronous. We
should avoid that.
Rossen: Synchronous layout extensibility on the main thread will
kill scenarios very quickly.
<bkardell> Rossen: I think what glazou was talking about that
helps.
roc: That seems weird to me. If you look at what Ian's written
(which I agree with) you do want custom layout to behave like
existing layout. You want custom layout to complete at the
same time as the built-in stuff otherwise it's not a real
polyfill. So it has to be synchronous.
roc: In all our browsers, even servo, layout and JS run on the
same thread.
roc: So synchronous behavior doesn't make things more janky,
<bkardell> there are opportunities to offthread and rejoin I think.
iank: Internally, we came to the conclusion that you need
something running in the middle of layout computation,
whether defined up-front with an EDSL or in JS.
iank: We were also toying with ideas like that the JS was in an
isolated world (e.g. a worker).
iank: We might be able to have better guarantees about the DOM.
Lots of tech discussions that we could possibly go into this
afternoon.
Rossen: Yes.
Rossen: I agree with the spirit of this. When we start discussing
technical details we'll figure out how this can work. I
believe we can still make things looser from a dependency
point of view.
Rossen: In some of the recent things we've been playing with we've
been successful in detaching and running object model,
layout and rendering (been parallel for 1 release already).
Rossen: So we don't block script or layout for rendering. Trying
to do the same thing for layout. So far things look pretty
good.
Rossen: As mentioned before the spirit here is that we don't want
to disable the ability to do things in the platform just
so we can expose things that script can use,
Rossen: But fundamentally want to be able to do something like
this (???)
iank: One other thing with layout - may not expose full range of
CSS layout within custom layout. e.g. might not have the
ability to deal with things like floats.
dino: Can you give examples of what you mean by custom layout?
<bkardell> GSS
<TabAtkins> http://gridstylesheets.org/
<bkardell> thanks tab
iank: Two or three years ago we were speccing flexbox. Authors
have wanted this for quite a while. Being able to do this in
user land is extremely powerful (and things like grid too).
iank: Another one - if we ever wanted to do a layout that is
constraint based (like grid stylesheets)-
iank: How can we do that in user land?
iank: I really like relative layout from android. How could we do
this in user land?
dino: All the examples you gave are not really doing custom layout
in the same way as the web is. I have concerns about this
being performant.
dino: It's not JS performance per se that is going to be the
problem, it's just that layout is tricky.
TabAtkins: We have some approaches that we think might work to
make this performant, and we want to discuss in the
group to make sure that the ideas could be used across
browsers rather than just something that might work for
us.
iank: I've written lots of custom layouts. How they work is
horrific.
iank: Often I need to do things like collapse, do a DOM measure,
inflate, do another measure.
glazou: At the moment the situation is far worse than _any_ API we
can come up with.
glazou: Anything we can provide will make the situation orders of
magnitude better. Even if we think there's a performance
issue it's a huge win for authors.
dino: I agree with that, but there's a bigger set of users we need
to worry about.
dino: They are the users. We've put a lot of effort into things
like smooth scrolling - users don't care about custom
layouts so much, they want their page to be fast.
dino: My general point is that developers obviously want this
power and what they have now is terrible, but my fear is
about making things worse.
shane: Yes, but whether users care about custom layouts, authors
are doing them. There's thousands out there. The techniques
that are used have a performance impact across the
platform, including scrolling. So we'll actually be making
things better.
<bkardell> dino: If people do it today, authors are taking
responsibility for their custom stuff... making it
extensible is not different, is it really? not asking
to add gss to the platform
<bkardell> They have the power, that's the point.
glazou: I hear both of you, but I think we shouldn't confuse
author's responsibilities and vendors responsibilities.
This goes far beyond technical side and into marketing,
communications, etc.
glazou: But it's always the author's responsibility if they use a
technique that slows the website down. There's nothing we
can do about that. There are zillions of ways you can make
your website suck.
glazou: I know this will impact the public image of your browser.
But if we take that into account then we're not going to
make progress.
glazou: Right now it's the author's responsibility if a site is
slow or if it sucks. That isn't going to change because we
add more APIs.
<bkardell> Don't discount the possibility that the killer new
feature comes in through this route as a cowpath
johanneswilm: Again, just thinking about performance limits web
apps to being really simple if you don't want them
to be slow on old computers.
johanneswilm: We're not stopping this now. People are doing this,
despite the tricks they need to use. Things can't
get slower if these tools are made available so we
don't need to jump through loopholes.
dino: I guess I'm not against the idea of custom layout,
especially Ian's example (the springy thing - measuring text
offline before animating to the right position).
dino: I think that's a bit different from implementing the CSS
Grid model.
iank: You need to be able to do it inline in that example though.
You need full participation of layout. So it's not that
different.
iank: I've mainly talked about box layout, not text layout. But we
should also think about text layout.
bkardell: You should be able to organize things so you can
shortcut and go through the native pathway if there's
nothing custom, right?
bkardell: So hopefully this will have no net effect on sites that
don't use this.
iank: Yes.
iank: So layout is hard.
iank: Then there's the painting aspect - the final layer of the
pipeline.
iank: If people want e.g. screws on border corners, or something
crazy, they should be able to paint that directly on the
element if they want.
iank: e.g. in the past, border radius. When I was first starting
out you needed to use a table to get these.
iank: We should enable these types of use case too.
iank: Is painting a worthwhile problem?
dino: I've wanted this forever.
iank: It needs some thought - e.g. drawing outside of bounds for
things like box shadow, drawing in content layer.
roc: Do you want static content or animating content?
iank: We'd want to do it on invalidation.
roc: Can you give an example?
iank: Example: if you have a my-border-radius and you animate that
property, then the paint will animate.
roc: But if a property isn't changing, then the display is static?
iank: Right.
Rossen: One of the things I wanted to mention here is that as we
think about extending layout and the parser and all these
things, it would be good if we approached this from the
perspective of something that we can do right now versus a
pipe dream.
<bkardell> It makes sense to keep trying to spell out a whole
system even if pieces never get implemented or we need
big "here be dragons" handwaving
Rossen: So one concrete example: Ian and Dean both mentioned that
content measure is something we all have internally. We
should be able to expose this on top of the current DOM
today without going into super-crazy philosophical
discussions.
Rossen: (of how to implement a spiral layout)
Rossen: Ultimately I think we'll strike a balance in the middle.
glazou: Another thing that we need is CSS value. We need to be
able to parse *any* value. Concretely: there was a
polyfill for linear gradients. It's a function of
arguments separated by commas. Each argument is pretty
complex. We have no way of representing something like
that if it's not already in the browser.
glazou: In the OM right now, CSS Value completely sucks. Nobody
uses it. We should get rid of it,
glazou: Or have a new name for a new CSS Value, and get it right
this time.
glazou: Current one is useless and unused. Let's do it right.
SimonSapin: What if we had the ability from JS to pass things from
any production rules. e.g. in the spec we have a thing
that is either a linear gradient or radial gradient.
What if we could pass just the color stop list.
glazou: Yes. *all* the values we have in CSS. Including the
infamous URL.
glazou: It's pretty simple language, actually. Should be able to
achieve a representation of this in no time.
dino: Question for Rossen. Were you suggesting we should
prioritize the things we can do right now, or that we all
know what those things are and should just do them?
dino: And what do you mean by 'right now'?
dino: e.g. we could probably all see a way to do painting right
now.
Rossen: I didn't mean to suggest priority in terms of what we
should spec or do.
Rossen: I think it would be easier to start working on speccing
and implementing things we can do right now.
Rossen: But I wouldn't push for implementing them *right now*
iank: I think I've opened up enough rats nests for now.
<bkardell> Some things themselves can be specced and pollyfilled...
a proposal for a replacement for CSSValue for example
SteveZ: roc mentioned in passing, I'd like to ask for an explicit
CSS Line Box interface, so you can ask how many lines a
laid out thing has, and for each line ask for the dominant
baseline and extent above and below.
SteveZ: A read only interface. That would help with a lot of the
things that we're doing.
Rossen: I think that ties in with the whole describing of the box
tree.
Rossen: We definitely should do this.
SteveZ: It needn't be a text box. You can have a line that
consists entirely of images.
Rossen: line box.
<johanneswilm> +1 for line box exposing!
* bkardell claps
<br dur=70m>
Received on Tuesday, 3 March 2015 19:19:46 UTC