- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Jun 2020 19:08:39 -0400
- 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
----------
- RESOLVED: Accept change as proposed by fantasai [move
top|bottom|center values from alignment-baseline to
baseline-shift] unless strong impl argument (Issue
#5180: Shift top | bottom | center values from
alignment-baseline to baseline-shift)
- The group looked at several diagrams in order to understand the
proposal to handle line-sizing and leading-trim (Issue #5168:
Rethinking line-sizing and leading-trim). They were a drawing
from dauwhe (
https://user-images.githubusercontent.com/5687700/84923354-1d839600-b095-11ea-927c-cb17ab91de78.png
)
and a slideshow from fantasai (
http://fantasai.inkedblade.net/style/talks/vertical-rhythm/slides.pdf
).
Slide 52 was recreated on a whiteboard and discussed in detail
to reach a common understanding of the proposal.
- The proposal was well received and was an improvement over the
existing behavior using line-height.
- There were some open questions which need to be answered prior to
the spec being finalized:
- One was to determine if the spacing should use just the
leading in the content's line box or also have the assumed
gap which includes the leading on adjacent line boxes.
- When looking at font metrics should this look at first
available font or at the whole font family. First available
gives more control to designers but the whole font family
makes it less likely to get overlap when a fallback happens
so might be a better default.
- Need to make clear that this doesn't impact the line box model.
- Should this be two properties as proposed or one property that
takes one or two values.
- RESOLVED: Adopt new model described in the issue, continue working
on it (Issue #5168: Rethinking line-sizing and
leading-trim)
- RESOLVED: Apply negative half leading to margin box edge (Issue
#5178: line-height < 1 in a margin-box line layout model)
- RESOLVED: Define the central baseline so if the font has an
explicit ideographic central baseline, use that. If not,
use halfway between ideographic top and bottom. If
that's missing, halfway between ascent and descent
(Issue #5177: About the central baseline)
- The text for issue #1254 ('line-height: normal' definition should
reflect reality of determining based on fonts) needs to be
reviewed but will stay in the spec as-is for now.
- RESOLVED: Publish updated working draft of CSS-Inline
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jun/0016.html
Present:
Adam Argyle
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Mike Bremford
Oriol Brufau
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Holbert
Dael Jackson
Brian Kardell
Brad Kemper
Jonathan Kew
Alison Maher
Stanton Marcum
Myles Maxfield
Manuel Rego Casasnovas
François Remy
Florian Rivoal
Cassondra Roberts
Jen Simmons
Miriam Suzanne
Regrets:
Rachel Andrew
Megan Gardner
Chris Harrelson
Chris Lilley
Lea Verou
Scribe: dael
Rossen: We will do a 90 minute call. Will try and stop around 1 hour
mark because we have to let dael go and also for the others
that can't stay over 60 minutes it's a good time for a break
Rossen: Let's get going
Rossen: Let's go with the agenda unless there's a last minute change.
CSS Inline
==========
Shift top | bottom | center values from alignment-baseline to
baseline-shift
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5180
fantasai: top bottom and center values. Center is new, top and
bottom have been since css 1.
fantasai: When we pulled in alignment-baseline and baseline-shift we
made them longhands for vertical-align
fantasai: Weren't sure what to to with top and bottom because don't
specify a baseline or a shift exactly. Put under
alignment-baseline.
fantasai: Seemed to make more sense to go under baseline-shift
property. Alignment baseline is a concept that exists for
a lot of other boxes but top and bottom don't have a
meaning.
fantasai: I was thinking would make more sense on baseline-shift
which is how much to shift after you align. In which case
we ignore baselines because top and bottom don't care.
They use top and bottom of align subtree
florian: Point of view from inside element top and bottom values
don't combine with either, they take over. From point of
view of element relationship with parents it does make
sense to continue applying alignment-baseline even if top
and bottom shifted. Am I getting that right?
fantasai: Yeah. Probably only case for both is table cells where top
and bottom values trigger behavior on align-content. In
that case if you have a table with a single table cell and
if you vertical-align top the baseline still has a meaning
to allow to able to align to. In which case we have to
export a baseline so there's a meaning to having both
values
fantasai: Within inline layout top and bottom has no ability to
combine with aligned baseline or baseline shift.
florian: Another approach is from cascade and setting. Most of the
time you set in shorthand. If set separate having some
feeling that align-baseline is based on broad context and
you could be doing this for whole doc but locally switch to
top and bottom
florian: It's a good fit for neither, but I weak lean toward your
proposal
AmeliaBR: What's our implementation status? Are we asking
implementors to change shipped things or is all still new
stuff adding extra vertical-align keywords
florian: I don't think impl have switched to long hands except in
SVG which doesn't have these keywords.
fantasai: I don't think alignment-baseline is in FF
AmeliaBR: That's my only concern. If we're changing after something
has shipped not worth changing. If nothing has shipped I
agree with fantasai this makes more sense
florian: MDN doesn't seem to know these have shipped, but it has a
[?]
fremy: We can check
fantasai: I can't get FF to do anything with alignment-baseline
Rossen: Doesn't sound like strong impl constraints
fremy: Not able to get FF to do something and I'm in FF dev.
<AmeliaBR> Confirmed that Chromium doesn't support these keywords in
alignment-baseline
<dholbert> according to this code, alignment-baseline is indeed not
currently supported in Firefox:
https://searchfox.org/mozilla-central/rev/eef39502e08bcd3c40573c65a6827828dce4a032/dom/svg/SVGElement.cpp#974-975
florian: Alternative would be spawn another long hand but I'm not
sure I'm excited about it
AmeliaBR: I suggested if these override both longhands but it gets
confusing from cascade PoV
florian: It can't do something in the shorthand without doing
something in long hand
fantasai: Values are mutually exclusive with baseline-shift. You
can't do shift and do top and bottom. Because mutually
exclusive might as well be same property
fantasai: Does anyone have other comments or should we accept and
move on? There's arguments in favor of change and none
against
dbaron: Seems only sort of exclusive. You can do top and down but
not top and up
faceless2: Spec says you can't combine them.
florian: Browsers haven't impl syntax. But even if they did does it
mean anything?
fantasai: Can't really combine. If you want to shift there's a lot
of other ways.
dbaron: Okay with it. Makes sense to forbid it
Rossen: Seems like leaning toward forbidding it.
Rossen: astearns pointed out...[we table this one and go on to other
issues since we don't appear to have clarity on this one yet]
florian: Have clarity, but not enthusiasm. Everyone leaning in that
direction
<faceless2> Test: https://jsbin.com/hodevav/edit?html,output
AmeliaBR: Resolve to accept change as proposed by fantasai unless
strong impl argument?
Rossen: That's the proposal, yes
Rossen: Objections?
RESOLVED: Accept change as proposed by fantasai unless strong impl
argument
Rethinking line-sizing and leading-trim
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5168
fantasai: Combines a lot of ideas. I can go back over line-sizing.
Might be helpful if people watch video because it has
pictures.
fantasai: Line-sizing we had several discussions on size of lines. 2
properties. Line-sizing which is between current model to
use line-height of each inline box and draft line box over
effective height. Problem is we get line larger than
author wants because they set line height with slack. If
they add stuff they don't want extra leading added to all
the lines. That's one problem
fantasai: Tried to solve by using margin edges of content box which
is usually top and bottom ascent/decent.
fantasai: Problem with that model is it works fine when line-height
is big enough. Doesn't work when line-height is close to 1
because not extra leading for shift with something like
font-family. Lots of times ascent and descent are
noticeably taller than glyphs
fantasai: Other discussions were about leading-trim and how to
handle setting inline. Trim or not. And if you're trying
to figure out metric to trim maybe you want to set it doc
wide and not figure out which each time you trip. Trim
usually depends on language.
fantasai: Might make sense to rethink relationship between these.
Proposal was switch to a model where leading-trim is a
switch if you trip and a separate property to say what is
top and bottom edge of text for inline layout
dbaron: What does second property do? Just leading-trim or other
things?
fantasai: Just leading-trim
florian: leading-trim just trips start, end, or none. First says
where you trip if you do and it's the switch between legacy
and normal with variants of normal that lets you pick
something else than text-top and -bottom and lets you
switch to a different font metric for line-sizing
florian: General feeling is this is going an interesting direction.
If it will work depends on details which are not fleshed
out. Example when we trim what do we trim. Layout box,
content box? When trim to metric is it first available
font, tallest font? Without trying variants of these I have
a hard time convincing it works right, but it's worth
exploring
Rossen: Feel like we can make more progress on this issue except
that it's worth exploring?
fantasai: This was one of the main issues to discuss. We can wait 5
minutes for people to think. If people need a week we need
to wait.
dauwhe: Wish we had a whiteboard
florian: Very much so.
[fantasai works on projecting her whiteboard]
<dauwhe> https://user-images.githubusercontent.com/5687700/84923354-1d839600-b095-11ea-927c-cb17ab91de78.png
dauwhe: I put in an old drawing trying to understand original sin of
a superscript in a paragraph messing up spacing and it
labels some font metrics. Would love to understand better
how options effect this
florian: Switching between legacy and margin-box would let us not
take into account green part of 5. Being able to have
metric helps. Let's assume top of ascent in yellow is more
far away than ink of 5. A different metric you'd be able to
trim more. Ink of 5 is out of bounds. Might be able to have
enough slack on line before we could increase but nothing
in the proposal does that. Can get rid of green and some of
yellow
dauwhe: In real life all of yellow box fits bottom half leading of
previous line
florian: Yes if there is one and not something there
dauwhe: Yes, it's a middle of block sort of example
[more whiteboard set up]
<fantasai> http://fantasai.inkedblade.net/style/talks/vertical-rhythm/slides.pdf
fantasai: We have a whiteboard, we have diagrams from dauwhe, we
have these slides^ which I'll start with
fantasai: Slide 52 shows [draws]
fantasai: You've got a line box and another line box and another
[they're stacked on top] You have leading above and below
fantasai: The line gap is the leading of the two boxes that are
adjacent. You have text that's in the line box. Does it
fit in the line box or do we need to increase
fantasai: Traditionally each element has its own leading. If we trim
it out then can still have a different font which may or
may not fit in line box. Depends on ascent or descent.
fantasai: When trying to figure out if something fits in line box we
need to ask what is bounds of thing and what do we
consider fitting in the line box? Do we assume
half-leading on the next box and take that and boundaries
[assumed gap], include the leading.
fantasai: We take assumed gap when we're doing Ruby.
fantasai: That's one question we haven't covered yet.
<astearns> I assume that using the assumed gap will still avoid
collisions with previous line descenders because the gap
only includes the previous half-leading
fantasai: Other question is what is the metric on text which we
consider fitting. What is the size of the thing.
fantasai: What I'm trying to answer is can we change what it means
for the thing we're trying to align. What's the size of
the inline box we care about to try and fit inside the
line box
fantasai: Current is use the line height, but that's bad because
includes half leading and we don't care about that. New is
use margin-box edges which coincidence with ascent and
descent in most cases.
fantasai: Some fonts it matches height, some go a bit higher for
accents, some a lot higher for ascents. So you end up with
a lot of vertical space being considered.
fantasai: Combining metrics with inheritence you let author say I
only care about cap height and don't care if ascender leak.
fantasai: Trying to take leading-trim which is non-inherit, use the
metric, and put it in an inheritable property.
fantasai: Can also say do we care about fitting and should we make
what the default
fantasai: Making the line box work for dauwhe use case it's what is
size of inline box and what is size of line box for
purpose of fitting
fantasai: Proposal is saying let's put some controls over what
inline box is and allow it to trim to particular metrics.
fantasai: Making sense?
Rossen: I don't think you need to explain again. We have a queue
Rossen: Quick ask to mute on webex if you're not talking.
<dauwhe> goal rendering:
https://user-images.githubusercontent.com/5687700/84924250-4193a700-b096-11ea-8149-0266693b8f84.png
florian: The original proposal/issue wasn't discussing if we're
using assumed gap. Combo of explanation and picture from
dauwhe makes this interesting. Depending on what sticks out
this design, unlike previous, lets us introduce another
property that lets us pick between line box and assumed gap
florian: We'd be lacking something to decide text bounds if we do
just that. This gives us the switch as opposed to previous
design which coupled to leading-trim. Now it's re-usable
and you can decide. Convinced me more this is right
direction. My inclination is start spec this knowing it's
not final but with sense it's better
dauwhe: In general I like this idea of almost being able to pick how
these stack up
dauwhe: Pick which edge will contribute here
dauwhe: I don't think I can say more and have it mean anything
without making drawings for myself so I understand
florian: If we say pick one do we mean metrics of first available
font or of all used fonts. Is there a correct answer or a
switch. Don't want a switch but not sure which
fantasai: If we're going with this model means that you're going to
consider content of descendant inlines. Each inline will
contain an edge. If contents are different font they
contribute their edge. Multiple fonts on a line the line
box will go from highest top to lowest bottom. Currently
ascent+leading, in future have other options.
fantasai: At that point makes sense to consider fallback fonts. Once
trimming not adding a lot of excess so by default
considering fallbacks is where I would start
florian: Range in there
fantasai: That would be appropriate place to start and if need
stricter can add. Lots of cases where we mix fonts so
weird if you say I wont font-height of this and it chops
florian: If we start from content box and add padding & margin if we
trim from that difference from content box and union.
Content box is only first available so how do we trim from
first available to all font metric. I buy everything you
said so I'd try that direction
fantasai: Feels like follow-up issue
florian: Yeah, probably
myles: 2 questions. First is what happens when text doesn't fit?
fantasai: Increase line box height
myles: Just the one?
fantasai: Yes.
myles: When you drew you did black lines and than added red text. Is
that the model where red text tries to fit in lines?
fantasai: Yeah. Whether this proposal or not we only accept positive
leading on root inline box so the text inside the root
inline are going to care that they fit in the leading
bounds. If they leak outside we increase.
fantasai: Baseline of root inline will be here and they will try and
fit. In either model we don't care if some text is big
enough to go into leading area. If it's a bit too big it's
fine. Question is what if it's big enough to go outside
leading of own root inline. Do we stretch line for that
case or assume half leading of previous line belongs to
this.
fantasai: Stricter and looser model. In no case do we apply positive
half leading to inline boxes inside
dbaron: I think myles asked if changes order of impl
fantasai: I don't think so
dbaron: I think the answer is no
florian: Spec is you align based on baselines and add leading and
margin boxes if you need. Then you draw line box around
them all
myles: And in this model you do all the layout, draw a black box and
it's only determined by primary font metrics and than adjust
form fallback fonts?
florian: Tricky because lots of similar named boxes
florian: Inline boxes have 2 models depending on line-height normal.
If it's normal inline box takes into account all actually
used fonts including font fallbacks. Anything other than
normal then it's just that size that's set. Only take
metrics of first available font into account to figure out
where baseline goes.
florian: On your line there may be more than one box. Once all
inlines are in boxes you do top of tallest to bottom of
deepest. Depending on how each box was sized is line
height. What top is is the previous question. Top of margin
box or add leading. Legacy is we add leading which is
probably not what we want.
florian: New model is margin box which doesn't have leading
Rossen: myles does that address your question?
myles: Think so
fantasai: Line box model doesn't change, just changing what is top
of each box. Even if doing assume gap we can do it in same
way. Only calc layout bounds of each inline box.
fantasai: In legacy it's defined as line-height. New it's text
metrics based. Model on how you calc line height is not
changes.
<florian> myles, the section of the spec that outlines the answer
to the question you just asked is
https://drafts.csswg.org/css-inline-3/#line-layout
Rossen: Couple of people on queue then break.
Rossen: We've made progress on understanding. Let's drive to
conclusions
jfkthame: Question of if we're trimming through method like cap
height would that be on first available. My instinct is to
say only first available is better answer. Thinking from
experience of page design where stability and
predictability is of great value and if we merge metrics
of fallback fonts it gets difficult as a designer to
figure out what's going to happen.
fantasai: My main concern is to extent we've been using looser
metrics that works better. When mixing fonts there's
slack. Bringing this to tight metrics I'm afraid you'll
have substantial ink overflow when you switch fonts.
jfkthame: I can see that. Counter by saying these are controls that
will only be used by designers looking for careful control
of content. If want to allow some stuff to leak that's
their choice and we shouldn't stop them
myles: General principle website designers don't know if webfonts
will load. That's choice of user. We should be resilient to
if different font that designer wanted.
fantasai: And you could have picked a lovely multi-script font and
get chimera fallback. Trying to make sure text is readable
even when unexpected things happen.
fantasai: If your font loads properly you get what you want but if
you have a fallback thing bias toward fitting by default
makes sense to me.
fantasai: I think it is secondary to issue. We can open a separate
item on fallbacks.
Rossen: Reasonable.
dbaron: Two comments
dbaron: One is about the question someone asked about which of this
applies to first available font vs all
dbaron: Maybe that wasn't quite the question
dbaron: It was. First or all fonts. In this proposal that's only for
text over and under not leading. Leading looks at root
inline box so only one font. I think that's the model for
this purpose.
dbaron: Second is text edge over and under having 2 properties is
weird in some cases but necessary in others. For leading and
normal want one but for metric values you can't. Wonder if
this should be one property that takes one or two values
fantasai: Either way should have shorthand
fantasai: I think we should push fallbacks or not to a separate
issue. Look at overall structure of these properties
Rossen: florian you want to propose a resolution?
florian: Noting that the previous proposal is marked as rough in the
spec. Even if this isn't fully fleshed out including
question of short/long for properties and question of
fallbacks. I propose we replace the current vague proposal
with this vague proposal in the spec and add these as
issues to keep drilling down.
florian: I haven't heard arguments that led to us preferring the old
model.
Rossen: Let's give a 5 minute break. If there are people that have
to skip out that's fine but we prefer you don't skip.
Stretch, get water, and think about florian proposal to swap
the old model with the currently proposed one.
<br type=5min>
Scribe: dauwhe
Rossen: Let's go back to it
Rossen: Florian was talking about a proposal
Rossen: take this new model and replace the old model with it
Rossen: and then continue to work on it
Rossen: Can we do that? Do we have enough info to make that decision?
<dauwhe> +1
Rossen: Any objections to the proposed resolution
Rossen: I hear no objections
RESOLVED: Adopt new model described in the issue, continue working
on it
line-height < 1 in a margin-box line layout model
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5178
fantasai: When we apply line height with positive half leading
that's good
fantasai: If we have negative half-leading
fantasai: the size is less than the height of the font
fantasai: line-height: .8
fantasai: the ascent and descent of the font--you have to slice off
the bottom part and take this as layout bounds
fantasai: In the new model we're not applying line-height to inline
boxes
fantasai: This one doesn't get half leading, so it gets taller
fantasai: but we still have to reduce the size of inline boxes when
there's negative half leading
fantasai: The proposal says we have to apply negative half
leading... do we reduce the size of content box or margin
box?
fantasai: In the proposal we say margin box
fantasai: What do people think about that?
Rossen: Is there a reason for it to be other than the margin box?
Rossen: I think that makes sense
florian: Yes, it makes sense
florian: but if we would affect painting, it would be weird
florian: so it should be margin box
Rossen: Any other opinions? If not, we can resolve.
Rossen: Any objections?
dbaron: Not an objection
dbaron: the idea is fine
dbaron: What do numbers multiply by? Are they still what they used
to multiply by?
fantasai: That's a good question
myles: What's the argument to change?
fantasai: If you want fixed you can set fixed
myles: Can you use px?
florian: Yes
dbaron: But it's weird to do that because it inherits
fantasai: I would say we treat them the same as currently
fantasai: You're trying to reduce size of line boxes by 20%
fantasai: You want ascent/descent to be shrunk a bit, to get the
affect of setting solid
dbaron: Is the condition less than one, or what would make it less
than the margin box
fantasai: A+D doesn't necessarily add up to one em
myles: That works even if line height is PX
fantasai: Yes
Rossen: Are we ready to resolve?
fantasai: I think so
Rossen: Any objections?
RESOLVED: Apply negative half leading to margin box edge
About the central baseline
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/5177
fantasai: I raised an issue about central baseline definition
fantasai: Halfway between text top and text bottom, which are not
defined
fantasai: and it's the default baseline in vertical writing mode
fantasai: which isn't interoperable, which is bad
fantasai: We need a good metric for Vertical writing and CJK
fantasai: which is halfway between ideographic top and ideographic
bottom
fantasai: We could just define to be exactly that
fantasai: or create a new keyword for ideographic central
fantasai: but I think we should make central the ideographic baseline
fantasai: Comments or questions?
florian: Don't have a great sense of the fallback when ideographic
baselines aren't there
AmeliaBR: Use ascender and descender heights to define edge of
em-box, and halfway between?
AmeliaBR: That gets messy because of different values of asc and desc
AmeliaBR: and there are different names for metrics
AmeliaBR: If we're using central alignment on a font not designed
for it, and the font is badly broken, then you get bad
results
florian: Are there vertical languages that are set upright and whose
fonts don't have ideographic top/bottom metric?
florian: Does Yi use it?
fantasai: Yi uses same as Chinese
AmeliaBR: The OT fallback fallback for center on vertical axis is to
assume glyphs use full em-height
AmeliaBR: you'll get weird results if glyphs are narrower
fantasai: The proposal is to define central baseline to be the
ideographic baseline
fantasai: and if that's missing fall back to half between ascent and
descent
AmeliaBR: The CSS definition continue to use the concept of em-box
AmeliaBR: if not explicitly defined
<florian> wfm
fantasai: If the font has an explicit ideographic, use that. If not,
use halfway between ideographic top and bottom. If that's
missing, halfway between ascent and descent
Rossen: Any objections?
RESOLVED: Define the central baseline so if the font has an explicit
ideographic central baseline, use that. If not, use
halfway between ideographic top and bottom. If that's
missing, halfway between ascent and descent
'line-height: normal' definition should reflect reality of determining
based on fonts
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1254
fantasai: Lots of talk about what line-height: normal does
fantasai: I went through the minutes, and incorporated into the spec
fantasai: One question: how fonts own line gap metrics are handled
fantasai: When they are there, we split the gap so half above and
half below
fantasai: I think it only affects the height of the line box
fantasai: so I put that in the spec
fantasai: I wanted to confirm that with the WG
fantasai: That what is now in the spec is acceptable
myles: Is this a question of researching of what browsers do? Make
fonts with varying line gaps and see what happens?
florian: At least start with finding what it is
dbaron: My memory is that gecko's choice of whether to use the line
gap metric is complex, and that what it affects is what
number line-height: normal means
florian: I agree that line gap does not affect height of content box
florian: I didn't test vertical align
myles: Rather than asking us to remember what our browsers do,
better to test the browsers?
myles: I'm happy to make a bunch of fonts to help
florian: We can split it up. we'll make fonts and test
Rossen: How shall we resolve? Try to match reality of current
implementations?
fantasai: We can leave the issue open until we have definitive test
results
fantasai: I'll make sure that what dbaron said is allowed
fantasai: the rest is already in the spec
<dbaron> I don't think I mentioned using the line gap metric of a
different font...
fantasai: If people want to review, that would be great
fantasai: and I'll ask if I should publish a new WD?
Rossen: A new WD would include edits with today's resolutions?
fantasai: Yes, I'll make those edits before I publish
Rossen: Any thoughts?
Rossen: Hearing no pushback
RESOLVED: Publish updated working draft of CSS-Inline
Future Meetings
===============
myles: 90 minutes is too long for me
myles: We made good progress
myles: Don't we usually just let the agenda overflow
myles: I'd rather have lots of topics for the future
fantasai: I had deadlines this week, which was why
Rossen: Most people had similar sentiments, Myles
Rossen: Maybe we don't repeat this, unless at F2F
Rossen: There's a thread on Private ML about upcoming F2F planning
Rossen: Thanks everyone
<fantasai> I also figured that the line sizing topic would take
awhile and wanted to make sure we had the time to dig
into it rather than skimming over it over the course a
few calls
<dauwhe> I think this helped
Received on Wednesday, 17 June 2020 23:09:24 UTC