- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Mar 2015 14:21:53 -0500
- To: public-houdini@w3.org
Scope and Proposed Charter
--------------------------
- RESOLVED: Accept proposed list of topics as scope and charter of
Houdini
- Topics are:
- Query interfaces
- Box Tree
- Font Metrics
- CSS Event model
- CSSOM
- Modification interfaces
- CSS Parsing
- Property and Value Extensions
- Selector Extensions
- Cascade and Inheritance Extensions
- Input Extensions (scrolling, pointers etc.)
- Layout Extensions (r/w extensions to the box tree)
- Paint Extensions
- shans and Rossen will write the charter and post it to the wiki.
Box Tree Spec
-------------
- RESOLVED: Create a new document - box tree spec - with editors
TabAtkins, iank, Rossen, plinss, shans
- The CSS specs should be the place where the creation of boxes is
defined fully, but some of that may need to initially go
into the box tree spec until the originating specs are all
changed.
- The group leaned toward having the API return the results from
the last animation frame with some kind of marker for
relative order.
- There will need to be a way to limit what is exposed to keep
from giving either too much information or an overwhelming
amount of information.
- The API should expose the nature of the element, such as it's a
flexbox.
- There were arguments for both exposing everything in the API and
writing iterators for the users. Use cases are needed to
come to a concrete decision. TabAtkins has an idea for the
iterators approach that he'll test once there are use cases.
- It was agreed that sizing and geometry information will need to
be exposed.
- The box tree API will either need to be extensible so SVG can
extend it, or be mapped to HTML.
- Mostly people leaned toward exposing both physical and logical
measurements, though there were good arguments for just one
or the other as well. No matter the end choice, it was
agreed that the explanations and property names will need to
be kept clear.
- The next step is for the editors to write some spec text so that
there is a set of proposals on the table to further the
conversation.
===== FULL MINUTES BELOW ======
Scope and Proposed Charter
--------------------------
Scribe: rbyers
shans: This is our attempt to rationalize various topics discussed
today.
Rossen: We want to agree on a charter, and then on a proposed a
list of agenda items we can work on more actively. Items:
<Rossen> Query interfaces
<Rossen> Box Tree
<Rossen> Font Metrics
<Rossen> CSS Event model
<Rossen> CSSOM?
<Rossen> Modification interfaces
<Rossen> CSS Parsing
<Rossen> Property and Value Extensions
<Rossen> Selector Extensions
<Rossen> Cascade and Inheritance Extensions
<Rossen> Input Extensions (scrolling, pointers etc.)
<Rossen> Layout Extensions (r/w extensions to the box tree)
<Rossen> Paint Extensions
glazou: No-one in the world would say the CSSOM was well designed -
we should improve it
ChrisL: By box tree you mean box and fragment tree, right?
shans: Yes.
glazou: Also a media query extensions?
shans: Yes, we'll add it.
shans: This is the proposed scope - and this should become the
charter.
dbaron: Modification includes what you need to do new properties?
Rossen: Property and value extensions should cover that.
glazou: What are property / value extensions?
Rossen: What the areas we want to be read-only, what will be read-
write?
Rossen: Read-only: box, fox, events, and object model.
rbyers: What are the other input extensions?
Rossen: Basically what's involved around scrolling,
Rossen: That I'm initiating scroll.
rbyers: Is it fair to say it's scoped to scrolling?
Rossen: Scrolling is why we put it here.
Rossen: I don't see a need for more, but we might want to extend
it.
vollick: Does it include extending compositor driven scrolling?
shans: Don't see why it's out of scope.
vollick: The threading question...
shans: Scrolling is interesting - half in and half out of CSS.
Rossen: But we shouldn't say no just because of that.
Rossen: Houdini TF is joint between CSS and TAG,
Rossen: and TAG covers everything.
Rossen: So I wouldn't rule out threading.
<bkardell> is isolation in scope?
shans: Yes, isolation fits inside cascade and inheritance
extensions.
shans: Any other questions / alterations?
xidorn: Click on a link and jump to a target usually causes a
hashchange, but not always.
Rossen: A part of input extensions?
Rossen: We named it input because we want to keep it vague and
wide open.
Rossen: Any input that modifies CSS or other primitives we're
covering,
Rossen: So that issue should be in scope.
RESOLVED: Accept proposed list of topics as scope and charter of
Houdini
glazou: Who will write the charter and put it in the wiki?
ACTION: shans and Rossen to write charter and put it in the wiki
<RRSAgent> records action 1
Box Tree Spec
=============
Creation of Spec
----------------
shans: My suggestion is to start with box tree this afternoon.
shans: Tomorrow handle property value extensions, CSS parsing,
font metrics and input extensions.
shans: If we start with box tree, it's clear we need a box tree
spec.
shans: We should resolve to create a box tree specification as a
work item and select editors.
<dbaron> (was the initial set plinss, rossen, shans, then Tab for
everything, then Ian K?)
TabAtkins: Put me down for everything.
SteveZ: I'm interested in line layout.
shans: Does that belong in box tree spec or another spec?
SteveZ: If the box tree is the result of layout, then it should be.
shans: I'd expect editors to actively modify text.
shans: Sounds like TabAtkins IanK Rossen plinss shans
shans: Are editors of box tree spec
RESOLVED: Create a new document - box tree spec - with editors
TabAtkins, iank, Rossen, plinss, shans
Box Generation
--------------
shans: Let's work out what's in, what's out.
dbaron: Part of the problem with the box tree spec is that some of
it belongs in the main CSS specs.
astearns: The box tree spec won't say anything about what boxes
are generated from what input - that belongs in CSS specs
astearns: But it will be about the API for accessing boxes.
TabAtkins: Generating boxes will be the job of custom layout -
separate topic.
shans: And also standard layout - CSS specs.
shans: I would like to see descriptions of how boxes are generated
based on CSS properties.
shans: Maybe not as normative text, and maybe we can move to CSS
spec later,
shans: But it would like a single place that defines what a box is
and how it's generated.
shans: It doesn't have to be in the main text - informative
attached to the spec.
ChrisL: What's the point in having informative text saying how the
boxes are generated?
ChrisL: It seems like API spec describes how to get at it, but if
that turns up holes in the CSS spec then we fix the CSS
spec.
shans: Without saying what generates boxes, box spec describes how
to get something that doesn't exist.
astearns: I can imagine examples.
shans: Nailing down the behavior we expect is a big part of the
work here.
astearns: A lot of the information you're asking for is already in
the CSS specs.
astearns: If there are additional pieces needed, we should add
them into the CSS specs.
ChrisL: I'm not arguing there's not gaps,
ChrisL: I'm sure there are, but the correct place to fix those are
in the CSS spec.
SteveZ: Said another way: interoperability concern - there ought
to be a consistent box tree result for a given CSS input,
SteveZ: If there's not, the CSS spec is vague.
Rossen: We should be driving all these missing pieces back into
the CSS spec.
Rossen: Defining APIs on something that's ill defined is counter
productive.
Rossen: This is exactly what I was alluding to when I was asking
what a box is.
<franremy> (just want to point out the boxes being defined may
depend on the layout mode; do line-boxes make sense for
a grid? that's maybe why we want the spec to talk about
concrete cases even if we have to actually define them
in CSS after that)
plinss: The CSS specs have lots of examples of 'weasel wording' -
"there's a box here."
plinss: Every CSS spec that defines a layout/display property
should have a section that says: "Here are the boxes as
exposed via the box API."
plinss: Meanwhile we may need to put those in the box tree spec
temporarily.
shans: So the box tree spec should eventually be quite small.
Content of Spec - API surface
-----------------------------
Rossen: So what API surface do we want in the spec?
Rossen: For example, Rob suggested maybe there should be some
geometry in there.
TabAtkins: Some are exposed roughly by getClientRects.
TabAtkins: That gives you geometry.
TabAtkins: kwkbtr has a basic proposal on the mailing list.
<shans> (toru's proposal:
https://lists.w3.org/Archives/Public/public-houdini/2015Feb/0001.html)
SimonSapin: Is the API asynchronous?
dbaron: At what granularity?
roc: If we want to figure that out we need to take time to figure
it out. But it's orthogonal - any API will have that issue.
TabAtkins: What's the problem with returning a promise?
roc: By the time you get your promise resolved, the information
might be out of date.
roc: Does it return new information, old information?
roc: What guarantees are we making?
roc: As weak as "at some point between the call and result the
layout information was this".
shans: Having the ability to request when it's ready rather than
force synchronous layout is useful.
<dbaron> (issue was that there could be multiple promises
outstanding, and then one of them changes the dom... what
happens to the others)
TabAtkins: It should be possible to define this - resolved in
order, when resolved it reflects the state at that time.
roc: But then have you solved the problem that you wanted to with
an asynchronous API?
<franremy> getClientRects/getBoxQuads/offsetWidth are synchronous;
why go asynchronous for boxes?
dbaron: If every promise runs layout again then you haven't solved
the problem.
dbaron: It's the only reason people are thrashing layout today.
TabAtkins: Ok, we should give better affordances around that.
roc: Good question to ask - why do people thrash layout today?
roc: One I've heard is people having to modify DOM to get the
information they way.
roc: We can avoid that by giving APIs to get the information they
want without modifying the DOM.
roc: Are the other cases?
<franremy> roc: Yep, I temporarily mutate the style to get
"min-width, min-prefered-width, max-prefered-width,
max-width"; an API would be there, I wouldn't need to.
iank: Large code base, multiple teams each registering global
click event handlers,
iank: Each of which is reading layout.
iank: They can't reason globally about what everyone else is doing.
roc: But they don't need to fear - one piece won't change the
parts of another.
TabAtkins: When you don't have one code base it's hard to separate
all the reads and writes.
roc: That's a good argument for your promise-based approach.
TabAtkins: It would make it less likely for one person to
read/write back and forth.
TabAtkins: It's easier to code all your reads and writes together.
roc: One approach is to return the results from the last animation
frame.
roc: That way the information is guaranteed to be obsolete by one
RAF frame.
TabAtkins: All resolved at once with same information fed to them -
all looking at the same world.
TabAtkins: Read/writes won't interfere with each other.
dino: If you have large code base - multiple parts trying to do
something. Do you have any guarantees over the order?
roc: Order doesn't matter.
roc: Everything will work as long as callbacks doesn't modify the
DOM in ways that affect other callbacks.
roc: If they do, there's no escape from layout thrashing /
incorrect results.
shans: You already needed to know the relative order.
roc: Right.
iank: You might get frame glitches if it's a frame late.
roc: We can do it in the same frame.
TabAtkins: As long as you're in your frame budget it should be
fine.
TabAtkins: We'll know what things we need to freeze - don't need
to ship the entire world over.
dino: If you had two things you'd be OK in the layout thrashing
case - you'll get accurate results.
shans: But second one needs to know it was second.
shans: Writing values doesn't force a layout.
dino: OK, I think I've convinced myself.
shans: You need to explicitly force a layout in the second one.
shans: Forcing a layout explicitly will help teach developers
about the cost.
johanneswilm: When you look at the box tree you may change DOM /
CSS.
johanneswilm: Rather than use a promise wouldn't it be easier to
require the developer to ensure things are stable.
roc: That's how it works today, but we need to provide a way.
dino: If we're returning the results of the last RAF setup, why
are we doing asynchronous?
roc: You want to get the results at the next frame.
roc: You don't want previous frame because then you need to keep
the old layout tree around.
dino: Makes sense.
shans: So you're setting up a record of the requests - what boxes
script wants information about
shans: Just after RAF you get those results.
roc: It depends exactly when, but yes.
johanneswilm: Box tree will only work for elements that are part
of the current DOM, which means that developers will
need to stick stuff into the DOM, get the box tree,
then change the DOM again.
iank: You're getting at DOM measurement API?
johanneswilm: If you don't want us to mess up the DOM afterwards.
TabAtkins: It's not about not messing up the DOM, it's just too
easy to do things in a bad ordering.
TabAtkins: We want it to be easier to get the order right.
<franremy> Question: Could we say instead that getBoxes() caches
the result once generated for an element up to a rAF,
except if the code explicitly asks element.forceLayout()
or forces a layout by any other mean?
Rationalizing Stacking Context & Containing Blocks
--------------------------------------------------
vollick: Related to DOM and layout thrashing - are we interested
in rationalizing stacking context and containing blocks?
vollick: So you can, for example, escape z-index jail?
TabAtkins: I'm not sure if this is Houdini or CSS Positioning.
roc: You're asking for new CSS features to escape from transform,
etc.?
vollick: Yes. There's technical reasons it's very tricky.
roc: I hope this is out of scope,
shans: Either it's firmly in scope here or in CSS WG.
TabAtkins: In scope may mean "that's crazy, we won't do it".
shans: You could look at it as z-index as a CSS feature.
shans: Or that z-index controls a primitive 'stacking order'
dbaron: Not just stacking order but whole painting model.
roc: Let's not do that here.
dbaron: I think it's in scope for CSS.
roc: None of what we have here tries to change the way CSS paints
stuff.
roc: We've got enough to do.
plinss: That doesn't mean we can't come back to it.
plinss: We talked about this with scrolling - think about it terms
of box modification or layout.
What Information to Expose
--------------------------
iank: What information to we want to expose?
TabAtkins: Parent relationships...
TabAtkins: For different types of boxes we might want such as
margin info.
roc: It's very hard to work this out for yourself.
roc: When a box has been split.
dbaron: For parent relationships are you talking in terms of boxes
or fragments?
TabAtkins: Boxes don't have parent/child relationships.
roc: Yes they do, but they don't have geometry.
TabAtkins: When you're doing geometry you need fragments.
astearns: For boxes it makes it so you can get to list of ranges
being displayed.
TabAtkins: It's easier for boxes - line boxes need to go into
character ranges.
Rossen: Does CSS describe inline context?
Rossen: What is inside of a line box?
Rossen: A bunch of runs, inline element, position: inline,
absolute position items, attached in a line but float out
for floating context, etc.
Rossen: A bunch of context inside the line box that isn't
explicitly defined.
Rossen: It could be quite useful.
Rossen: Where is a break?
TabAtkins: Once you expose line boxes, the nature of the break
becomes an obvious thing about it.
Rossen: Depends what we expose on the line box.
Rossen: If I have a bunch of stacked spans in completely different
line boxes, is this part of my break?
Rossen: We need to drive something back to CSS to specify inline
context,
Rossen: Then we can define what APIs we want.
Rossen: For example, we need a dominant baseline.
Rossen: What if we expose all the runs and you can compute it
yourself?
Rossen: That would be more powerful - could figure out where all
the baselines are, inline elements, how we arrived at the
baseline.
TabAtkins: As a start we expose the root fragments. each has a
list of fragments inside of it, the range of the DOM
tree contained within it.
TabAtkins: It can go down to line boxes, which can contain inline
boxes.
TabAtkins: Generated content is a first class citizen here.
TabAtkins: We need a property way to describe where that's going.
TabAtkins: Generated content can contain inline fragments.
roc: One problem is how do you get access to just the information
you want,
roc: Without forcing the engine to take a snapshot of the entire
subtree?
TabAtkins: Good question.
TabAtkins: Maybe you could not have parent pointers?
TabAtkins: You only see the requested box and below.
roc: But you still have to snapshot that subtree.
TabAtkins: Maybe there's options - descendants or not. Maybe a
filter.
TabAtkins: There's ways to declaratively limit what we want to
expose.
TabAtkins: You can easily reveal only what we want so people can't
query arbitrarily.
<franremy> roc: that's where we can divide the api into variants.
maybe some "box" variant don't have child info.
johanneswilm: Would it make sense to limit how far down you go?
johanneswilm: You may be interested in an element and its
immediate children?
TabAtkins: Yes, I think you should able to specify that.
TabAtkins: At least 'this element', 'this element and all
descendants'.
SteveZ: Are anonymous boxes children?
TabAtkins: The fragment generated by a 'before' pseudo is a child
of one of the fragments of its generating element.
TabAtkins: Just like being a first child in the DOM.
astearns: And table fixup?
TabAtkins: Those would show up?
astearns: But not as a child of the table cell.
TabAtkins: No, a parent.
TabAtkins: If you ask for the boxes of a table, you'll get the row
group, captions, etc.
TabAtkins: It depends on the different box types.
Rossen: Is that in the display spec?
TabAtkins: That's where we decided to explain element vs. box vs.
fragment, but haven't done that yet.
Rossen: Type of boxes seems like an element for that module.
TabAtkins: We need to rewrite display box module.
dbaron: Table heights are not interoperable between engines.
Look of the API
---------------
gregwhitworth: Any ideas on what the API would actually look like?
gregwhitworth: I don't see what we're talking about getting uptake
from most web developers - very cumbersome and not
intuitive.
Rossen: Such as what would a selector look like?
gregwhitworth: Yes, hope I don't get a stack of a single tree -
need to look inside of it to make sense of it.
TabAtkins: We could give the type such as it's a flexbox.
gregwhitworth: Yes, to make it more intuitive.
TabAtkins: The nature of the fragment can be exposed here,
TabAtkins: What class you're using in your render tree.
Accessibility
-------------
Rossen: We haven't discussed accessibility at all
shans: Query APIs just exposing information that already exists -
may help accessibility.
Rossen: If there's not good semantics in the nodes then it won't
help.
TabAtkins: A screen reader reading off the json structure returned
by the API?
Rossen: It could.
Exposing Tree Relationships
---------------------------
dbaron: We should talk about what the tree relationships in the
API actually look like.
dbaron: If you have both boxes and fragments you want parent
relationships over fragments.
dbaron: You might want to decide if it's a more array like or list
like API for children,
dbaron: But the issue that causes confusion for people working
layout code:
dbaron: continuations vs. siblings.
dbaron: I'm not sure we should expose that to the web.
<dbaron> interface CSSBoxFragment {
<dbaron> Node node; // or element? -- what about text
<dbaron> DOMString anonymousType; // empty string for normal??
<dbaron> CSSBoxFragment parent;
<dbaron> // Previous/next fragment of same box
<dbaron> CSSBoxFragment prevFragment;
<dbaron> CSSBoxFragment nextFragment;
<dbaron> // Previous/next box, whether fragment of same box or
not, as long
<dbaron> // as they're children of the same parent.
<dbaron> CSSBoxFragment prevSibling;
<dbaron> CSSBoxFragment nextSibling;
<dbaron> // access to children
<dbaron> // geometry information
<dbaron> };
dbaron: If you do something like this, you have two different
prevSibling / nextSibling links with different semantics.
Neither is a subset or superset of another.
dbaron: Given this example with lines break as I've drawn them
[photo: https://wiki.css-houdini.org/_media/img_20150207_163553.jpg]
p has 4 child fragments - 2 in each line box. Each red box
is a fragment we have two sets of things children of
different parents don't have next/prev siblings but
prevFragment / nextFragment links aren't just for siblings
asking someone to walk over the tree once they'll usually
mess it up.
dbaron: You want to walk over all the boxes of an element.
dbaron: You need to use the next fragment links of the element
only.
dbaron: Look at the next child links but not the next fragment or
you might double walk the tree.
dbaron: Do we want to expose this to web developers?
gregwhitworth: We can expose what makes sense.
gregwhitworth: You would do this internally.
dbaron: Then what do you want to expose?
SteveZ: There's different levels of developers - those that don't
want to see this and those building higher level
facilities that do want to.
gregwhitworth: You can see both.
johanneswilm: Wouldn't this all be there if we simply had a line
box, each with fragments?
TabAtkins: It would have a similar structure, but arranged by line
boxes.
dbaron: This just adds another set of boxes - doesn't change the
linkage.
TabAtkins: You want to be able to say "for this span, where are
the rest of its fragments?"
dbaron: In Gecko, we call the green links sibling links, the black
ones are continuation links.
<franremy> TabAtkins: It's maybe orthogonal though--
fragment.ranges[0].commonAncestor.getAllFragments()
shans: What about an API that gives you various walks over the
structure?
shans: We do the hard work of iterating them correctly.
dbaron: You could provide an iterator that solves the 'hard to
walk over the whole tree', but may still be confusing.
plinss: We need to expose this in the low level API but we need to
be careful what to call them to explain them rationally.
plinss: Not 'next sibling',
plinss: I'm sure we can come up with names that make it more
obvious.
plinss: And we can also expose iterators to make it easy.
plinss: But we have to explain this - it's fundamental stuff,
people will have to learn this.
johanneswilm: I know we JS developers have historically not been
seen as real developers - but we're not less
intelligent than everyone else.
johanneswilm: If we want to build good web apps that are as good
as native apps, why shouldn't we have these things?
johanneswilm: People will make libraries.
plinss: To do hit testing you can just walk sibling relationship -
don't care about parent/child continuation.
TabAtkins: I think we can cast these in an easy to understand way.
plinss: I think we'd be doing a disservice to try to expose this
as different trees with simpler APIs.
TabAtkins: I was thinking about something like what François wrote.
rbyers: Is there an example of this sort of API in native
platforms?
TabAtkins: Kind of, yes
TabAtkins: There's an example in android where there are ways to
get at some of this stuff but I don't know details.
iank: Android is simple with its text.
dino: I bet one of the more complicated ones is Adobe's API for
text in flash.
<astearns> flash text API:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flashx/textLayout/elements/package-detail.html
rbyers: But we should make an attempt to learn from other
platforms here.
dino: The iOS one (CoreText) isn't nearly as complicated as what
we have.
dino: In general on iOS we expose more details but nowhere near as
complicated layout.
<dbaron> I think it's worth considering what the API would look
like without exposing fragments in the primary API, but
exposing them in something secondary.
dbaron: Maybe if you exposed the fragments as something secondary.
TabAtkins: e.g. for a span you ask either for one or for all its
fragments.
roc: That won't tell you which fragments are children of which
other ones.
TabAtkins: You get the initial view, but if you walk down and ask
for all your fragments you'll get an array of two spans.
roc: Those span fragments, will they have parent pointers?
TabAtkins: I don't know, we'll figure it out.
TabAtkins: We will have to review some use cases to figure out API
shape.
johanneswilm: But you will get down to what text is where.
TabAtkins: Yes, you'll need to.
Rossen: The other one we expose outside HTML is the rich text box.
Rossen: It's part of the .NET platform.
Rossen: It's not as much richness as HTML / CSS
Rossen: but has a decent amount of API surface
<Rossen> https://msdn.microsoft.com/en-us/library/system.windows.forms.richtextbox_methods(v=vs.110).aspx
iank: Is that part of WPF?
Rossen: In .NET 4.5
Rossen: So do we want to go after a model that exposes everything?
Or a simpler one with iterators?
shans: It seems to be lots of support for expressing everything.
shans: But we should try to back up with use cases.
SteveZ: If you expose everything, then people can write iterators,
SteveZ: Otherwise you lock out some views people would like to
have.
Rossen: That's a valid argument this isn't easy to get right.
SteveZ: So people will produce iterators that will do the right
thing.
TabAtkins: I think I can create something nice, I just need to
review some use cases.
ChrisL: It doesn't mean we have to give the entire tree at once,
ChrisL: It just has to be available through traversal.
shans: If we can cover all of the information with a good set of
iterators then it may solve the snapshot issue,
shans: For a really large tree.
Rossen: If you get back an iterator, now you're blocking until the
iterator is released.
Rossen: But if you get back a collection (with the promise based
approach) then the engine can continue modifying the tree.
shans: A certain amount of work needs to be done to prepare the
data.
shans: If you don't have a way to restrict what you ask for...
TabAtkins: Yes, we're going to have a way.
TabAtkins: There's an async barrier, you ask for all the stuff you
want.
shans: Our filters need to be really good.
TabAtkins: I have a decent idea for this.
TabAtkins: Need to see how well it satisfies the various use cases.
shans: Are there any other box tree related concepts people want
to discuss?
<franremy> btw, something interesting to mention here is
getClientRects return visual position, not layout one
<franremy> you can't know where a box is in the inline flow
without unapplying transforms/relative pos; that's
annoying
What Properties the Box Model Will Cover
----------------------------------------
TabAtkins: This is excluding text measurement?
Rossen: Yes.
Rossen: I think the box tree tells you about what's there.
Rossen: You get the structure of the boxes. Should the box module
cover the properties of the boxes themselves, or just the
structure?
Rossen: Given the different types of boxes we will have, putting
them all in this spec will be hairy.
Rossen: But I could see it going either way.
Rossen: Certainly measurement, geometry information.
TabAtkins: Fragments will link back to their elements
TabAtkins: While there's not a perfect correspondence between box
properties and element properties it'll be pretty close.
TabAtkins: But anonymous boxes don't have any elements to go back
to.
Rossen: So what do you do with all the structure for boxes not
backed by DOM?
TabAtkins: Yes, so let's look at the use cases and see what's
needed there.
shans: So should this be excluding or including measurement?
TabAtkins: I imagine most of the use cases want to know sizing
information.
iank: There's sizing and there is measurement - what size would
you be given this constraint?
TabAtkins: Right, so this is sizing only. measurement is elsewhere.
Rossen: A good part of measurement API is it doesn't depend on
layout.
Relationship to SVG
-------------------
Rossen: Anything from the SVG point of view?
ChrisL: 2 years ago I would have said no - don't use the box model.
But in SVG 2 we're trying to reuse text to use the box
model. So yes.
ChrisL: But it's not really clear how we're doing it but I think
this will help and I expect to see the same sorts of
things exposed.
TabAtkins: If you put width on a text element you get line boxes
out.
TabAtkins: But rest is probably 1:1
Rossen: I'm not sure about use, marker, etc.
ChrisL: I need to look into it, but in principle we want to use
the same thing.
ChrisL: How useful it would be I'm not sure.
roc: Text on a path fragments are transformed - not rectilinear
relationship. don't think we want to expose arbitrary
transforms.
roc: It seems less complicated to expose what we had before doing
the path transformation.
ChrisL: Yes, that's fine.
roc: We use the same engine for HTML and SVG text - would be hard
NOT to return the same information.
roc: It would be nice to have a box and fragment for each SVG
element.
roc: Per spec it's not clear it has a box, but I think it should
and in Gecko it does.
ChrisL: So each element generates a box and each is absolutely
positioned?
roc: Essentially, yes, SVG has its own layout model.
Rossen: That's pretty much the same as what we have in IE.
ChrisL: Not clear what this gets you.
roc: Tools that highlight elements you hover over - working the
same for HTML and SVG
roc: For example, that's how our dev tools work.
ChrisL: That makes sense.
plinss: In Gecko, does the box of an SVG element give you the
bounding box?
roc: It's a little confusing, we'd need to spec it out.
roc: There's an idea of an SVG bounding box.
roc: In Gecko we the CSS border box is the SVG bounding box.
ChrisL: SVG 2 is adding the second bounding box - decorating
bounding box.
roc: We have this for all our elements internally, it's not
exposed.
ChrisL: Painting box can be bigger.
TabAtkins: ... background is fill, border is stroke.
plinss: Box tree API should be extensible so SVG can extend it.
TabAtkins: Or we map to HTML.
plinss: But what will they have in a few years?
TabAtkins: Gecko has a proprietary border-colors property to
specify multiple borders.
Physical vs. Logical Measurements
---------------------------------
Rossen: Anything else related to box tree?
murakami: About box tree measurement - physical and logical are
both needed in box tree measurement API.
murakami: It defines block size and inline size. Such APIs should
be defined for box tree.
Rossen: When you read back results in the box tree they're post
layout. So e.g. for vertical text should we be talking
about width/height and origin for logical or physical
point of view.
Rossen: I could see us mapping those back and forth being fairly
straight forward.
TabAtkins: I don't have a strong opinion, but I don't think it's
bad to just report x,y,w,h (physical).
Rossen: An example: I want width and height of vertical line so I
can constraint it somehow,
Rossen: But now you're putting the burden back on me to figure out
what it was.
Rossen: Should we perhaps expose both?
Rossen: Such as in Trident everything is logical.
TabAtkins: Ours too.
shans: I don't think we can just expose logical.
Rossen: We'll probably have to expose both, just like CSS.
gregwhitworth: I don't think more options are a bad thing.
gregwhitworth: We just need to make the API intuitive - that'll be
the hardest part.
shans: We'll have to be very careful about names.
gregwhitworth: I truly hope there won't be a need for a library.
gregwhitworth: There should be a simple way,
gregwhitworth: so if physical is the easiest way for me to
understand it, I should be able to get it.
plinss: But the extensible web manifesto says to expose the base
primitives and let people make libraries.
plinss: Then we wait to see what libraries become popular.
plinss: If we try to predict all the interesting usages and APIs
we're going to take a long time and still get it wrong.
plinss: Let's do something simple and basic that people can build
on top of, and see what people do.
roc: Yes.
shans: So logical vs. physical might be important because they are
pieces of fundamental information.
plinss: All the base information should be available. but if I can
compute all the logical dimensions from the physical plus
style information then I don't have to expose them.
plinss: A common thing in these APIs is whether to use a parent-
relative co-ordinate space or other origin.
plinss: We end up converting back and forth.
Rossen: Do we expose used values or actual values or both?
Rossen: Pre-transform or post-transform?
Rossen: We obviously want the result of layout,
Rossen: But another layer of all the transforms applied on top of
it.
dbaron: I don't like 'actual value' term.
dbaron: The spec uses it but fails to define it.
roc: One option is to ignore transforms for this box spec, return
co-ordinates relative to something local, such as fragments
for an element are relative to top-left of element's border
box.
roc: Then use geometry APIs to compute relative to other elements.
roc: If we put transforms into here the API will be more
cumbersome.
shans: Yes, it's more consistent for transforms not to be part of
this.
roc: We've already spec'd out conversions of quads between any two
elements.
roc: We don't need to do that again.
<franremy> and what about "position:relative;top:X;"?
<franremy> because the 'inline' layout use the position without
the 'top' being applied, yet people may expect to get
position applied.
xidorn: I'm concerned that some spec defines anonymous boxes but
doesn't define the process to create it.
Rossen: Part of the box tree?
shans: We might need to update spec text for this.
shans: We should change spec text to say boxes are created for
purposes of box tree API.
plinss: CSS spec should be defining what boxes show up for the box
tree API.
shans: That doesn't mean engines need to store additional data.
plinss: Engine can always synthesize responses to the API.
dino: They're going to have to anyway.
Rossen: We've optimized the engine so there's nothing left.
astearns: What about franremy's question?
Rossen: position: relative is something we compute during layout.
Rossen: It's reasonable to have it.
Rossen: If it's used value then it should be exposed.
dbaron: I don't know that I'd draw the distinction based on used
value or something else.
Rossen: In your box tree, are you storing the relatively offset
box position?
dbaron: Yes.
Rossen: Same for us.
dbaron: I agree relative stuff should matter.
dbaron: Just that 'used value' isn't the distinction.
Rossen: Anything else we want to discuss?
shans: It's probably more productive to start getting some spec
text.
Rossen: Break for the day or move on to the next topic?
Rossen: It's property and value extensions
iank: That's probably quite big.
<Zakim> ChrisL, you asked to be reminded at this time to go home.
<franremy> I think Zakim solved the question for us.
roc: Could we get more done by splitting in two?
roc: There's the style system then after you've computed style
there's extending layout and painting.
roc: I'm really only interested in the latter.
dino: How full is the CSS agenda?
roc: If not too many people are interested in both we could get
more done.
Rossen: People will gravitate to one or the other anyway.
Rossen: We're adjourned for the day.
Received on Tuesday, 3 March 2015 19:22:22 UTC