[CSSWG] Minutes Seoul F2F 2014-05-20 Part IV: Box Alignment, Box Model/Render Tree, -webkit-line-clamp

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