W3C home > Mailing lists > Public > www-style@w3.org > April 2018

[CSSWG] Minutes Berlin F2F Tue 2018-04-10 Part VI: TTML Requests [css-inline][css-text-4]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Apr 2018 23:24:19 -0700
To: "www-style@w3.org" <www-style@w3.org>, public-tt@w3.org
Message-ID: <381836bf-7d74-6a73-067b-a1efd3ab1f12@inkedblade.net>
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

TTML Requests

   - RESOLVED: Add a text-group-align property to Text 4 with an outline and
               open issues on that text once it's drafted.
   - RESOLVED: Add a line-padding property as described in minutes to Text L4.
   - RESOLVED: Add a property (to be named) to css-inline to control padding
               of inline boxes. It inherits and has two values: normal and fill.


Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael

Outstanding Requests from TTML

Aligning an aligned block of text within its container

   github: https://github.com/w3c/csswg-drafts/issues/1975
   fantasai: If you load the first link the first issue you'll get the PDF.
   fantasai: Basic issue is you have a paragraph or a sentence. You put it
             in a box with a width constraint so it wraps. None of the lines
             of text are 100% filled. One is 80%, one 50% full.
   fantasai: You want text left aligned but the paragraph to be centered
             in its container.
   fantasai: We can't do this in CSS. TTML would like for us to be able to
             do this.
   fantasai: Different ways to approach it.

   TabAtkins: Line beak is between “is” and “enormous” in the example.
              They want text left aligned but once you have the line
              breaks center the group and then left align within the
              established center.
   astearns: Text can do this in a 2 line, they want this in a 3-line scenario
   TabAtkins: And any line might be the longest, not necessarily the first.
   Rossen: If we have padding auto, that's what they want.
   astearns: Not only centering.

   dbaron: Underlying feature is you want to re-shrinkwrap the width of the
           block after wrapping lines, and then figure out what to do with it.
   florian: This is a sizing thing or a text effect thing?
   fantasai: If this was laid out with css the left gap could not be here.
   Rossen: You're sure we can't with flexbox?
   TabAtkins: Yes. You need to re-shrinkwrap after linebreaking, and flexbox
              doesn't recalculate the size after linbreaking.
   myles: So you want to layout the first line, figure out the width?
   dbaron: Layout all the lines, figure out which is the longest, and then
           shrinkwrap around it.
   dbaron: You have a size, layout all the lines in that size, then change the
           width of the block smaller so that it's lined up with the widest.
   myles: Does floats make that real hard?
   dbaron: Probably

   TabAtkins: Proposal was a second level of text alignment where it's within
              the bounds of the longest line. Should be fine with floats,
              or at least well defined.
   dbaron: You'd have to do work to define what to do with extra bits.
   florian: Driving use case isn't floats driven.
   TabAtkins: And you don't need a second wrapper to get that.
   astearns: You and I, TabAtkins have the same solution, just properties are

   dbaron: I think what I described is what browsers did pre-CSS. Like
           Netscape 4 would narrow the backgrounds to match the longest line.
   astearns: To my mind what's happening is here you have a center-left
             paragraph. We lay it out as if it's left aligned, taking
             the longest line and centering the whole paragraph. I'm
             looking similar to text-align-last, I suggested
             text-align-inner whereas you say this is a centered paragraph
              by inner is left.
   florian: I saw it the other way around.
   astearns: I forgot how TTML asked.
   florian: I think Tab's version is better for forward compat. fallback to
            left is better then fully centered.

   TabAtkins: fantasai pointed out a further use case when handling some
              CJK typography where most content should be set solid but
              shorter lines are justified into that size. Right now you
              have to size the box in a multiple of the ic unit to get
              that to work.
   fantasai: That would solve a complaint from CJK that justification
             causes their lines to set too loose.
   florian: I think there is still advanced CJK alignment, but this gets
            us most of what they want.
   myles: This is center-left and you're talking center-justified?
   astearns: this is a text-align: left with text-group-align: center
   fantasai: And when there's floats you shift only as much as the
             shortened line would allow.
   florian: For TTML float interruption is unimportant, but in CJK we care.

   koji: So it's a group?
   fantasai: The question we have to think about is from TTML, if we only
             deal with one block it's probably good enough.
   florian: Per BFC instead?
   TabAtkins: I was assuming 2 paragraphs; there were use cases to have
              them the same. Don't cross BFC bounderies.
   myles: What happens if you put it on one paragraph of BFC?
   TabAtkins: It FCs the block or it's ignored because block is not a BFC.
   dbaron: Inherited or non?
   TabAtkins: Non
   myles: Put it on your BFC and hopefully authors knows what a BFC is.

   fantasai: I don't think it needs to BFC anything. If we're going to
             have a block, e.g. a section with a heading and 2 paragraphs,
             we want them to be handled as a unit. So the property has to
             be non-inherited and when you apply on a section it modifies
             line box on both sections.
   astearns: More complicated.
   florian: block and to descendencts
   fantasai: You break at BFC bounderies. But the block itself doesn't
             need to be a BFC.
   dbaron: It applies to all the lines that are in this block and its
           descendent blocks? Only traversing child blocks and not into
           the lines?
   fantasai: Right.
   dbaron: I feel like scope is similar to first-letter or text-indent
           for finding things? But those just look at first and this
           is looking at all?
   dbaron: ... never mind text-indent, that's inherited

   astearns: Before we go further into complicating we should ask the
             TTML people if they want to align paragraphs.
   florian: CJK does
   koji: CJK the whole block is one BFC and then we need to layout everything.
   florian: For CJK case I'm worried about floats.
   TabAtkins: [whiteboards floats]
   TabAtkins: Have big element and a floating picture and some text.
   TabAtkins: This block of lines having a shorter allowed line width is
              handled separately for the second block?
   Rossen: That would be horrible.
   fantasai: I don't think separate blocks.
   dbaron: Look at the exits, not the lengths.
   florian: floats are aligned to the box
   fantasai: no
   dbaron: So you have some excess on each line, figure out the smallest,
           and use that for the alignment.
   Rossen: But then add a float on the right side.
   dbaron: There's still excess on each line.
   TabAtkins: Excess you know whichever has the smallest because all the
              others can be adjusted just as much.

   dbaron: Suppose you're crossing multiple blocks and they have different
           text alignment. You block align it center, and you have a child
           with right align.
   dbaron: You accumulate excess on both sides and use the smallest from
           both. I think that's similar. If the left aligns have 0 and
           the right is whatever is the smallest. If you're then told to
           center you move the over by that much.
   fantasai: I was thinking alignment after the group alignment. You find
             out the amount to shorten by and then you shrink your line box.
             Then we center in the remaining space after we apply group
   dbaron: I think you're right.

   florian: Use cases to make it more complex then TTML wants are CJK.
            If we're not solving moving the alignment we're not solving CJK.
   astearns: I suggest we design this only at the paragraph level.
   TabAtkins: Won't work if there's floats for CJK. We want the extra
   [everyone talks]

   iank: We want smartness and things will be complex.
   ?: markers on lists
   fantasai: Marker offset on lists is with respect to the edge of the line
             with consideration of alignment, so it will move with this.

   astearns: Let's get the conversation to one person at a time.
   TabAtkins: I think this needs more design. I don't think we should agree
              right now, but it's good to get this in front of people.
   <dbaron> I think the CJK usecase requires the block-level thing that
            Netscape 4 did.
   fantasai: Before we consider restricting to single paragraph we should
             hear from TTML to see if it works for them. I think we have a
             good idea what we want to try and let's see if it works.
             I would suggest we draft the proposal into Text 4 and work it
             through as a part of writing.
   astearns: And having separate issues.
   florian: Most solve TTML, nice for CJK

   astearns: Add a text-group-align property to text 4 with an outline and
             open issues on that text once it's drafted.
   astearns: Objections?
   koji: Earlier someone mentioned creating an anon block?
   fantasai: I think that's more difficult for the mechanism.
   fantasai: Can you explain the use cases in the issue?
   koji: Yes.
   RESOLVED: Add a text-group-align property to text 4 with an outline and
             open issues on that text once it's drafted.

   astearns: And we'll talk with the TTML.
   fantasai: They're looking to edit.
    * dauwhe book folks will want to use this :)

