- 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
=========================================
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.
===== FULL MINUTES BELOW ======
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
reversed.
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
alignment.
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
shrinkwrapping.
[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
letters.
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
end.
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>
https://www.bloomberg.com/news/articles/2017-09-20/google-is-said-close-to-buying-htc-assets-to-bolster-hardware
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.
[whiteboards]
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
bottom.
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
margin.
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?
<pal>line-box-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
property?
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
lines?
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
painting.
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