- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 7 Aug 2020 10:15:09 -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 3
------------
- RESOLVED: Preserve whitespace for sink 1, collapse otherwise
(Issue #5120: initial-letters-wrap: first, whitespace
collapse needs defining)
- RESOLVED: Remove hebrew value from initial-letter-align (Issue
#5208: Drop 'hebrew' alignment from initial-letter-align)
- RESOLVED: Add `leading` value to `initial-letter-align`, and get
feedback to confirm it solves the issues for these
scripts (Issue #864: Alignment of initial-letter for
South Asian scripts without hanging baseline)
- Issue #4988 (initial-letters changing used, not computed
font-size) needs more use cases so discussion will continue on
github.
- RESOLVED: Make drop caps behave like raise caps for the purposes
of text-align and justification (Issue #5207: text-align
+ initial-letter)
- RESOLVED: Make shape-outside and margin interact the same way for
initial letters as for floats (Issue #5119:
initial-letters: interaction of shape-margin and regular
margin)
- RESOLVED: Don't drill through block boxes with non-zero padding /
border in the block axis (Issue #5237: leading-trim
through to descendant line boxes)
- There's interest in having a loose fit option similar to Ruby
(Issue #5239: Tight vs loose fit into a line box) but more time
needs to be spent in exploring use cases and thinking about how
or whether to handle collisions.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#tuesday
Present:
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Emilio Cobos Álvarez, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Simon Fraser, Apple
Daniel Holbert, Mozilla
Koji Ishii, Google
Dael Jackson, Invited Expert
Brian Kardell, JS Foundation
Jonathan Kew
Chris Lilley, W3C
Peter Linss, Invited Expert
Alison Maher, Microsoft
Myles Maxfield, Apple
Cameron McCormack, Mozilla
Tess O'Connor, Apple
Florian Rivoal, Invited Expert
Devin Rousso, Apple
Jen Simmons, Apple
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Lea Verou, Invited Expert
Scribe: emilio
CSS Inline 3
============
initial-letters-wrap: first, whitespace collapse needs defining
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5120
fantasai: So when you have a raised cap, you need subsequent space to
appear in the first line
fantasai: otherwise it's confusing whether the cap is part of the
word
fantasai: but for drop caps you need the space to disappear
fantasai: so that all impacted lines are even
fantasai: so the proposal is that if the sink is greater than one we
collapse, but we don't otherwise
faceless2: 0 is a valid sink, so we presumably collapse there?
astearns: So we avoid collapsing only for 1 and collapse elsewhere?
fantasai: Yeah
florian: What does a sink of 0 do?
astearns: Presumably the letter appears on its own line
fantasai: I'd like to reopen that because I don't think it behaves
like people want
fantasai: and we have props to create the necessary breaks in L4
florian: Clarification, just regular U+0020 whitespace?
fantasai: Yeah
RESOLVED: Preserve whitespace for sink 1, collapse otherwise
Drop 'hebrew' alignment from initial-letter-align
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5208
fantasai: We have some values handling hebrew in
initial-letter-align, effectively as a placeholder
fantasai: because we don't have metrics for it and a couple other
writing systems
fantasai: We put it in the spec along with an issue on those lines
<fantasai> https://github.com/w3c/csswg-drafts/issues/5244
fantasai: As we're cleaning up the spec I think we should remove the
hebrew values and leave the issue about the writing
systems not having metrics available
fantasai: so that we don't have this value which is not
implementable at the moment
dauwhe: We tried to reach out to the hebrew community and we
couldn't even name the alignment point
florian: I'd say let's remove it given we have an issue to having
this
fantasai: I think it was useful as we explored the space to know
where we needed to hook it in, but now it's less helpful
RESOLVED: Remove hebrew value from initial-letter-align
Alignment of initial-letter for South Asian scripts
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/864
<fantasai> https://w3c.github.io/ilreq/#h_scripts_without_hanging_baseline
fantasai: In ^ we're not aligning ink-to-ink, we're aligning the top
and bottom of the drop cap ink to the top and bottom half-
leading of the line
fantasai: proposal is to add a value that does that
fantasai: We have a value in text-edge referencing that metric,
called `leading`, corresponds to that half-leading edge
fantasai: so proposal is to reuse that name
florian: This seems a reasonable solution to the problem, but I'm
confused about the stated problem
florian: half-leading is very css-y, it's interesting to see
typography using it
AmeliaBR: The diagrams don't seem to be talking about leading but
about ascent and descent of the characters
fantasai: There's "ascent" and "ascent height" in the diagrams. One
of those two is our ascent and the other is something else.
fantasai: afaict our ascent is their "ascent height"
fantasai: If you argue that our ascent is their "ascent" then what is
their "ascent height"?
fantasai: I'm pretty sure that what they're calling "ascent" is just
the half-leading edge
myles: Is this a proposal to change the meaning of different metrics
depending on the font or is this about adding a value to a
property?
fantasai: Adding a value, to `initial-letter-align`
astearns: There are some questions about whether this value solves
the issue, maybe we should push it to another level?
fantasai: We can go back to i18n and check whether it does, but this
is not a case of us not having a proper metric for this
fantasai: I think we should add it and check with i18n whether it
solves their problem
myles: I don't want to weigh in about the particular metric, but can
we have the behavior of auto to do the right thing?
fantasai: We don't have an auto value for this
<myles> https://developer.mozilla.org/en-US/docs/Web/CSS/initial-letter-align
myles: mdn says there's one (^^)
fantasai: really?
faceless2: I suggested adding one about 3 hours ago
<myles> faceless2: do you have a link?
<faceless2> Bottom of https://github.com/w3c/csswg-drafts/issues/5244
myles: I guess I should rephrase: if this is the expected way to do
type setting we should make sure that it does the right thing
by default
fantasai: Yeah but we should have separate issue for that
myles: I'm fine with that
florian: This seems like the right way to do this if reality matches
the diagram
<florian> I'd support an inline issue or note calling for feedback
RESOLVED: Add `leading` value to `initial-letter-align`, and get
feedback to confirm it solves the issues for these scripts
initial-letters changing used, not computed font-size
-----------------------------------------------------
scribe: faceless2
github: https://github.com/w3c/csswg-drafts/issues/4988
fantasai: In some cases where the initial letter has multiple
characters, some of the characters may want to be of
different sizes - for instance punctuation or
superscripts or similar
fantasai: The problem is that we can't just say the descendants of
the initial letter take the font size of the parent, so we
need to have some kind of distinction to see whether the
author wants to make the descendant an absolute size or
have it scale to the initial letter
fantasai: The proposal is the the initial letter sets a font size
multiplier, so computed font-size is now a tuple - the font
size length and a multiplier. When font-size inherits it
inherits the multiplier, when the font-size is set to a
length multiplier is set to one, and when set to a
percentage the multiplier is not reset
fantasai: This ensures that the multiplier set on an initial letter
is inherited by its descendants, so they will be scaled to
match the parent element.
fantasai: So the author can choose between specifying an explicit
size or one that is linked to the initial letter size
<fantasai> summary of the proposal:
https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-644472219
<fantasai> properties affected by multiplier:
https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-634920474
dbaron: It sounds good. If they wanted to use a font-relative
unit that isn't an em, they can use a calc for this:
calc (1.5ch/1em * 100%)
dbaron: This leads to another problem - the unit dimensionality
analysis in calc. Does this prevent you from doing calc(200%
* 200% / 1em)?
fantasai: Can we multiply percentages by percentages any other place?
TabAtkins: So long as the percentage resolves to a number, yes.
fantasai: Percentages generally resolve to a length, so multiplying
by another percentage would give you length squared which
is not valid
myles: The solution seems to add a lot of complexity for what is
ultimately a corner case. And I don't see different sizes
being very common
myles: So I'm worried about the cost-benefit analysis
fantasai: So even if we don't want control over font sizes, we have
a multiplier down somehow otherwise even an unstyled
descendant inline box will break initial letter sizing
myles: The other option is not to solve this problem
<dbaron> I could suggest another option...
fantasai: Also, desire to control size is relatively common: for
example an initial quote is supposed to be a different
size to the initial letter.
heycam: It's possible we could solve this for quotes in a different
way, rather than relying on the author to put markup on this.
fantasai: There is an open issue to allow initial punctuation to be
selected via pseudo-element.
heycam: It's a bit weird that now we can't do getComputedStyle on an
element and set it back as the computed style on an element
as now we'd get something that behaves differently. I don't
like that there's a hidden value as that's not particularly
obvious to the author
<AmeliaBR> +1 for heycam's concern. Computed style should be
round-trippable. Used style could still be used for em
units.
astearns: I think the common case where the open quote is meant to
match the size of the body text - is it going to be
possible with this to make this work?
fantasai: Yes, with this proposal you'd set the size to 1em to match
the paragraph size
florian: We want the ability to match the size to the parent text,
and we want intervening markup to not mess things up.
Affecting the computed rather than used value would solve
the second. Is the first one the reason we're not going
that way?
fantasai: That would make font-size depend on both font-size and
line-height of the element's *containing block*, which
is not a dependency that we want to put for the computed
value of font-size. Doing so would make the font-size
computation, which is a dependency of all other length
value computation, much more complicated.
emilio: I wanted to echo some of the concerns raised by myles, but
also to point out font-size already has some complexity -
for instance font-size: medium has complexity, if you change
to a font that has a different meaning of medium there are
already calculations going on there
myles: We do that too but it's just for monospace, but the only
reason that's there is because the default monospace font had
weird metrics. I don't think we should consider that as a
precedent.
emilio: I agree, I don't think we should add to the complexity
dbaron: So another idea which may be less complex is to have a
separate property that causes an element to be excluded from
the font-size adjustment that the initial letter changes. We
could have a property that could be set to prevent elements
and exclude them from the size adjustment
dbaron: So eventually you'd take the multiplier and give it its own
property
florian: There's no use for a multiplier of 1.7 is there?
florian: If you wanted that you could just use 1.7em
fantasai: So if we had an on/off switch, how are we tracking the
multiplier? The resizing effect of initial letter has to
be stored somewhere, as a multiplier, not a boolean value.
faceless2: This is per-property multiplier, you have a couple cases
with e.g. margin-left: 1em
faceless2: want that to be font size of the paragraph
faceless2: but want the actual font size to be matching the initial
letter
florian: So that works with fantasai's proposal, because can use ems
or not; but not with dbaron
(dbaron and fantasai both start to disagree)
dbaron: The proposal with the multiplier is it does not affect the
use of em units or any other font units, just percentages.
<fantasai> https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-634920474
dbaron: It only applies to particular properties which are related
to the font, and only to percentages.
fantasai: This isn't purely about the font-size its about several
other things that are keying off the used font size.
fantasai: So you can't use this for margin left, for example, because
it only takes em values. And em values are not affected by
the multiplier
fantasai: The things where it needs to be relative to the used font
size are things that are being done to the text itself, and
in that case we're already allowing for percentages because
they need to be inherited as percentages. But margin
doesn't have this because we have no use case for it
astearns: I'm not hearing a consensus on this
florian: I'm not necessarily is opposed but was asking questions to
help understand it better
astearns: the way to go forward here is to go forward on the issue
with some examples. I'm hearing enough reservations that
we shouldn't resolve.
fantasai: we'll take it back to the issue.
<br>
text-align + initial-letter
---------------------------
scribe: emilio
github: https://github.com/w3c/csswg-drafts/issues/5207
fantasai: We had a long discussion about this a while back and we
decided for raised caps to make them part of the rest of
the line
fantasai: but for drop caps we decided something else
fantasai: but having two models is not great, and even a raised
initial can affect the second line if it has a descender,
so concerns about how those lines are affected don't go
away by limiting to raised caps
fantasai: So my proposal is to treat drop caps the same as raised
caps, participating in the alignment of the first line
fantasai: Then if it impacts following lines it'd shorten them
<dbaron> It sounds like this might be better for shape-inside as
well?
dbaron: What I think I've seen people do is combining initial-letter
effects with shape-inside
dbaron: may or may not impact this discussion
dbaron: haven't worked through whether this decision affects it
fantasai: I don't think it does
florian: As you pointed out raised cap with a descender already
needs to deal with this so it makes sense to do the same
RESOLVED: Make drop caps behave like raise caps for the purposes of
text-align and justification
<tantek> just catching up on this discussion. that sounds like a
reasonable conclusion
initial-letters: interaction of shape-margin and regular margin
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5119
faceless2: We have two ways of defining margin around an
initial-letter, one is margin and the other is
shape-outside
faceless2: we need to define how they interact
faceless2: I think I agree that matching what floats do is a good
idea
faceless2: There are a few proposals, not sure if fantasai's
proposals are still applicable?
fantasai: There were several options, one is that we only used
shape-margin only, another is using it when it's non-none,
another is using maximum
faceless2: There's a strong argument I think to make it work the
same ways as floats, may need to remove the margin-right
magic
fantasai: One of the advantages of regular margin over shape-margin
is that is axis-specific
fantasai: so you can tweak the space with the following line by
tweaking the margin only in the horizontal axis, for
example. Using different amounts of margin between the
initial letter and impacted lines vs between the initial
letter and lines below it might make sense. You can't do
that with shape-margin
faceless2: I agree, current adding margin-right adds functionality
that you can't reproduce in other ways currently
astearns: So the downside of making it behave like floats is that
you get the weird behavior that you can only pull stuff
closer inside the margin box
astearns: and you need to expand the margin box if you want to push
stuff further
astearns: but authors are dealing with that already
astearns: so probably they can deal with it too for initial-latter
fantasai: Given the consistency argument we should probably spec
this and see how it works and try to get some feedback
faceless2: Nobody is shipping this currently right? Just WebKit?
fantasai: I think that's right, and WebKit's implementation is quite
limited atm
RESOLVED: Make shape-outside and margin interact the same way for
initial letters as for floats
astearns: As you spec this it may be that we should also move that
over how floats behave
CSS Sizing 3 Interlude: intrinsic sizing of fit-content()
=======================----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3731#issuecomment-661408877
astearns: So the edits are in the spec already, is it just
confirming that it's good?
fantasai: Yeah, oriol suggested to handle the fit-content argument
like other percentages
oriol: fit-content() is just syntax sugar for nested min/max
functions with min-content / max-content on the values
oriol: so they should behave the same as the expanded form
<fantasai> https://github.com/w3c/csswg-drafts/commit/6622d44241d41b38d19eed89fa796826f2121dcb
dbaron: Should probably review offline, though should take me about
10 mins
astearns: Let's do that.
leading-trim through to descendant line boxes
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5237
fantasai: leading-trim relies on the concept of "first formatted
line", which is needed to deal with anon blocks and also
nested blocks
fantasai: However it may be a bit too aggressive as it also drills
into styled boxes
fantasai: See the example in the issue, the leading-trim of the
outer box ends up affecting the leading of the "warning"
box even though it was already styled with borders/padding
fantasai: It doesn't seem like the author would want that
fantasai: So I think we should do what margin collapsing does and
don't drill into boxes with non-zero border / padding
<AmeliaBR> This definitely sounds like something that should match
up with margin collapsing rules.
dbaron: Do you want to make it also condition on the
margin-collapsing definition or just reuse it?
dbaron: I think you should intersect the definition
dbaron: because otherwise you'd apply it to some empty lines and
it'd be bad
iank: There's a lot of complications round floats and
margin-collapsing, which you may be very careful of
<dbaron> yeah, it might be better to take the relevant parts of the
margin-collapsing definition rather than actually referring
to it
<dbaron> another fun question is whether there are any interactions
with 'clear'
emilio: Would it be better to say anonymous block boxes inherit this
property?
fantasai: I think you may want to apply it to non-anonymous boxes as
well, like chapter -> paragraph, specially if those
margins are collapsed
florian: Another one would be the notes in specs, some of them have
paragraphs inside some don't, and you want to treat them
equally
fantasai: I think I'll try to spec this and then come back for
clarifications
RESOLVED: Don't drill through block boxes with non-zero padding /
border in the block axis
Tight vs loose fit into a line box
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5239
fantasai: dauwhe made a nice diagram, we had a lot of discussion
about this. We recently added the text-edge property to
control what is the size of an inline box in terms of
deciding what is the size of an inline box
fantasai: for the purpose of fitting on a line or not
fantasai: which allows us to trim the half-leading and even into
the glyph down to e.g. cap height
fantasai: Currently, whether something fits inside a linebox is
about whether something fits into our own half of the
leading between lines. But it may be ok if it leak outside
of our half leading if it leaks only into the half-leading
of the adjacent line box
fantasai: I'd call that loosely fitting. We do this for ruby.
fantasai: We make the assumption that there's a linebox before and
after with the same metrics as the root inline box
fantasai: Do we want to allow this for other kinds of content than
ruby and if so what does that look like?
florian: To be clear we don't try to detect collisions nor
special-casing for first lines right?
fantasai: Right, if you enable this you have a decent chance of
overlapping content
dauwhe: I drew this because we put a superscript in a paragraph and
it breaks the vertical rhythm, and we hate this
dauwhe: text-edge controls how the child inline affects the line
height
dauwhe: To make this work you couldn't even do the text-edge checks
on the cap height you need to cut it all the way down to the
x-height for the cap not to get into the half-leading of the
previous line box
florian: I think the text-edge lets us get rid of the green part of
the problem, but we're left with the yellow part of the
problem
fantasai: So with the new line layout model you could give negative
margins: you'd allow overlap up to the margin and not more,
so you can control the overlap
fantasai: One way to get this is to set margin-top: -half-leading on
the element you want to allow bleeding
fantasai: but we don't have such a value right now
fantasai: Various things we could do
florian: It seems there are two models, A and B, with ruby using one
and regular layout using another, but authors not having
the choice
koji: Do you want to allow bleeding unconditionally or do you want
to detect conflicts?
fantasai: Ruby doesn't detect conflicts so we'd do the same
koji: But ruby is safe because it's usually in one side, but
generally you may have superscript on one line and subscript
in the previous one
dauwhe: I'd be willing to take the risk of some ink overlap to
preserve the regularity of my line spacing
dauwhe: in the case shown here I wouldn't have many problems unless
stuff goes over the font descent
dauwhe: if you know the font you're using then it seems worth the
risk
florian: Collision avoidance seems expensive to compute
<tantek> Is there a user accessibility (readability) concern though
with overlapping ink that may need to override the web
author not minding about some ink overlap?
koji: This proposal seems limited to that purpose in the issue
koji: would like a more general thing
fantasai: for example?
koji: Most dtp(?) allows to control the exact line pitch, risking
overlapping content, which I think is a good model for CSS
koji: but this seems only half-way there
florian: dtp model seems useful only if you render it in the computer
of the author
astearns: Doesn't CSS allow you to have that setting line-height to
a fixed length?
fantasai: Not really. It's possible with the new line layout model
with negative margins
koji: I think what I said is in fantasai's the Absolute Model in
page 52 of fantasai's presentation
See http://fantasai.inkedblade.net/style/talks/vertical-rhythm/slides.pdf
[archive https://lists.w3.org/Archives/Public/www-archive/2020Aug/att-0000/slides.pdf
]
fantasai: So I think that you're proposing an absolute model where
we don't care whether stuff doesn't fit at all, while
loose has some limits. But I think is good for the author
to be able to opt out consciously on specific content, but
not to set a mode switch that would allow any amount of
conflicts that the author may not even see on their
computer
fantasai: I think we should not allow to switch it off for the whole
page
astearns: I like the idea of taking the behavior we already have for
ruby, and exposing it to authors
AmeliaBR: On the topic of absolute line spacing we have the
vertical-rhythm module, but IIUC the way it works is
avoiding conflicts but pushing stuff down a whole line
AmeliaBR: but this allows to keep some overlap while keeping the
vertical rhythm
dauwhe: Everything is trade-offs but sometimes avoiding the collision
is worse than the collision itself
fantasai: As long as it is still readable, but there may be cases
where not, like if the top of the capital P overlaps with
the bottom of the n
koji: I think dauwhe's case is that when the author has control of
the text and wants collisions instead of separation, and I
think it's a reasonable request
fantasai: I'm fine with collisions as long as authors are explicit
about when and how much, and the new line layout model
allows that via negative margin
fantasai: This probably needs a lot more thought and there's not any
concrete proposal on the table, just wanted to introduce
topic for thinking
AmeliaBR: Seems like a problem worth solving
<break type = 30min>
<CSS Inline topics continue in next minutes>
Received on Friday, 7 August 2020 14:15:55 UTC