Extending inline backgrounds to before-and after-edges of the line area
github: https://github.com/w3c/csswg-drafts/issues/1974

   astearns: In this one there is a PDF of what they'd like.
             There can be vertical gaps between lines that don't get a
              background color in CSS. They'd like to spec that the
              background should be extended to be contiguous even if
              there's a gap like this.
   TabAtkins: I don't like the magical background.
   fantasai: Should say it's the box.

   TabAtkins: Is this related to linebox size calc proposal?
   dbaron: Prob not.

   dbaron: One questions is what to do if box is bigger then the line gap.
   florian: semi-transparent you don't want transparency to pile up.
   <leaverou> what about background-clip: line-box? :)
   tantek: For borders you can do the cheap and ugly overlapping borders
           or the likely-wanted borders around the whole thing.

   astearns: My summary was insufficient. It's also extending background
             on both sides to half the gap.
   florian: Consistent with increasing height of inline box.
   dbaron: What if there's a tall image on one line?
   astearns: I asked about what if a float is in the way and they didn't care.
   smfr: Feels a little like how when webkit does selection and tries to
         eliminate selection gaps?
   TabAtkins: In float example I suspect that... it wouldn't be contiguous...
              first line is a little bigger but not touching. That's solved
              by inlines being the height of the line property.

   astearns: How to accomplish this?
   florian: inline-height: auto | fill
   florian: inline property with legacy and filled.
   leaverou: line box as psuedo element?
   fantasai: Wouldn't solve the problem.
   leaverou: Wouldn't line-height address it?
   TabAtkins: Inline box sizing wraps the content reasonably tight such that
              line height can produce gaps.
   leaverou: If there's a :line-box pseudo element wouldn't they be able to
             set padding?
   florian: pseudo element controls too many things.

   fantasai: Can we pause this and switch to next issue?
   fantasai: It's similar in the opposite axis, might be worth having both
             loaded into our heads to continue discussion.

