- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Jun 2014 09:06:31 -0400
- To: www-style@w3.org
Box Alignment
-------------
- fantasai brought the group up to date on the changes including:
- New last-baseline value (in addition to baseline value)
- explanation and details of baseline alignment concepts
- additional notes on vertical-alignment property
- a bit more work will be done before the request for a new WD
Box model / Render tree
-----------------------
- TabAtkins, with additional input from glazou and plinss, told
the group about question of further exposing the box model
that was originally brought up in a conference with react.JS.
- The were a few members that were very interested in beginning
work on doing a better job of exposing pieces of CSS, though
not necessarily exclusively in the direction requested by
react.JS. These WG members will begin to put together ideas
and potential solutions.
-webkit-line-clamp
------------------
- RESOLVED: put max-lines property that behaves like max-height in
the line grid module
- RESOLVED: work on block ellipsis problem independently
==== FULL MINUTES BELOW ======
Full Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael
Box Alignment
-------------
<astearns> http://dev.w3.org/csswg/css-align/
plinss: Let's start again
plinss: Next is Box Alignment.
[pause for stragglers]
plinss: So box align.
fantasai: More baseline stuff!
fantasai: Give me one second.
fantasai: The box align stuff we worked on is the baseline section.
fantasai: There had been some discussion about having the
ability to align to first or last baseline.
fantasai: For example you have a bunch of tabs across the top of a
page, you might want to align along the last baseline,
not the first.
fantasai: To allow to switch we have added a last-baseline value
to the alignment properties.
fantasai: Alternatively we can do first-baseline + last-baseline.
fantasai projects: http://dev.w3.org/csswg/css-align/#baseline-rules
fantasai: In order to handle all the baselines that exist, what we
have is we define that instead of a single baseline, you
have an entire baseline table that you take and propagate
up through the containing block tree.
fantasai: An example: if I'm in a block inside a table cell in an
inline table the first line of the block will set the
baseline where the inline table will align to the
surrounding text. Since as the block we don't know which
type of baseline (alphabetic, central, hanging, etc) the
inline table wants to use, we propagate them all out.
fantasai: We wrote the text with those concepts and explained for
block containers how you get that.
fantasai: We also defined baselines for table columns, so you'll
have baselines along the block axis when needed in
orthogonal flows.
fantasai: For flex and grid containers we were referring to those
specs, but we realized that flex needs a lot more detail
than is currently there.
fantasai: The other thing we haven't handled yet is if you have
multiple baseline-alignment groups.
fantasai: If you have two sets of baselines, this section needs an
update.
fantasai: There's also the case of opposite writing modes where if
you have, say, Chinese and Mongolian text where the
first baseline of Mongolian is on the right, the first
baseline of Chinese on the left, but letters are
oriented in the same way.
fantasai: If they're oriented the same way, maybe you want to
align them together.
fantasai: Any input/comments/examples would be great.
fantasai: That's where we got. My goal is to complete this and
then publish a new WD.
fantasai: For terminology we added a some terms to talk about
alignment: alignment subject, alignment container.
fantasai: For baseline alignment we added more terms.
fantasai: Baseline sharing group and concepts of sharing an
alignment context so when you're aligning to
each other you know what you're aligning to.
fantasai: We tried to make that clear and explicit.
fantasai: That's that. Do people have comments/thoughts/complaints
about terminology?
fantasai: One thing we did formatting-wise was add an HR/seperater
in several sections, to separate things you might want
to read if you're an author vs. things that you won't
ever want as an author.
fantasai: We also added a note that the vertical-alignment property
will need a 'first-baseline' value that's different from
the 'baseline', because in CSS2.1 'baseline' uses first
or last depending on if it's an inline bock or an inline
table.
TabAtkins: That's it.
plinss: Okay. Are you ready to publish an update?
fantasai: Now?
TabAtkins: I want another day to work on baseline.
fantasai: That's where we're going, though.
fantasai: I think the key idea for future specs is, when you're
dealing with baselines, unless you're doing an alignment
right there, you want to hold on the the whole baseline
table. This is true here and for line grid. Line grid
does that, too.
Box model / Render tree
-----------------------
fantasai: Next topic.
plinss: Box Model
fantasai: That wasn't me.
TabAtkins: Who added it?
plinss: It's been on since the extensible web summit.
TabAtkins: I can talk usefully about some of the feedback in the
vein that these are interesting things.
hober: Bert wanted to call for this.
clilley: It's 10 to 9am in France
plinss: We won't get a better time.
TabAtkins: Are we ready?
plinss: No sign of Bert.
TabAtkins: Okay.
TabAtkins: The biggest part of this discussion was mainly with the
react.JS folks.
TabAtkins: They do a standard thing where the DOM is projected and
you don't deal with it in your application.
TabAtkins: The things on the DOM side are about elements with odd
hidden states, but on the CSS side there's insights.
TabAtkins: It possibly involves doing an exposed render tree.
TabAtkins: The idea is in some cases, react.JS would be happy if
they can do everything in web GL.
TabAtkins: They can't do that because various bits of our things
that have been required for years, but if most of the
page could be a custom renderer and they got into HTML
for a handful of things.
TabAtkins: Problem is we're just doing a canvas that's a black box
and can't interact with the page.
TabAtkins: They can't tell the browser this is floated, give me
your ideal size.
TabAtkins: The best take away is it would be useful to define a
layout API that we implicitly lean on for layout so an
arbitrary JS could hook in and provide the information
requested.
TabAtkins: So it can make things masquerade as if they had
intrinsic sizing.
TabAtkins: I don't know what that would require to expose, but it
seems it would be a small interface.
TabAtkins: Probably between 3 and 5 pieces from a block, min/max
content and preferred size.
TabAtkins: And have a few ways to call in, either just provide
information from CSS or provide information CSS can ask
for like "I'm going to render you in min content", tell
me that.
TabAtkins: Putting it there isn't great, but we can define the
minimum a block needs to expose to provide layout.
TabAtkins: There was talk about explicit tree exposure and I
didn't deal with that as much. plinss and glazou did.
plinss: The premise there is the expose the box tree that we know
is there and don't talk about and start exposing folks
into layout to do real polyfills
plinss: The gist is to deprecate presentational APIs and have APIs
in the box tree to get presentational data.
plinss: We need to formalize what is a box. These are all things
that have been always there, but not documented.
plinss: I'd like it to be documented and have exposure.
TabAtkins: Earlier we talked about fragments-based styling and we
had an issue that getComputedStyle doesn't work. If we
expose something like a render tree we can get a
coherent idea of the style.
plinss: We can get the list of fragboxthings and than get the
computed style on that.
plinss: Then we can stop exposing these lies in DOM APIs.
plinss: We've been talking for years. I want to say let's just
do it.
TabAtkins: I think we should.
dbaron: There's a bunch of hard problems. When do you get the same
object and when do you get a different one? We don't
promise anything about permanence.
clilley: Does the return point to the actual object?
plinss: There's no way to get it.
clilley: If there's a copy that's fine.
plinss: That's a rational way to make this work.
plinss: We shouldn't just rewrite interfaces on this thing. I also
don't want to expose peculiarities of layout.
hober: That's 80% of this feature
plinss: I want to expose the results.
Rossen: And you're assuming an specific implementation that isn't
in our implementations.
Rossen: There's things we can look to expose in specific cases,
but saying you want to expose box tree or render tree is
going a bit further than what all implementors could
agree on.
dbaron: I think the idea of exposing a read only copy is also hard
because if you're going to expose child lists and tree
navigation because that implies you need to make a copy of
the whole tree if you want any piece.
astearns: This is something Mozilla already exposes in their
developer tools diagram.
dbaron: Not really.
dbaron: I'm not sure what diagram you mean, but we don't really
have APIs exposed to dev tools for getting this.
plinss: I don't want to pick an implementor and say this is what
we need you to expose, but I think there's a rational
subset that can be exposed. I don't want to just throw up
our hands and say this is hard.
hober: I think there are several boxes that we have no way to get
at and might be reasonable to expose. I think that's a tiny
fraction of what the people asking for this want.
plinss: react.JS is asking for something different. I'm not
talking about satisfying them completely, but doing
something for everyone else. If people do hit testing on
the tree it doesn't work.
hober: I agree we have a problem with hit testing. I think the
problem is that we never defined hit testing.
plinss: There is a hierarchical geometry that makes hit testing
work and why can't we explain it?
plinss: You don't have that in IE?
Rossen: That's not easy to expose.
hober: Expose and explain are different.
plinss: So what's the answer? There's nothing we can do?
hober: This is enormous.
plinss: I'm not saying it's not. I'm not saying it won't expose
things people can shoot themselves in the foot with. This
can't be impossible.
TabAtkins: I think we can bite of less enormous chunks.
hober: We're less likely to do that. We need to define what boxes
we need to get at and we should do that.
hober: If you have an inline and a block as siblings, there's an
implicit box and being able to get there is reasonable.
Rossen: If you have it. Some implementations don't.
plinss: Can't you synthesize a way?
dbaron: With all the margin collapsing?
plinss: You have to have computed it.
Rossen: A lot is transient.
hober: I brought that up because it's already specced. This box is
explicitly described, but you can't get to it.
dbaron: It's in spec, but not in implementation. It sounds like we
have 2 implementations where it doesn't exist, though we'd
like to add it.
hober: There's the most obvious case and that's already a problem.
dbaron: The change to generate that box is months of work and
there's a whole bunch of others to make our render tree
match what the spec says it looks like. Then we could
think about exposing it.
plinss: No one is saying this'll get to rec in a month.
hober: Seems like cost/benefit analysis is weighted on cost.
plinss: I think we're not looking at the benefit right. There's
lots of things people can't do in script.
hober: So we should go case by case.
Rossen: So are you saying the primitive you expose isn't enough?
So authors are using block and can't do what they need to
today?
plinss: Yes.
Rossen: What's an example?
TabAtkins: One is the knowledge of how text is broken and laid out
in an element. Given a piece or geometry and and array
of text/elements, give me the layout.
plinss: The holy grail here is what we don't know what people want
to do. It's polyfills. We'll spec something a year from
now and a major browser says this is hard and will take
too long.
plinss: And people can't get the data we need to move things.
glazou: We also discussed this API in conjunction with portability.
glazou: So put the type into JS if you don't want to remain at the
selector, you need this.
dbaron: I don't know if that helps as much as the API TabAtkins
spoke of. You'll still need that.
glazou: Probably.
plinss: I think both.
dbaron: That depends on complexity. I'm not convinced you can't do
these things without TabAtkins's layout-exposing API plus
what we have not.
plinss: What I'm trying to solve is there are so many things in
the web platform, there's a cliff where you have to
re-implement 90% to add your bit.
hober: And we should aim to improve over time to make that
situation better.
plinss: This is opening up the black box that's CSS and stop
keeping it in there. It's big. It's not a minor thing we
can do piecemeal.
plinss: We have to decide if CSS is magic and unicorns or if it's
explained.
hober: I think if we can do something like how web animations work
we can explain how that works in a CSS model. That's not an
expose all the CSS model in an API.
plinss: But that's just something on the side of the black box.
dbaron: This is a change similar to creating the DOM.
dbaron: I think when the DOM was created there were substantial
changes to how things worked.
dbaron: It was a new architecture that the new stuff was mapped
onto, but it wasn't how the old stuff worked.
dbaron: Given how much of a mess CSS layout is, maybe we should do
new fundamentals.
plinss: I'm fine with that approach that we design a rational
system.
hober: That sounds experimental. Why not do this within a
community group?
plinss: Because the experts are here.
dbaron: I think it needs a group of a decent size committed to
working primarily on that thing.
shans: You can do something like web animations did with a
dedicated group.
plinss: I'm fine with that. I don't want to dictate who, I want to
see it happen.
glazou: I think so too.
glazou: We discussed this once with a JS based extension. We won't
be able to do it correctly.
plinss: So are there people willing to work on this?
plinss: Don't all volunteer at once.
plinss: So define something. Define the beginnings.
glazou: I'm happy to work on that.
shans: I'd be interested, but I don't know if I have the
expertise for it. I'd certainly join a group.
plinss: Are you all willing to go back to your organizations and
have internal discussions and see if there are people
willing to come work on this?
hober: I assume everyone goes back after a F2F and has a
conversation about the topics and this is one of those
things.
plinss: I'd like to have an inkling of a next step.
TabAtkins: Next step is someone interested, me and shans, start
drawing ideas and maybe experiments in code.
shans: In the JS model initially.
TabAtkins: Yeah.
plinss: Alrighty.
plinss: Anything else for today?
plinss: We've exhausted today. We can pull something from tomorrow.
TabAtkins: I can do -webkit-line-clamp.
TabAtkins: If people haven't heard of this...
-webkit-line-clamp
------------------
<dbaron> http://dev.w3.org/csswg/css-overflow/#max-lines
TabAtkins: -webkit-line-clamp is a strange proprietary feature in
webkit but based on the old flexbox model.
TabAtkins: You specify an integer and it only displays that many
lines. It has to contain text and you limit the lines.
TabAtkins: Better than having to guess at the line height.
TabAtkins: It's useful for aligning text.
TabAtkins: You can display a useful amount of text without odd
guessing games.
TabAtkins: I'm interested in putting this into a spec that's less
crazy since it's not related to flexbox.
TabAtkins: Maybe line grid.
dbaron: It's similar to the overflow fragments proposal, though
the point was to say a fragment would contain this many
lines and than flow into the next fragment, but it seems
reasonable to do this.
astearns: In the clamp-fragment case you don't want to have the
elision marker.
dbaron: There's also a discussion about text-overflow: ellipsis
and lines.
TabAtkins: That would be set separately.
dbaron: I don't know if what I proposed is right, but I think the
lines might be useful for whatever it ends up being.
TabAtkins: I love the name.
TabAtkins: Sounds great. I'm happy with this.
TabAtkins: We just say this also works for overflow: hidden and
I'm golden.
TabAtkins: It breaks after that many lines.
fantasai: It should just limit the height, exactly like max-height.
Rossen: That's the overflow behavior.
TabAtkins: It means the intrinsic height, the auto height, is that
many lines.
Rossen: The behavior for block-overflow: ellipsis derived the
number of lines. Instead of specifying the number of
lines you'd specify the ellipsis and the first line that
overflows and subsequent lines gets dropped.
fantasai: Why can't this work like max-height?
Rossen: How?
dbaron: I think it could.
fantasai: It's simple, and you overflow unless you specify
overflow: scroll and if you want to clip, scroll or
fragment you can.
fantasai: Why make it more complicated?
hober: Makes sense.
dbaron: Or it's a unit on value for max-height.
dbaron: But I wouldn't want to figure out fractions.
TabAtkins: Plus each unit is variable size.
hober: To me the min/max height are talking about a continuous
length of very small dimensions with an amount of px and
this is more discrete.
astearns: So how would it interact with min/max-height?
TabAtkins: I think it should just affect auto-height.
fantasai: You want it to affect margin collapsing like max-height.
hober: Or it doesn't affect height, just wrapping.
fantasai: But then you can't decide that you want a scroller.
TabAtkins: That is true.
fantasai: We have this behavior for select boxes already;
you can't express that well.
fantasai: This takes care of that problem.
TabAtkins: That's an interesting way.
fantasai: Also <textarea>, how many rows, that number.
TabAtkins: Width is already in chs.
TabAtkins: Okay.
TabAtkins: I have to think about consequences, but I think that
something like this not intrinsically tied to fragments
is good.
fantasai: You can pull this into line-grid which would account
for it.
TabAtkins: Then there's the concept in webkit the prop triggers
the block overflow ellipsis.
fantasai: That should be separate.
TabAtkins: That's what I thought. I had a property for a slightly
more complex, but this is text-overflow: last-line.
hober: I want us to be able to solve things with properties that
aren't awfully named.
TabAtkins: We'd have to make it a vertical flexbox...who knows...
fantasai: That's so weird.
TabAtkins: That's all I wanted to talk about.
hober: So do we have a resolution that people want to solve that?
RESOLVED: put max-lines property that behaves like max-height in
the line grid module, work on block ellipsis somewhere
else.
[end of day]
Received on Wednesday, 11 June 2014 13:06:59 UTC