- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 27 Aug 2017 14:32:48 -0400
- To: public-houdini@w3.org
- Cc: www-style@w3.org
=================================================
These are the official Houdini Task Force
minutes. Unless you're correcting the
minutes, please respond by starting
a new thread with an appropriate subject line.
=================================================
Layout Worklets
---------------
- iank reviewed the changes made since the last F2F
- There was a lot of confusion around the proposal on handling
inlines and the childDisplay flag, especially around the
'normal' mode (both the name of the mode and the purpose) so
the group worked through use cases to understand it better.
- RESOLVED: Proposal above accepted [proposal: floats and
block-inside-inline are given their own line box
fragment thing, whose width is given to the block as
the available inline space. (This essentially forces a
line break before and after the item)]
- RESOLVED: absolutely-positioned children do not appear as
LayoutChilds
- RESOLVED: relpos and transforms are after layoutworklet
positioning
- iank received several actions to clarify text in the spec and
move some items out to Level 2.
- RESOLVED: Publish CSS Custom Layout FPWD
Future Meetings
---------------
- Houdini will meet on Thursday of TPAC.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Paris-F2F-August-1st-2017
Scribe: fantasai
Layout Worklets
===============
<dino> https://drafts.css-houdini.org/css-layout-api/
Handling inlines
----------------
<dbaron> https://drafts.css-houdini.org/css-layout-api/#breaking-and-fragmentation
iank: Last time we talked about handling inlines
iank: discussed having a flag childDisplay
iank: default is childDisplay = block, which blockifies every
child.
iank: Other value, currently called normal, is that a root inline
box will spit out line boxes
iank: into given available widths.
iank: This example here, takes two copies, one which is
indentation and the number of lines to apply that indentation
iank: and will adjust the inline size of that root element.
iank: Simple example.
iank: Some issues open on inspecting the resulting line box, but
can get into that later.
* fantasai thinks normal is a terribly generic name for this
behavior and suggests "line" (as opposed to "block")
franremy: What's blockFragmentationType?
iank: Not native to this example, can ignore that.
franremy: What does it do tho?
iank: When set on a child means it will try to fragment at the
block fragmentation offset
iank: e.g. if child has avoid break column on it then [...]
iank: This example shows a lot of fragmentation things.
iank: Can talk about making layout more powerful, but conceptually
this is it.
iank: Default for childDisplay is block, which is like flex/grid
layout.
fantasai: Why isn't it called "lines" or something?
iank: Could do that, yes
iank: Conceptually, you could have a bunch of blocks represented
by layout children which would behave like ...
iank: then children that are part of root inline turn into line
boxes.
fantasai: I didn't understand that at all.
fantasai: I have a box, this is the parent, it has some children.
fantasai: Each display property value is assigned to at least one
of these children.
fantasai: When childDisplay is block, they all get blockified
fantasai: when childDisplay is normal, what happens?
iank: They have their normal display type.
fantasai: What does that mean?
iank: You get their normal display type.
fantasai: But what does that mean? what does the API return?
[iank shows Fragment idl]
iank: If you lay out a thing that's a block, you will get a single
fragment
iank: You can position it by setting the inline block offset.
iank: In the normal mode, and you're laying out a root inline box,
you will get returned line by line.
fantasai: So the fragment represents a line box or a block?
TabAtkins: Basically a fragment.
dbaron: What I originally thought you were saying is not what I
now think you're saying.
dbaron: What I originally thought was that you were describing a
thing that said whether you would treat a bunch of line
boxes as giving each line box, or just treat it as a child
anonymous block that wraps the line boxes.
dbaron: And now what I understand you to be saying is that you're
talking about whether you're going to blockify each
individual child as flex and grid do.
TabAtkins: Yes, that is what this is about.
dbaron: I'm a little worried about putting that in the layout API,
because it seems like it's about box tree construction,
which I see as happening earlier in the process.
iank: There are basically two ways the box tree can be constructed
here, and that's controlled by childDisplay.
iank: UA would read childDisplay value, and would change the box
tree construction based on that value.
TabAtkins: This happens when you register the layout, so it's
available at box tree construction time.
dbaron: It's annoying to have to handle this before handling
children.
iank: Why annoying?
dbaron: There are other parts of box tree construction that I
think come out a lot easier if you do bottom up rather
than top down
dbaron: Servo does it bottom up, was thinking of making Gecko do
that.
TabAtkins: Then how do you deal with blockification in flex/grid?
dbaron: I guess it handles it some way
TabAtkins: We're not doing anything more than what the specs do.
dbaron: But then you need to load your custom layout stuff before
box tree construction.
dbaron: You have to do it in the middle of box tree construction.
TabAtkins: You need to do execution of it.
iank: Otherwise it falls back to block.
TabAtkins: This is at registration time.
iank: Otherwise you'd treat it as an invalid layout.
dbaron: Forgot about registration bits, that's all right.
Rossen: The default is normal?
iank: The default is block.
[Rossen asks for why normal mode exists, ian explains use case is
for controlling available widths for inlines]
[Rossen, see minutes at
https://lists.w3.org/Archives/Public/www-style/2017Mar/0021.html]
TabAtkins: This allows layout worklets to do some basic level of
inline layout.
fantasai: So can we rename this thing that's called normal to
lines or flow or something else that's less generic?
TabAtkins: It's do what you do normally.
fantasai: Normally isn't a thing, there's different layout modes,
they each have their own "normal". You pick one.
TabAtkins: It's not lines though.
dbaron: You're defining children as line boxes effectively.
dbaron: There are three things that this doesn't control but could
expose.
dbaron: If you're laying out a block of inlines, does the layout
expose blocks, does it expose line boxes, or does it
expose inline boxes.
fantasai: And we decided not to tackle inline boxes right now,
because it's too complicated.
TabAtkins: The API takes inline boxes as input, gives line boxes
as output.
iank: The input is a root inline box, the output is a line box.
dbaron: Which may be substantially larger than the root inline box.
TabAtkins: Boxes don't have width or height.
TabAtkins: That's a pre-layout concept.
dbaron: By the time you have done layout it does.
TabAtkins: No, by the time you've done layout you have fragments
and text.
TabAtkins: I'm using modern terminology of boxes and fragments.
Boxes are box tree structure. Fragments are rectangles
with geometry.
TabAtkins: Right now we're outputting line boxes, internally it
does inline layout but we don't look into that it's too
complicated.
TabAtkins: At some point later we'll expose that.
TabAtkins: Then I'll position the line box how I want, and inside
it'll lay out however it wants.
fantasai: Overall seems reasonable, but need to rename 'normal'.
Rossen: It's not a line, could be a table.
fantasai: The closest thing it does is what Gecko does, which is
wrap each line of inline-level content and each
block-level fragment into its own line box.
fantasai: And then returns a Fragment object representing that
line box.
[TabAtkins asserts its not a line box, because CSS's concept of
line box doesn't ever contain a block-level element, but
that's not what fantasai was talking about she was talking
about Gecko's internal architecture and its lineBox objects]
<TabAtkins> That's not what I was asserting either. >_<
dbaron: childDisplay should maybe have "force" in the name
fantasai: I think it's fine.
iank: Question is inside of a root inline box, if you see a float
and if you see something that is block-level, what do you do?
dbaron: I think those are two very different questions.
iank: Tab and I thought they should just become atomic inlines.
dbaron: Why wouldn't you want them to do what they do everywhere
else and do block-in-inline splitting?
iank: Because it's scary.
dbaron: Doing column display requires that.
iank: No it doesn't.
iank: We don't want to bake inline splitting into the platform.
fantasai: I think you should just wrap the block into one of your
line box fragment things.
iank: fantasai and I discussed this at lunch.
iank: Idea is to force break before/after and have it just take up
that space as its container.
...
iank: In our impl, whenever we see block-in-inline, we split into
3 boxes.
iank: First half is one anonymous box, then there's another
anonymous box with the block, and then a third with an
anonymous box containing the rest of the inline.
iank: This is why abspos is broken in these cases in our impl.
Rossen: From PoV of what you were outlining
Rossen: about block-level and float /inline level
Rossen: For second case, we have a float inside an inline
Rossen: spec says "instead it must be treated as in-flow, and be
inlinified"
Rossen: why?
iank: For 1st level of spec, didn't want to deal with floats.
iank: If you have a float intruding outside the line box, want to
skip that complexity.
fantasai: It's not really “normal” is it, if the floats and
block-in-inlines don't behave as they “normally” do.
Rossen: ...
iank: What we're suggesting is that floats are treated as
inline-block.
Rossen: So you're back to internal layout.
Rossen: Things will happen. Set of floats might be positioned
around a line of text, and at the end line of text you
come back to as a fragment
Rossen: And then you register a bunch of exclusions.
iank: ...
iank: Ignore floats and forces them to be inline blocks.
franremy: Basically there will be no floats in custom layout.
iank: If we handle floats, we have to add exclusions and stuff to
1st level which is complex.
fantasai: If you're going to do custom layout, including floats
makes no sense. Not sold on doing what's in the spec, but
floats should certainly not float.
fantasai: If we're wrapping block-level stuff in line boxes like
we described, I would suggest doing the same thing for
floats.
iank: Yeah, that makes sense. Then you could implement floats
yourself if you wanted.
fantasai: So I think we should do that. If you really want floats
to work, you can implement floating yourself, and
otherwise you treat them as block-level boxes.
fantasai: Do margins collapse?
iank: No
fantasai: Then it's not “normal”.
[Summary of the proposal is that floats and block-inside-inline
are given their own line box fragment thing, whose width is
given to the block as the available inline space. (This
essentially forces a line break before and after the item)]
RESOLVED: Proposal above accepted
franremy: If you have abspos inside an inline...
Positioning
-----------
<astearns> https://drafts.css-houdini.org/css-layout-api/#interaction-positioning
iank: Next round of simplifications.
iank: I think it'd be nice if all positioning stuff is handled by
the UA
iank: e.g. if you have an out-of-flow child, doesn't appear in
LayoutChildren.
iank: You don't get to control them.
fantasai: Did you mean abspos? out-of-flow includes floats.
iank: Yeah
ACTION iank talk about absolutely-positioned boxes rather than
out-of-flow boxes in the positioning section
franremy: This is fine, except you wouldn't be able to implement
the abspos aspects of Grid.
TabAtkins: Not in v1, right.
franremy: You could work around that with custom properties in
place of 'position: absolute'.
iank: For relpos, the inlineOffset and blockOffest values of the
fragment are considered to be before relpos and before
transforms.
Rossen: Inline and block offsets, you can additionally offset
those.
iank: Yes, they're initially set to 0 0, you can set them wherever
you want.
RESOLVED: absolutely-positioned children do not appear as
LayoutChilds
RESOLVED: relpos and transforms are after layoutworklet positioning
fantasai: Wrt the static position bullet... the alignment
properties are supposed to affect the static position,
so it's not a point you're defining here, it's a
rectangle.
fantasai: And also, the padding box is relevant for the abspos
containing block, not its static pos
Rossen: Do we need this bullet point?
fantasai: Yeah, need to define static pos.
fantasai: Could define to do what flex or grid do.
fantasai: Can't define to do what block does, because that
requires figuring where the box "would have been" if it
was a block... which we don't know
fantasai: because we're not doing block layout.
ACTION: iank update staticpos bullet to fix above issues
franremy: If you have position: sticky, this is the same as
position: relative
franremy: the UA will just make it stick
ACTION: iank clarify that point explicitly as well
Overflow: Scrolling and Fragmentation
-------------------------------------
iank: Next section is interaction with overflow
iank: Because we're handling transforms and position: relative by
the UA, seems that overflow should also be handled by the UA
iank: Stuff we discussed in Tokyo, that we assumed you might get
relayed out twice once without scrollbars and once with
iank: You still need to be able to reason about relpos and
transform to decide whether a fragment will trigger
scrolling, in this level don't deal with it. Maybe add an
API for more efficient figuring out later.
ACTION: iank add stuff about double scrollbar layout above
iank: Final section is fragmentation.
iank: Two attributes, blockFragmentationType and
blockFragmentationOffset
iank: set by your parent.
iank: Your parent layout can set your blockFragmentationOffset
iank: blockFragmentationType is enum none/page/column/region
fantasai: If you set blockFragmentationType to none and
blockFragmentationOffset to 100px what happens?
iank: It's invalid for the parent to give you that.
fantasai: But what if they do.
Rossen: Your fragmentation break creation is based on the value of
the blockFragmentationType, if set to none then the offset
is irrelevant.
Rossen: If it's not none, then you're expected to propagate it
down.
iank: If the blockFragmentationType is none, then the UA will
coerce blockFragmentationOffset to zero.
fantasai: Is that in the spec?
iank: No.
ACTION iank add blockFragmentationOffset coercion to zero on none
to spec
astearns: Pages can be left to right or top to bottom depending on
the writing mode.
iank: This is only in the block axis.
fantasai: This is an important point, actually. An orthogonal
multi-column element can fragment between columns (in
its inline axis)
fantasai: And this is actually a reasonably common use case.
[iank and Tab draw this on the white board]
Rossen: iank's point still holds.
TabAtkins: We might need to pass in information about being
orthogonal flows, but yes, in this case the element is
fragmenting in its parent's block axis.
<fantasai> This case though, the fragmentationtype/offset is in
the layout container's parent's writing mode's block
axis, but not its own block axis.
<br type=coffee>
fantasai and iank discuss how blockFragmentationOffset needs to
be handled for orthogonal flows; plan to have the caller indicate
no fragmentation, otherwise the layout function author would need
to know to treat the blockFragmentationOffset as an inline-axis
fragmentation offset
ACTION: iank specify that an orthogonal flow's blockFragmentation*
args get reset to none/zero (meaning orthogonal flows
can't fragment in custom layout) so that authors don't get
confused and try to fragment in the wrong axis
</br>
baselines in custom layout
--------------------------
iank: There are several levels here...
iank: This gets into a hairy topic I don't want to get into yet
iank: which is basically, do we want a separate line fragment type.
iank: This is that font metrics object.
iank: ta-da!
[iank displays FontMetrics api
https://drafts.css-houdini.org/font-metrics-api-1/#intro ]
iank: We agreed that having childDisplay=normal being useful, root
inline boxes spitting out lines is useful simplifies things
a lot
iank: One powerful thing to talk about later is having explicitly
a line fragment object
iank: which inherits from a normal fragment
iank: but it has extra information about what is inside that line
iank: so you can inspect the segments in that line
iank: and the baselines and stuff like that.
iank: That's sort of baselines part one:
iank: where are the baselines in the text
iank: the way to do for fragments more generally.
iank: As an input to layout you give it the baselines that you
want.
iank: You may want to know the alphabetic and middle baselines of
the block
iank: you can get those baselines from the fragment.
iank: Conceptually a UA could propagate which children need to
produce which baselines and bubble those back up.
iank: We probably won't wait for implementations of css-align-3
which has additional baselines.
fantasai: I think you meant 'central' there rather than 'middle'
fantasai: They're all different (middle, center, central),
unfortunately.
iank: I went for this model instead of having a baseline offset on
each fragment
iank: because more powerful / nicer
iank: didn't want to wait for css-align-3 for multiple baselines.
franremy: for baselines, can you change positioning based on the
alignment?
iank: This will return the offset from the top of the fragment.
fantasai: There's a first baseline and a last baseline, is this
the first baseline? :)
iank: ummmm
iank: Might need tuples.
iank: first/last vs alphabetic/central/etc
iank: Do we need first-letter baseline?
fantasai: I don't think so.
fantasai: I would say if it's stuff we can add on later, we should
add it later.
Rossen: Certainly first and last should both be there.
iank: Might want to wait until css-inline-3 shapes up.
Sizing
------
iank: Last bit of interactions is how sizing works
iank: implicitly, what happens is ...
iank: Let's go with this version of constraintspace atm
iank: Can have 3 types of sizes:
iank: Can give a fixed size
iank: can give child available sizes
iank: can also give child percentage sizes.
iank: This is slightly different from what I had here.
fantasai: Why is percentage not considered fixed
iank: For example ...
fantasai: Oh, it's not the percentageSize, it's the size against
which percentages are resolved.
iank: Maybe should change that to percentageResolutionInlineSize
etc. Since most of the time you won't be setting this anyway.
iank: Defaults to the value of the availableSize
iank: or 0 if you set infinity.
<fantasai> (random bikeshed idea: { inline100percents:
<somevalue>, block100percents: <somevalue> } for the
name)
iank: If you set fixedInlineSize then percentages will resolve
against that size.
fantasai: Wait, that doesn't happen currently, the child would
resolve against some aspect of the available/parent size.
iank: I think it's the grandchild that cares?
iank: ...
iank: If the author only sets the fixedSize, then available and
percentageresolution sizes copy that value.
fantasai: I think, since we don't currently ever resolve a box's
own percentages against it's own specified size, then
defaulting avail/percentageResSize to fixedSize would be
confusing.
iank: So just default them to zero?
fantasai: Yeah, I think that would make more sense.
ACTION: iank have percentageResolutionSize and availableSize, when
unspecified, default to some initial value like zero
rather than to fixedSize so it's clear what's what
Automatic Inline Sizing
-----------------------
iank: This has some interactions with how other layout modes
interact with this
iank: e.g. positioned layout sizing should size the positioned
sizing equations if they need to and then fix their layout
to that size
iank: e.g. if containing block has width=height=100px
iank: immediate child which is abspos with tblr=10px
iank: UA will set a forced fixed size.
TabAtkins: This is a result of default stretch alignment
calculating the box's width/height from the offsets.
fantasai: So if you set align-self: center;, then it wouldn't
force a fixed size.
iank: You have fixed size, you have available size, and you have
percentageResolutionSize, which the UA can pass in to get
the different sizing constraints.
iank: I think that's all we need.
fantasai: Can the author ignore the fixed size?
iank: No, the UA will force it.
fantasai: So letting the child know, you're getting this fixed
size, deal with it.
iank: Yeah.
iank: So now the constraintSpace here is a bit wrong
iank: inlineSize here needs to be split into "availableInlineSize"
and "fixedInlineSize" etc.
iank: This brings us to resolving inline sizes.
iank: Currently in all of the examples
iank: the first thing the custom layout size does is resolve the
inline size using the resolveInlineSize(space, styleMap)
utility function.
iank: This does the default things!
iank: One thing we could do is to always do this call for the
author
iank: But this wipes out a class of use cases
iank: Where you can't adjust the inline sizes
iank: Like happens currently in flexbox.
fantasai: What's the output of the layout function?
iank: dictionary FragmentResultOptions
fantasai: So, you could give that a constructor that could
optionally take the styleMap and space as optional args,
and if they are present, calculate the inlineSize as
part of construction.
surma: Options bag as return object is more common in JS APIs.
surma: So keep that.
[iank shows off utility functions]
iank: Function called resolveInlineSize, which every example calls
immediately
iank: Doesn't cover all cases, though, like bubbling up sizing in
MathML
fantasai: I think if you want to make this more ergonomic you
could incorporate it into defaulting on the output,
either by building it into the constructor or by
automatically converting null output on inlineSize to
run this calculation.
fantasai: I wouldn't choose to force it to this calculation.
Rossen: If I have 42 custom layout where all sizes are 42, you're
preventing me from doing that by "helping me".
fantasai: It's not really custom layout if I can't customize it :)
franremy: [......]
iank: There's a separate intrinsicSizes pass.
...
iank: At some point we'll be able to do layout in intrinsicSizes
pass, but Gecko can't do that currently.
franremy: There was a mention gecko could not handle layout of
children to compute intrinsic sizes; I was wondering
whether that was not required for tables since there is
spanning of cells etc, but dbaron doesn't think it
requires it.
dbaron: Tables don't do that.
...
jack: Resummarize?
iank: Servo has 3 passes, bubble up content sizes, recursive down
layout sizes (?), then tertiary positioning phase
[missed]
jack: SimonSapin implemented writing modes
jack: In cases where height depends on width or whatever, we defer
the calculation to later pass
jack: It's resolved slightly later.
iank: Would you be fine with [...]?
iank: Let's say a custom layout is a float.
iank: You have to lay it out first to know its inline size.
jack: Floats already cause problems.
dbaron: He's talking about floats defaulting to using intrinsic
sizes.
iank: Similar also flexbox initial pass.
dbaron: Not sure about custom layout being as problematic as you
thought, but I also don't understand the model.
dbaron: I'm understanding is you're computing inline sizes on the
way down the tree, block sizes on the way up the tree
dbaron: what you do in between is lay out children
dbaron: which seems reasonable consistent with this.
iank: We won't report the inline size until after we lay out the
children.
iank: In all cases so far, we calculate inline sizes ahead of time
iank: not strictly needed.
iank: You could not set the inline size until the end, where you
always report 42.
dbaron: You can report a different inline size that you were given.
iank: If it's not fixed, yes.
iank: You can tell your children to be fixed at 50px, or that they
have some arbitrary layout with available size.
jack: We would like to get out of this is to run in parallel for
multiple elements at a time.
Rossen: Can you run something deep in your subtree parallel with
something much higher, or boxes that are disjoint in the
box tree.
Rossen: I've played with both models.
jack: We won't run computations simultaneously on parent and child.
Rossen: In that case ian's concern is not a problem.
iank: We can say "layout these 5 children", this supports that.
iank: This API creates a child constraint space, and gives it all
of its children, and all of those children will lay out in
parallel (or could be laid out in parallel).
till: You're not concerned about other way of laying things out
because infeasible anyway?
Rossen: It is feasible, but in that case when you're stitching
between your chain of layout, the assumptions that you
projecting down in your further start need to match up
otherwise you have to restart.
Rossen: In those cases, what iank is saying, is you can set inline
sizes ahead of time and then start your execution.
iank: You could then change your inline size.
Rossen: Otherwise doing a lot of work and redoing it.
till: Seems like this could be solved by requiring you to opt into
both modes, where you have to be explicit about whether you
want inline sizes to be dynamic or fixed.
till: If we don't require that then probably in those cases we'd
???
till: once you had this kind of optimization.
till: Not requiring specification of inline size would probably
lead to most content not specifying an inline size, so you
don't have the optimization.
till: Whereas if you have to decide whether to specify or not at
the beginning, then ...
till: Because it doesn't matter in that case.
More Utility Functions
----------------------
iank: It's really nice to have the padding/border/scroll edges
given to you up front.
iank: There's an interface called LayoutEdges that provides this.
[iank shows API]
iank: You can choose border/scrollbar/padding or all since you
frequently want them all together
iank: LayoutEdgeSizes gives you access to each side or each pair
of sides like this: edges.all.inline
fantasai: That's great, I love it
* SimonSapin returns
Automatic Inline Sizing (cont.)
-------------------------------
Rossen: Box tree inline size servo, and integration with other
modules.
Rossen: Did you cover this?
Rossen: We wanted to know whether or not Servo requires to know
inline sizes on the way down the box tree in order to
produce heights on the way up.
SimonSapin: In short yes, there are three main traversals.
SimonSapin: Each is parallel
SimonSapin: First style computation on the way down
SimonSapin: bottom up intrinsic sizes.
SimonSapin: If intrinsic sizes depend on full layout, we have a
problem.
SimonSapin: Once we finish traversing the tree, go back up to the
root, second traversal.
SimonSapin: Based on intrinsic sizes, assign inline sizes.
SimonSapin: On the way down
SimonSapin: And on the way back we assign block sizes.
Rossen: ...
Rossen: Custom layout can have inline size predefined by the UA.
Rossen: That would allow you, Servo, to always set the inline size
and then keep going down.
Rossen: But from custom layout pov, custom layout is not so custom
if it cannot change the sizes
Rossen: So if you forfeit this requirement or assumption that
inline size is always given, how much would that be a
problem?
fantasai: We're not assigning inline sizes on the way down, but we
are assigning available sizes on the way down.
SimonSapin: For existing css models, when this isn't flexible
enough, we go up one level in the tree and ask the
parent to assign inline sizes.
SimonSapin: Inline size of one node is an input into tree traversal
SimonSapin: But that is based on calculation done on the parent
level
SimonSapin: So inline sizes children of a node can be assigned by
the parent.
Rossen: ...
Rossen: Would it be a problem?
Rossen: You have 3 boxes nested, starting layout from the top box
Rossen: what I understand is you will do one pass down to compute
styles, when you're in 3rd box, will compute intrinsic size
Rossen: based on that work up to compute intrinsic sizes.
Rossen: Then start by assigning inline sizes on the way down
Rossen: top will set inline size, then set inline size of 2nd,
then third
Rossen: on the way back up computing heights.
Rossen: Let's say middle box is a custom layout
Rossen: Root box still has size set by input space
Rossen: It wants to go down and compute layout, but the child is
custom layout.
Rossen: It can suggest an inline size, but the custom layout wants
to set its own size.
Rossen: It says my size is 42.
Rossen: Then you continue to third box.
[missed a bunch of stuff in example]
SimonSapin: Whether we have custom layout or not, we don't want
every layout mode to know about every other one.
SimonSapin: Want some division of responsibility.
SimonSapin: Top box would compute some inline size it wants its
children to have
SimonSapin: Its child can change that decision if it wants.
Rossen: So we seem to be correctly speculating that this won't be
a problem for Servo
[various discussions about layout models. summary of the
discussion was that servo would be able to handle what is
currently in the spec]
Inspecting LineFragments
------------------------
Scribe: franremy
iank: Line fragments are useful to inspect in custom layout.
iank: This is a very early prototype api we came up with in 5min
but we want opinion.
iank: The idea is that you might want to be able to inspect the
various segments inside the lineFragments
iank: where each char is, where the baselines are, etc...
iank: which enable powerful things to authors, like line-text
alignments.
Rossen: One of the principles of layouts steps is that you are
operating at one level at at time.
Rossen: What you are proposing breaks this invariant.
Rossen: It is still worrisome even if only applies to lines
metrics.
Rossen: Second issue is that we are going to expose metrics, we
might also want to do it for non-line fragments.
Rossen: If we want to support inline layout, maybe we should be
transparent and support all of it.
iank: But this is a read-only api, we don't allow changing.
Rossen: for now ;-)
Rossen: (slippery slope argument)
Rossen: I would rather not have this in level 1.
iank: sounds fine
ACTION: iank remove LineFragmentSegment from level 1
iank: Final idea though would be inspect where words would break,
and re-layout with other space constraints.
astearns: We already expose baselines, right?
iank: Yes, this would allow you to get more details though.
astearns: Seems sufficient for level 1 though.
iank: ok, this would be for level 2 then.
iank: Since we are rewriting our layout engine, we are going to
build in three or four phases.
iank: The new engine will first be to support "block" stuff
without fragmentation.
iank: Step up would be childDisplay "normal"
iank: and then once we have fragmentation, we will light up the
breaktoken and further fragmentation capabilities.
iank: My understanding is that there is broad consensus that would
allow us to work on this further.
Publication
-----------
Rossen: I think that covers the implementation progress for
everyone.
iank: I guess.
Rossen: It would be good to republish.
iank: ok
iank: One thing left to bikeshed is the "constraint space" name;
an idea would be "layout input space".
astearns: We need a resolution to publish fpwd actually.
Rossen: Any objection to RESOLUTION: Publish CSS Custom Layout
FPWD?
(no)
RESOLVED: Publish CSS Custom Layout FPWD
Meeting wrap up
===============
Rossen: Is there one more thing we need to discuss today?
iank: Lea Verou replied to an issue mentioned earlier, we could
discuss that.
iank: issue 434
iank: the issue about { inherits: true } by default
<astearns> https://github.com/w3c/css-houdini-drafts/issues/434
Rossen: What do we want to discuss further here?
Rossen: Can we not leave this as a github topic for now?
iank: Encouraging true by default being a performance footgun is
something we really wouldn't like
iank: but if there is strong pushback, we could revisit.
Rossen: It is not optimal.
iank: Not strong pushback, so let's keep it as is.
Rossen: OK so there shouldn't be any other topic to discuss.
Rossen: We should decide if we want to meet at tpac though.
Rossen: Thursday or Friday are the options.
Rossen: Any strong preference?
Rossen: Personally, I think we should meet.
dbaron: There is the AC meeting but most people prefer not having
the gap, so Thursday is fine.
Rossen: OK let's aim Thursday then.
Rossen: Thanks Mozilla for hosting us today.
Rossen: See you all tomorrow for css.
TabAtkins: And I published an update to Typed OM.
(people happy)
Rossen: Meeting adjourned for the day.
Received on Sunday, 27 August 2017 18:33:45 UTC