line start/end padding
github: https://github.com/w3c/csswg-drafts/issues/1973

   fantasai: This one is an issue where they want padding at start and end
             of line, applied to innermost element at that point.
   fantasai: If you have a span broken across 2 lines, at the end of the line
             padding is inserted into the span.
   fantasai: With CSS you can wrap all the text but it gives you the last
             result, which is not wanted.
   fantasai: This is effectively the opposite of letter spacing. This is
             outside the letter on the start and end sides of the line.
   fantasai: Should be easy to impl, but we need syntax for it. I wanted
             to do this issue because it's easy to understand.

   TabAtkins: Am I imagining a difference in the black line from hello and my?
   fantasai: I think that's not intentional.
   TabAtkins: Okay.
   myles: If you have 2 nested spans do you use innermost?
   TabAtkins: It would be like letter-spacing where one wins on the letter
              that ends the line.
   florian: this inherits?
   fantasai: I think that's simplest.
   TabAtkins: Has to. Letter spacing but for the space where we don't put

   myles: Recommendation is at the tie you do the line breaking. You do
          this for the end of the line? Not sure how it works for beginning.
   fantasai: You look at first character on your line and before you figure
             out how big the character is and like that you have to go forward
             a bit.
   <fantasai> You take the line-padding value of that character
   astearns: They use line-padding as the avenue to control this.
   fantasai: We could introduce a line-padding property that has a longhand.

   florian: and if you're interrupted by a float?
   fantasai: It's between you and the float.
   dbaron: Are there interesting things with bidi?
   fantasai: no.
   dbaron: pre or post reordering?
   fantasai: post
   myles: there's always a character at the end of the line. Whatever element
          that's part of is what you consult.
   florian: If you're post-reorder you might get a different character at the

   fantasai: Alternative is have this apply to the block. Whatever block makes
             the line box sets the value.
   Rossen: Similar to the box direction.
   TabAtkins: Then you just shrink the line box.
   TabAtkins: Possibly make it not inherit.
   fantasai: You want inherit because you have anonymous block boxes. But you
             can put it on the block container at which point it's applied.
   florian: I think possibility of different padding based on bidi is not
            useful and complicates things quite a bit.
   TabAtkins: This does seem better. No drilling down and no bidi. I like this.
   fantasai: The property is inherited, but applies to block containers.
             When you do your layout you look at line-padding property of the
             line box you're in, which comes from the block container.

   fantasai: I guess we're resolved on that approach of having the property.
   astearns: Text level 4 again?
   fantasai: Yeah. Other option is CSS Inline. Not sure where it fits better.
   RESOLVED: Add a line-padding property as described in minutes to text level 4.

