- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Nov 2018 19:36:06 -0500
- To: www-style@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.
=========================================
CSS Inline/Line Layout
----------------------
- This telecon was dedicated to beginning to work of a Line Layout
task force that will work on developing a new line sizing model.
- The possibilities were gathered into potential spec text in
order to create a starting point for discussion:
https://drafts.csswg.org/css-inline-3/#line-sizing-property
- Questions and concerns were gathered in Issue #3199
- A new issue will be opened to dive deeper into how to handle
interactions with Ruby reserve.
- There was interest in making sure that the handling of Ruby
reserve is well defined and not a mystery.
- Having a property to ensure there is enough space on the first
or last line if the author thinks they might have a Ruby in
their paragraph was also of interest to solve.
- There were two main models proposed, 'better behavior' and 'box
model behavior'
- Better behavior is "Line boxes are sized, and content
positioned within them, as defined in [CSS2], except that
positive half-leading is not applied to any box other than
the root inline box."
- Box model behavior is "Line boxes are sized to fit the root
inline box and its half-leading, as well as the outer edges
of any inline-level descendants in the same inline
formatting context. Positive half-leading is not applied to
any other inline box; negative half-leading is applied as
negative margins to inline boxes whose block-axis margins,
borders, and padding are zero."
- The group didn't think both were necessary. Of the two, the
preference was to focus on the box model behavior.
- There was also 'absolute behavior' listed but it was captured
to make sure the proposal listed all options and no one
believed it was the right path forward.
- Similarly, there was no desire to add the 'quirks' behavior
proposed.
- line-height:normal compatibility needs to be addressed in this
proposal. The current behavior works well so there's an interest
in making sure it stays.
- fantasai will re-write the proposal with two options, 'legacy' and
'normal' where 'legacy' is the as-is behavior and 'normal' is
the 'box model behavior' explained above.
- The box model behavior will be re-written to unconditionally
have negative padding adjust the content box (An issue will
be filed to track this)
- The normal property will apply to inline boxes (An issue will
be filed to track this)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Nov/0031.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Nigel Megitt
Michael Miller
Anton Prowse
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Scribe: dael
CSS Inline/Line Layout
======================
astearns: We should get started
astearns: Welcome to the first line layout TF call
astearns: If you didn't notice the email, we're only doing CSS
Inline today. If you're not interested feel free to drop.
astearns: Any changes to the agenda?
fantasai: Interested in resolving to publish box module and break L4
astearns: We can do next week since we did say people don't have to
call in and I'd like to do publishing with the full group.
astearns: Is the order the issues are in good? I tried to make it
most to least important.
fantasai: Conversation we left off with last week was trying to
figure out a switch into better line sizing model
astearns: Continue on that or smaller issues first?
fantasai: That needs more exploratory conversations
Proposal for a better line sizing model
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3199
<fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property
fantasai: This is a very rough draft. I wanted to document what we
had discussed in the past.
<fantasai> https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking
fantasai: Also dbaron's original proposal ^
fantasai: Then other discussion listed in issues
fantasai: Main goal is try and control jitter on the line and also
make sure line box sizes are consistent and baseline
position is consistent across line boxes.
fantasai: In common cases. If there's a giant image maybe it grows.
This is where you have same font size, but you change font
family midway you create jitter. As long as author has
given adequate line height it shouldn't cause line box to
grow.
dbaron: Reason to want stable line heights separate from stable
baseline patterns?
fantasai: Mainly stable baselines. You can't see edge of line box.
If line box is same height but baseline changes it makes
jitter. This isn't wanting a line grid. That's a separate
issue.
astearns: This is more about having a vertical rhythm within an
element
fantasai: Right
nigel: Is this considering Ruby height?
fantasai: Current way Ruby is defined to work is if you have enough
leading that double that would create enough space for
Ruby you don't increase line. Line to line is half above
and half below.
nigel: Ruby is in the line area
fantasai: Typically half in line box and half outside. Assuming
previous line box with space
Rossen: Which is one of the problems because everyone does something
with first line and last. Hopefully can do better here
fantasai: For Ruby you want to make sure enough space. When doing
first or last line you don't want to consider Ruby when
placing because you usually have enough padding. Leading
trim property discussed at F2F as to where you consider
top of line to be. That excluded Ruby so lets you place as
people expect
fantasai: If we want a switch that includes Ruby that's a different
switch.
fantasai: I think most of the time people are asking for Ruby to be
excluded so they line up
nigel: My expectation seems different. If you have or might have a
Ruby before you want to make sure line space is big enough.
Same with after. Have to be independent of content before. In
the case of a caption where text keeps changing need to make
sure baseline appears in consistent place whether or not Ruby
appears
fantasai: For captions layout rules are slightly different then
documents. Doing that we would need some way of saying
leave this much space, but only on the top. Right now
extra space is applied top and bottom
nigel: Exactly, yes
fantasai: That would probably have to be separate property. You'd
want to say add this much extra space but only here
nigel: Before or after or both. A first and last line selector that
adjusts it so you can be clever about where you put Ruby.
<myles> Can’t have last line pseudo because it’s contents can change
what the last line is
fantasai: nigel is that issue filed?
nigel: There was question about Ruby reserve. I have to go hunting
fantasai: We need to think about that more. but I think it's a
slightly different discussion. Might end up interacting on
same property.
fantasai: Does make sense we need to solve.
nigel: One outcome we should aim for is if we include Ruby reserve
or not it's clear which we do. If there's a way to add Ruby
reserve does it add line sizing? put a wrapper? need to be
clear whatever the model is
fantasai: Might be able to add values to leading-trim property we
discussed. It adds space instead of trims
fantasai: nigel can you file and issue?
<nigel> -> https://github.com/w3c/csswg-drafts/issues/3240
[css-inline] Leading control at start/end of block #3240
<nigel> -> https://github.com/w3c/csswg-drafts/issues/2998
[css-ruby][css-text-decor-4] Add over-most-under-last value
to ruby-position & text-emphasis-position for captioning
#2998
nigel: There was a TTML issue I put in IRC. Probably closest we have
nigel: Doesn't include reserve so that's the issue that needs raising
nigel: Happy to raise it
nigel: You think that Ruby reserve should be in leading control?
fantasai: Might make sense. Should look
nigel: In Ruby?
fantasai: In CSS Inline
fantasai: Discussed at TPAC and decided to add the property
nigel: 3240 perhaps?
fantasai: Yes, that's the one. Haven't edited it into spec yet
nigel: I'll raise an issue
<nigel> -> https://github.com/w3c/csswg-drafts/issues/3351
[css-inline][css-ruby] Allow ruby reserve space to be
allocated #3351
<nigel> I raised the issue above in relation to the ruby reserve
conversation.
fantasai: I think the main thing we need is a behavior where we
ignore the line-height property on any inline level boxes.
So other than root inline. Continue to height only if
leaking outside of line height set by root.
fantasai: That would solve a lot of the cases. Might be possible to
just do it.
florian: The better behavior and the box model behavior are they
distinct because different use cases or because one might
be able to be a default?
fantasai: Different behaviors.
fantasai: I don't know how useful box model is, but it uses margin
box of inline boxes
koji: Can you describe difference?
fantasai: Current line sizing model takes the root inline and
applies half leading. Every inline box ignores margins,
border, padding and instead uses line height to calc
leading. Makes sure line box includes text content and
leading above and below
fantasai: Box model behavior doesn't use line height on any inline
element. It uses margin edges and uses that as the sizing
box and tries to make sure line box is big enough to
contain all margin boxes.
fantasai: Right now we ignore margin box for inline boxes
dbaron: Almost feels like it's not clear to me the use case for
better behavior rather then box model behavior. Seems silly
to not include a border if you have one. If you want to not
you can use negative margin
florian: I think that's what I was thinking. You probably want
either of those in similar cases. Might want better
behavior over box model behavior only because we might be
able to make the better behavior a default. If we can't
make better behavior a default might not want it
dbaron: I'm not sure risks are different between.
florian: I'm not sure if there is a difference.
<dbaron> I guess the risk is that it's more different from the
current model
fantasai: I listed everything we've discussed so we can talk about
what we have.
fantasai: If we think box model behavior is better we can do that
florian: On that train of thought, if we think better behavior might
be usable as a default would anybody be willing to try as
an impl and go first? Or is it jut a thought experiment and
we don't need to consider it.
dbaron: Skeptical about making any of them the default
myles: With dbaron. I don't think we'd impl first to make them a
default
astearns: Concern over unknowns? I assume first someone would impl
and see what edge cases before any consideration of trying
as a default.
gregwhitworth: I think you impl first. Similar to how we allow
border box sizing to change. Let authors use it. If
it goes well we can do a trial as the default
gregwhitworth: What authors are begging for this? I heard a few use
cases. Is it high demand?
fantasai: People paying attention to typography are frustrated that
even within a paragraph where the font size doesn't
change, the baseline-to-baseline spacing is inconsistent.
dauwhe: I'm horrified that a superscript breaks line height
<nigel> +1
<astearns> +1
myles: Gotten many requests of people interested in line layout for
typography. They have baseline to baseline metrics from a
designer and there's nothing they can to to make that happen
<jensimmons> There are entire books written about how to deal with
the stupidity of the defaults. People who care about
typography & graphic design are intensely frustrated
with the status quo.
florian: Asked about default because if neither can be default no
reason to have both. Probably box model over better
behavior. If we can have a default maybe cause for both.
But it's not obvious we do.
florian: Absolute behavior seems more risky. That makes sense as
separate. Also wondering if this is a value where authors
think it's right and on the user's computer something is
different and there's overlap
fantasai: Very skeptical absolute behavior is right to add. Creates
a large risk of things going wrong. I added it for
completeness. Def not first edition.
florian: Quirks is different behavior. Is there request for opting
into quirks separate from being in quirks?
fantasai: Don't think so
myles: No.
<tantek> Agreed. the quirks behavior here is crap. never heard
anyone ask for it deliberately. though hard to tell since
it's a default :(
florian: Seems we could have 2 values. Current or Quirks and the
other being box model behavior
fantasai: Legacy and normal?
florian: Yeah.
florian: dbaron I think you explored a proposal with finer
granularity. Are there variants you thought useful not here?
<fantasai> dbaron's proposal was
https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking
dbaron: It's possible there might be some cases where you want...if
you need something like image-like text you might be okay
with them extending. Pretty edge case-y
myles: We try to tell authors not to have image like text. Or other
way around.
fantasai: dbaron's proposal had sizing around glyph bounding block.
Sometimes useful. One way to incorporate is have it in
inline sizing. Be able to switch and say this box uses
glyph bounding. This switch will inherit through entire
doc and it'll be just this box needs glyph sizing.
fantasai: That's the value I think prompted webkit to impl. Mainly
to allow a box to pick up less space. Larger font size
with capital letters it made the line increase even with
no ink
koji: No strong preference between better and box models. Agree
better to start with two values.
koji: Question: What do we do for line-height:normal in the case
where all browsers correct. We correct for the containment box
florian: Can you remind me in what way it collects things across
elements? I remember line-height:normal on a single, but
not on multiple
koji: We unify all the metrics so that all fonts are considered in
the height. Then the inline box height is included in the
parent height. Since we're only taking root line box I guess
we need to change to treat all
myles: 2 desires. If there's content in the middle that's really big
you want increase. A little bigger you don't want. We need
rules to distinguish the cases
fantasai: The better behavior and box model are supposed to have it
be that if box leaks outside line box we increase size of
box. Leading means if you're only a little bigger you'll
fit inside unless you've got a really tight line height.
Both break down on how they handle maintaining font size
and changing font family. Normally you have enough leading
for that, but if you're setting line-height:1 it'll create
jitter and I'm not sure how to handle that case.
nigel: Targeting avoidance of jitter between paragraphs?
fantasai: Mainly within.
nigel: Typesetting you might have 2 paragraphs, one with a
modification that adjust the line height. If it has
paragraphs on other side it looks weird if other paragraphs
have different. Typographic is here's my line spacing, use it
everywhere.
fantasai: That's what we're trying. It's the same as when we have
multiple line paragraph and only one line grows. We want
to solve that and related cases where there's content that
fits within the space but also when you try and include
leading and there's already leading
astearns: Might be good to add to draft text here are the cases we
want to address. And here are the ones we're not fixing
like an inline block with different line height.
fantasai: Inline block is like an image in this case. We don't know
what's inside
florian: What we just discussed answers koji. line-height:normal
shouldn't do anything special with looking at font metrics.
If they do stick out line height increases. Shouldn't do
anything different there then numeric values. Then we'd
have the problems where have different line heights because
different font
fantasai: Normal should behave as 1.1 or whatever it resolves on on
the root inline. Take the value off the first available
would be a reasonable behavior
koji: I think I like current, not sure it's well spec. Current impl
of line-height:normal that takes all points. Doesn't give
consistent but it makes text legible.
fantasai: If author wants consistent they can set a value.
myles: Valuable to take all used fonts into consideration. Could be
all text comes from font far down list. But if we do that we
get jitter. Sounds like we want to figure it all out and then
layout, but that's 2 pass and prob too slow
fantasai: What if you ran calc based on all available fonts.
Whatever you have in system. Prob too many fonts
koji: [missed]
myles: We create objects lazily so we're halfway through paragraph
before realize have to create a font
myles: Either before layout paragraph you have 0 fonts or you layout
twice. Or anyway do 2 passes
astearns: Seems to me kind of consideration koji said where look at
whole line and metrics and decide what to set that happens
after root inline box. You choose root inline box and for
every actual line you look at used fonts, figure out
metrics, and see if fits in root inline. If it does, no
change. If it doesn't, line may increase in height
florian: I think I'm with you. Having a hard time thinking through
koji: I think we need some detailed definition written down for
review. In general I like the line setting proposal. Make it 2
values. Probably have 2 behaviors, one when it's normal and
one when it's not.
myles: Worth consulting other proprietary apps like inDesign and MS
Word. They have line height. Should consider.
astearns: No one else have half leading like web does
myles: Yeah, but we should figure out what they do
koji: Agree. At least line sizing we're trying to define new model
so learning what other apps do and try to incorporate is good
fantasai: Summary: We want to have a line sizing prop with 2 values,
legacy and normal. Hearing preference for box model
behavior rather then better behavior. I can redraft to
bring down to that.
fantasai: Looks like issue with how does line-height normal: interact
fantasai: Other issues?
nigel: I was reading text on box model. There's a not covered case.
Not sure how important. It talks about applying positive and
negative half leading. Negative it says "negative
half-leading is applied as negative margins to inline boxes
whose block-axis margins, borders, and padding are zero."
What about those whose margin/border/padding are not 0?
fantasai: Then we don't add negative half leading to that element.
fantasai: That sentence was trying to address...if you have a line
height of 0.8 you're adding negative half leading. One of
our goals was to not have a span inside your line increase
the line size unless it's significantly larger. Let's say
all text is same font and size. We apply leading. Then we
encounter a span. Without this exception the box will be
sizes as a line height of 1. It'll be taller because
didn't apply line-height so it causes line to increase.
fantasai: If line height causes negative half leading we need to
take the amount it shrinks and apply to other boxes. Don't
want to do it >1 because then we grow too much.
florian: And we don't have to do that with padding or border?
fantasai: If you applied padding or border you decided to take
control and will be responsible to apply the negative
margins
nigel: Seems like a special case that will surprise. Imagine you
only want a border around a piece of text, no other change.
Seems like a surprise if it causes an increase?
fantasai: Could add negative half leading unconditionally
nigel: More obvious to me
florian: Might want to leave as an option issue, but unconditional
seems to make sense to me.
myles: Which spec is this?
fantasai: Inline
myles: Not there already?
fantasai: It's where it's drafted
<nigel> https://drafts.csswg.org/css-inline-3/#line-sizing-property
dbaron: Seems to me there are different use cases that lead to
negative half leading and might want different things to
happen. Font has a relatively large...the size you add the
leading around is large. Line height might do negative half
leading because tight line height. Doesn't mean you want to
remove from everything else
dbaron: On the other hand fonts that do that don't play well with
this model either
myles: Case you described is common because designers don't know
their font metrics. They put a font and adjust line height
until it looks good. They don't know if that crosses the
invisible line of ascent and descent
fantasai: Can say it adjusts the content box so then the padding and
border added outside leading
florian: That makes sense to me
nigel: And that wouldn't that cause clipping?
fantasai: No, don't clip inline boxes
florian: I think that's quite reasonable. Experiments might show
something else, but thinking it's a good model
myles: We seem to have a lot of ideas and theories. If this goes
into a spec it should have a don't impl marker
astearns: Section does have that.
astearns: This discussion of negative half leading is that a
separate issue?
fantasai: Yeah. We'll put in unconditionally it adjusts content box
and file and issue to discuss further
astearns: Action for you?
fantasai: Yeah
ACTION fantasai put in unconditionally negative padding adjusts
content box and file and issue to discuss further
<trackbot> Created ACTION-875
astearns: Converging on 2 value legacy and new thing. Will need to
be a lot of cleaning up of section in spec and adding
details discussed and then going over spec text.
fantasai: Yes and going over filed issues
fantasai: Should this property apply to block containers or inline
boxes?
koji: Prefer block container I think
* fantasai defers to dbaron on this issue :)
dbaron: If inherited and it can apply to inline boxes there's not a
disadvantage to doing it. Might be a little weird in terms
of effects.
astearns: Want to avoid a case where we introduce shift because we
introduce it to an inline container that breaks across
lines
dbaron: Haven't thought through inline boxes well
fantasai: I'll have it apply to inline boxes and file an issue
astearns: Sounds good
astearns: Anything more on this topic?
astearns: I'm really happy we had this conversation. Winnowing the
options and having something more focused for the future
is an excellent result.
<jensimmons> +1 to what Alan said
astearns: Likely can't take over the regular call in the future, I'm
happy to have extra line layout TF calls when needed.
fantasai: I'll draft up stuff and we'll meet again soon
<fantasai> Thanks everyone!
astearns: Thanks everyone and we'll talk next week!
<koji> Thank you too!
<nigel> thank you!
<aja> somewhat related...consider a nav with inline / inline-block
links as touch targets. how ever above discussion shakes out,
and example in Inline or a11y techniques would be helpful,
since it's a common pattern that's kind of a PITA to do right
<aja> *an example
<astearns> aja: could you add that as a comment to issue 3199 (link
above)?
<aja> guess so, sure
Received on Thursday, 29 November 2018 00:37:06 UTC