Extending inline backgrounds to before-and after-edges of the line area
github: https://github.com/w3c/csswg-drafts/issues/1974

present+ pal (via IRC)
   <pal> Just ping me if I can help.
   <astearns> pal, I believe we had some questions about TTML requirements
              in https://github.com/w3c/csswg-drafts/issues/1975 -
              could you review the minutes? (and ask me again if you can't
              find what I'm referring to)

   fantasai: In this case I think we need to apply to the inline.
   florian: I don't know if you need to but there's no complication on it.

   koji: We're talking about extending inline boxes height?
   fantasai: Only for painting.
   Rossen: Is it?
   fantasai: Yes, layout for inline boxes is based on line-height.
             We don't care about padding, margins, borders, etc.

   fremy: I put a link on IRC that's a website that tries to do this.
   fremy: I think how the did it is set some padding on the line and let's
          you extend the background.
   Rossen: They'll have overlap.
   dbaron: If you choose too much you cover up text in other line.
   Rossen: If you resize the window down to 3 lines you lose some of the y
   <leaverou> fremy, I've also seen it done with box-shadow to simulate
              line-padding, it's a very common effect
   fremy: They also used box shadow.

   florian: Are we discussing a potential property that switches the outer
            content height of inline boxes to be the height of the line?
   dbaron: I think border height.
   fantasai: Outer is margin
   florian: meant border.

   fantasai: Interesting thing is this is all elements on the baseline.
             What if I have superscript? I think what they would want is
             you're still going from top to bottom of linebox. Amount of
             extra background ink then differs between the top and bottom.
   fantasai: If we draw this and want to increase by x on each side, but
             if you have an element with different baseline you'll want
             to go from top to bottom of linebox. Normally when calculating
             the size of the background area you're going to use the size
             of the contents, your font metrics.
   fantasai: We're saying instead of doing that, ignore where all the text
             is, just find the line box edges and draw from the top to the
   fantasai: Should be clear regardless of the vertical positioning. The
             background doesn't move with the text.

   fantasai: Might be margin box you want.
   dbaron: No harm in the margin box because then it makes margin,
           could be useful.
   dbaron: Then you could inset some of the background.
   florian: It's commonly set in both directions because it only does
            something in one.

   TabAtkins: This won't be turned on by default.
   florian: I guess.
   dbaron: Also let's people make the border stick out by using a negative
   florian: Okay. I buy that.

   florian: Property with normal and fill?
   fantasai: Or add it as a keyword on padding property. Padding-top: fill
             so it means make the padding fill the line box if you're an inline
   astearns: Then you have to do it on each direction
   fantasai: You'd just say 'padding-block: fill' on the inline.
   <fremy> padding-top:fill sounds like align-content:stretch applied on the
           inline, with the line box as its bounds, rights?
   <dbaron> I'd note that this does introduce negative padding, which might
            be interesting...

   Rossen: I would the prefer this to be inline background. We can figure out
           what the bounds are. We don't have to implode padding or margin.
           It's a drawing effect. That way once we switch we can ensure
           there's no overlapping so when you're using semi-transparent it's
           always complete.
   Rossen: If it's only after rendering I would prefer higher level.
           Pushing this down to inline you'll have some times do it and it's
           more complex.
   fantasai: What makes it more complex to implement? On every inline you have
             to call the “paint your backgrounds function”.
   iank: This goes over the size of the line potentially.
   fantasai: You have to handle that for line-height already.
   iank: That's line-box size.
   fantasai: If I set my linee-hight to 10px and padding on my inline box
             is 10px above and below, I'll leak over.
   florian: Rossen your version, if the middle is top green and bottom
            yellow how to you know it doesn't overlap?
   Rossen: It doesn't. It's a simplification because it's one background
           behind all.
   fantasai: But they want different colors. Not just one element.

   koji: smfr pointed out we do that code for selection painting. The approach
         is like what Rossen suggested, it's easy to impl. If we go with
         padding it's more complex.
   fantasai: padding on inlines doesn't affect layout. It changes box size
             but does not move things around.
   Rossen: You can have tearing or overlapping.
   fantasai: You can already do the overlapping. I'm not sure how concerns
             about overlapping or not are valid.

   florian: When you do approach where your line height wasn't 20 pixels,
            it's possible you might get a bit of a gap in-between.
            Instead of sizing each individually you can edit as one shape.
   fantasai: But then what about when you do images?
   myles: Our selection does it piecemeal. We're very deliberate about how
          we round and floor. It fills pieces 1 by 1 and avoids pixel cracks
          with careful rounding.
   Rossen: If we leave to authors we'll have different rounding.
   astearns: We're saying design the feature at an inline level and impl
             deal with stitching together with the rounding errors.
             And it's what TTML is asking for in the issue.

   astearns: Do we follow TTML lead and call it fill-linegap?
   fantasai: No.
   florian: inline-box-sizing?
   koji: Sizing sounds like layout.
   florian: inline-height: normal|fill
   leaverou: Too much like line-height.
   astearns: Line-extend
   iank: border-outsets
   <leaverou> line-area?
   fantasai: You're not outsetting, you could be insetting.
   florian: inline-height and line-height are similar but if you're aware
            of both you won't be confused.
   iank: Not all webdev know all css properties.
   fantasai: line-gap-fill?
   astearns: Pierre suggests line-box-fill on IRC
   [quiet contemplation]

   fantasai: Thinking about to where we might extend there's a variety
             of metrics you might be interested in. Right now it's not
             entirely defined where the content box of the inline element
             is. You could want it to match em box, glyph bounding box.
   fantasai: Or match the edge of the line-box. There's several different
             values we might want at some point. You have a Zapfino
             heading and you want a highlight behind it.

   astearns: line-gap-fill-ink
   florian: If padding is applied to the outer padding goes in from there.
            Or we apply box-sizing.
   fantasai: Let's name the property. Fill value picks a value such that
             it fills the line box.
   fantasai: We need a name and it should be compatible with having
             different values in the future.
   fantasai: inline-sizing, kinda like box-sizing?
   florian: inline-height sounds fine to me.
   astearns: All the names implies changing geometry
   fantasai: We do change the geometry of the box. If you put a border the size of the border changes.

   <pal> padding applied using `padding` should add to the linebox
         fill... or not?
   astearns: [reads pal question]
   dbaron: replaces the padding I think. It's adjusting the padding
           to make margin edge line up.
   dbaron: Also introduces possibility of negative padding.
   florian: Do we only grow or also shrink is a separate question.
    * Rossen Mind the gap

   <leaverou> possibly silly question: would this be in addition to
              line-padding or instead of it?
   <fantasai> in addition, since line-padding is along the inline axis
   <leaverou> fantasai why not make it take 1-4 values as normal padding does?
   <fantasai> although we could theoretically combine them into one property
   fantasai: leaverou suggests
   leaverou: We can reuse line-padding and have it take 1-4 values for all
             directions and have a fill keyword.
   fantasai: I think... if we had a fill keyword with 1-4 values, what if you
             apply it to the inline-start edge?
   leaverou: I'm not sure.
   fantasai: If you have line-padding-inline-end: fill on a short line the
             color goes all the way to the edge. That's not unreasonable.
   myles: And that's on a span so it's only to the end of the span if there's
          a linebreak?
   fantasai: Only if it's the end of the line.
   astearns: If it's in the middle it goes to the end of the span.
             If the span ended a line it goes to the end of the line box.
   myles: Line break in the middle?
   fantasai: If the span is in the middle and there's text at the end there's
             no effect. If the span breaks or is last thing the background
             goes to the end.
   myles: You have to look at deepest span?
   fantasai: In fill case... yeah. Yeah. You'd impl as adding extra space
             and all the spans extend to the end of the line. Won't affect
             position, it's just paint.
   florian: Confusing if there's whitespace with a different span at the end?
   fantasai: If you use white-space: pre that's your fault. You wanted spaces
             to be significant.

   astearns: I think we have vague consensus on an approach. Is this in Inline?
             Would be nice for all TTML in one spec. Others are in Text L4.
             But this is more inline then text.
   astearns: Prop: Have a line-padding shorthand with all the attendant
             longhands that, in addition to lengths, takes a fill keyword.

   leaverou: Can we have a background-clip keyword that makes it so they
             don't have to wrap it in a span?
   fantasai: What element has the background?
   leaverou: Heading and you want to apply the linebox to the heading but
             you don't want to wrap the heading in a span.
   fantasai: You want a pseudo element for the root inline.
   leaverou: A new pseudo is more complex to add.
   fantasai: This is for a box that exists, probably not that bad.
   leaverou: Why can't we use padding on that rather then a line-padding
   fantasai: Padding is applied to innermost span, not outermost.

   <pal> applying padding at the end of the line may result in wrapping
   <pal> ... and need to be applied as part of the line layout algorithm

   florian: I thought we had normal and fill and you said lengths and fill.
   fantasai: This use case for inline needs lengths.
   florian: They apply to different things.
   myles: Instead of new property why wouldn't you use line-height to move
   fantasai: Not changing layout which is what line-height does. We're
             changing how box is painted.

   myles: what does length do?
   fantasai: We discussed adding space, like letter-spacing, to the start/end
             of the line. That needs length. Then we discussed how to fill
             distance between edge of box and edge of linebox, and that takes
             keywords. leaverou asked why not have a single set of 4 properties
             that solves both use case.. But we're not sure we can.
   florian: One was described as working on block and the other on inlines.
            fill could be made to work in both, but let's not. It looks like
            2 sets of 2 things
   astearns: Prop: A line-padding property?
   myles: It's valuable to not conflate properties that mess with layout and
          ones that mess with paint

   fantasai: line-padding was for the letter spacing type thing. I think
             line-padding is a fine name.
   fantasai: We need a name for the one in the other axis.
   fantasai: That's changing how we size the box for painting purposes.
             We've got normal which is what we do now and fill the line box.
   myles: Changes vertical alignment?
   fantasai: It does not.
   florian: We might in the future want to separate extending top and bottom
            side independently.
   fantasai: I think we'll start with one value for both of these.
             If someone wants different we can split later.

   myles: Background will paint outside of the boxes the spans create?
   florian: You're extending that.
   fantasai: That box has no effect on layout in vertical. It's only about
   fantasai: It doesn't change where the text is for that or any element.
   florian: And you can already set the border.
   leaverou: We're trying to come up with a second property name for the
             fill keyword, why not work in one direction?
   astearns: I think we're at the point where we can't combine the effects
             because where we're adding them in the inline axis is applied
             to the block container and fixing the gaps can't.
   fantasai: Also one takes lengths and the other keywords.
   florian: And we are only missing a good name.

   astearns: Prop: A property to be named that applies to everything, with
             2 values, normal | fill. It inherits and applies to inline boxes.
   <fantasai> and might take additional keywords in the future

   florian: Remaining question for that property is if you have enough borders
            it would shrink into the text and then what?
   florian: If you have 20px height and 30px borders, did you ask for that
            and that's your problem?
   dbaron: Related to the can it go negative question.
   fantasai: Overflow doesn't apply to inlines. Border goes behind the text.
   fantasai: Which is reasonable in a lot of cases. For the layout area you
             might want to have negative padding to get things to look the
             way you want.
   <fantasai> The glyph area of a character might be significantly smaller
              than the em box
   florian: Okay.
   florian: Do we need to define borders are behind the text or is that clear?
   astearns: I think next step is get this in the draft.

   astearns: Objections to having this property?
   RESOLVED: Add a property to be named to control padding of inline boxes.
             It inherits and has two values: normal and fill.
   astearns: Added to CSS Inline. Ideas on names are welcome.
Received on Friday, 27 April 2018 06:24:50 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 06:24:51 UTC