- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:47:34 -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 Ruby
--------
- RESOLVED: line-height on the ruby container doesn't affect the
boxes inside (Issue #4979: Does line-height have an
effect on any of the ruby boxes?)
- RESOLVED: Ruby containers, ruby bases and ruby base containers act
like inline boxes, we'll use line-height as an example
and call out exceptions in the spec (Issue #4979)
- RESOLVED: line-height doesn't apply to annotations or annotation
containers (Issue #4979)
- RESOLVED: Nested ruby containers behave as inline boxes for the
purpose of line-height (Issue #4986: Effect of
`line-height` on nested ruby containers)
- RESOLVED: Width and height don't apply to non-atomic ruby boxes
(Issue #4974: Applicability of width & height to various
kinds of ruby boxes)
- RESOLVED: Ruby containers behave like inline boxes, and thus
behavior of these properties is the same as for regular
inline boxes (Issue #4976: Applicability and effect of
margin / border / padding on ruby containers)
- RESOLVED: Accept the proposal in the issue, with the caveat that
it should apply only to in-flow content (Issue #4980:
Box model / layout model for nested ruby containers
(block axis))
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-three-time-slot-3a
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Tab Atkins, Google
David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Emilio Cobos, Mozilla
Dave Cramer, Hachette Livre
Luke Dary, Red Hat
Elika J. Etemad, Invited Expert
Daniel Holbert, Mozilla
Jonathan Kew
Peter Linss, Invited Expert
Stanton Marcum, Amazon
Myles Maxfield, Apple
Theresa O'Connor, Apple
Xidorn Quan, Mozilla
François REMY, Invited Expert
Florian Rivoal, Invited Expert
Devin Rousso, Apple
Jen Simmons, Mozilla
Miriam Suzanne, Invited Expert
Fuqiao Xue, W3C
Scribe: emilio
CSS Ruby
========
Does line-height have an effect on any of the ruby boxes?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4979
florian: Spec should say whether line-height applies to the inside
of the ruby when applied to the ruby container box
florian: and whether it applies to the inside ruby boxes
<fantasai> sgtm
florian: I think we should define it to _not_ do anything on those
florian: Seems to be what FF does
florian: and I don't think there's a strong use case for it
xidorn: I'm slightly surprised
xidorn: I think in FF if you apply the line-height to the ruby base
it would apply
florian: May have mistested
florian: Do we agree that line-height on the ruby container does
nothing to its inside?
fantasai: So it doesn't affect the contents but affects the line,
right?
florian: Yes
fantasai: I think anything else would be weird
<dbaron> I think this all sounds fine.
RESOLVED: line-height on the ruby container doesn't affect the boxes
inside
florian: Now about ruby-base
florian: I think there's two things that are reasonable and one that
doesn't
florian: Does nothing would be ok
florian: Affects the line is ok
xidorn: I think in FF it only applies to the line if you set it on
the base and container
<xfq> In https://xfq.github.io/testing/i18n-personal-tests/chinese-group-ruby-2.html
if you change the p selector to ruby/rb the line-height seems
to be changed
<xfq> In firefox
florian: That seems fine
astearns: Can we test this and confirm?
fantasai: There's a another question which is, does it have an
effect on ruby annotations / ruby annotation containers?
florian: Just tested above and setting line-height on the ruby base
does affect the line
myles: Doesn't this resolution cause the height to double up?
xidorn: It wouldn't it's just as if you'd set it on a span in block
layout
fantasai: I think making them behave like inlines to the extent
possible is reasonable
myles: Using the maximum value of two nested elements is not exactly
the same as how <span> interact with line-height
florian: Yeah, this needs phrasing on the spec to match what inlines
do
astearns: Is there any other property that we should include in the
resolution?
fantasai: We shouldn't have a list of properties, we should say that
it should behave like inline boxes
koji: Agree, we should say that ruby boxes are the same as inline
boxes, except for some behavior changes. Why do we need to
confirm each property separately?
florian: The spec was a bit vague in the past, so want to confirm
incrementally
florian: We can resolve that and save some time
fantasai: I think there's value to go through the list, we don't
have consensus on how vertical-align behaves and such
fantasai: Though the spec should be worded generically
koji: So we shouldn't put each property that behaves the same in the
spec, right?
fantasai: Right, though we might put some as examples, but we
shouldn't build an exclusive list
RESOLVED: Ruby containers, ruby bases and ruby base containers act
like inline boxes, we'll use line-height as an example and
call out exceptions in the spec
florian: Two follow-up questions: for ruby annotations, and their
containers, does line-height do anything?
florian: I think the answer is no
florian: because they're kind of like rows, and line-height doesn't
affect layout
fantasai: It does affect laout, they take up spaces on the line.
fantasai: They need to align to each other also, so there is some
kind of line box for the annotations.
fantasai: So I think we should say it should not apply because you
can set line-height and such on the annotation container
fantasai: Since annotation container is usually anonymous, it
inherits the ruby container line-height and font size,
which causes problems
fantasai: so I think we should say it doesn't apply
florian: I disagree with one intermediate point but the conclusion
remains true
<fantasai> Here's Xidorn's issue:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0181.html
florian: Anybody thinks that line-height should apply to annotations
/ annotation-container?
xidorn: I don't see how it can be useful
koji: Did you test browsers?
florian: Yes. For chrome is harder to test because the model isn't
that close, I don't think it has annotation containers in
their current implementation
florian: but yes, in FF line-height doesn't do anything
koji: ok
RESOLVED: line-height doesn't apply to annotations or annotation
containers
Effect of `line-height` on nested ruby containers
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4986
florian: If we'd have resolved that line-height does something on
the inner boxes, then this would be more interesting
florian: but given we resolved it doesn't we should probably say
that this behaves like setting line-height on nested inline
boxes
astearns: Xidorn, you mentioned that there's two different kinds of
nesting?
florian: A ruby container nested in a ruby base should affect the
line it's in, but one nested inside an annotation it should
do nothing.
fantasai: hmm, not sure about nothing
fantasai: Should probably be whatever inlines do in that case
florian: We can agree on it being not magic
RESOLVED: Nested ruby containers behave as inline boxes for the
purpose of line-height
Applicability of width & height to various kinds of ruby boxes
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4974
fantasai: Yeah, I think based on previous resolutions they do not
apply
florian: Yeah, if we say they're like inline boxes we should say it
doesn't apply on any ruby boxes
fantasai: Maybe we can't, but if we had a ruby annotation box that
is a replaced element or a flow-root of some kind, width
and height would presumably apply to that right?
florian: We inline-ify these
fantasai: Inlinification affects the outer display type
fantasai: But it could be a replaced element or other atomic inline
fantasai: so I think these apply as long as the inner display type
is `flow` and it is not replaced
florian: Does the box fixup allow you to actually replace one of
these?
fantasai: I think it would, we may need to change the fixup?
fantasai: The in-between boxes should probably not be replaceable,
but the innermost ones probably can
florian: I don't see a point in allowing an annotation to be replaced
myles: So this is an image inside an annotation with display:
ruby-text?
fantasai: Yeah, if we allowed that then presumably width / height
should apply
florian: The other case is whether you can make it a flow-root
xidorn: I don't think you can make them flow-root because the
'display' values are separate
fantasai: What about orthogonal writing-modes?
florian: We have an issue about that
oriol: If you have display: block ruby, then the ruby container is
wrapped in a block container
oriol: so maybe width / height should apply to the container?
koji: Can you make it a block container?
fantasai: It creates two boxes
fantasai: one outside and one inside
florian: Should width / height should apply to the block wrapper?
[yes, it's a regular block box]
xidorn: Regarding writing-mode, I think we always use the
writing-mode of the line
fantasai: Separate issue
RESOLVED: Width and height don't apply to non-atomic ruby boxes
Margin / border / padding on ruby containers
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4976
florian: So margin / border / padding applies to bases and
annotations
florian: and then others get wrapped around them so that part is fine
florian: This is only about the ruby container itself
florian: As an inline you'd expect that padding / border / margin
have no effect on layout
florian: so e.g padding applies to the background but doesn't move
stuff around [in the block axis]
fantasai: So we should say that they behave like inline, not that
they have no effect, because we have controls to change
behavior there
florian: I agree, though currently in FF it's different, though I
guess that's a bug
florian: xidorn seems to agree
florian: FF does it so that stuff decreases to make room for the ruby
florian: which doesn't seem something that would happen intentionally
RESOLVED: Ruby containers behave like inline boxes, and thus
behavior of these properties is the same as for regular
inline boxes
Box model / layout model for nested ruby containers (block axis)
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4980
florian: I think this one is a little bit more involved
florian: but the previous ones have cleared the way so that we have
less moving pieces
florian: You can have a ruby nested inside the base or the annotation
florian: How these behave is interesting
florian: Let's say we have a ruby inside of a base
florian: Currently the spec defines this
florian: but it's not clear if the wrapping around descendants
happens for only direct descendants or for all descendants
florian: I think the answer that makes more sense is that the base
container is sized to wrap tightly around all the
descendants
florian: and same for the annotation containers
florian: Would probably be easier with a whiteboard...
fantasai: I think this model makes sense, if we say _in flow_
descendants
fantasai: I think it doesn't require the layout model to dig through
nested levels other than via the sizes of the boxes, which
makes this simpler
xidorn: I think FF is currently doing something magically
xidorn: Not sure how it'd differ in practice
florian: I couldn't understand what magic FF is doing, but the
effects of it seem less useful
florian: When you have nesting there's more spacing than there would
be from this model
florian: and I don't know where it is coming from
xidorn: [missed]
koji: I agree that if you look at this case the proposed model looks
good
koji: I have my preference to not define this because this is not
demanded by users and this is a special case / divergence from
inlines
florian: That part of ruby is already different
florian: bases and annotations can take border / margin / padding
koji: It seems this model requires looking at the ruby base of the bc
florian: It's not the base which is sized different from inlines,
it's the container which would be sized magically
koji: Which base?
florian: Let's have two levels, the outer rbc and the outer rb
inside which there's a ruby ...
florian: All the ruby bases and containers are sized like inlines
florian: but the outer ruby base containers gets sized to wrap all
the descendant bases and annotations
fantasai: Yeah the base container sizing needs to be special
fantasai: otherwise we can't account for "one of the bases has grown
the font-size"
fantasai: It needs to grow to fit the bases that are inside them
fantasai: I'd go further, to make this more consistent, we may want
to consider that the base container is sized to fit their
bases and any other base containers
fantasai: or maybe that it fits all of the margins of all of the
inlines inside it
fantasai: in which case the definition would just work
xidorn: It would not
xidorn: because annotation containers are not inlines
fantasai: oh, that's right
koji: ok
<xidorn> florian: could you send me an example that you see
Firefox's behavior unhelpful? from my testing there doesn't
seem to be difference on annotations.
koji: Can we mark it at risk?
florian: Not sure it's the right term for this, but we'll actually
come back to this
florian: After this we have enough info to write the block layout
florian: At risk means we can remove it when switching from cr to pr
fantasai: I think defining nested ruby so that it actually works is
the right thing to do for the spec
florian: And the spec was already hinting at this working, it just
didn't say how
<fantasai> nested ruby testcase - works in Chrome and Firefox
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cruby%3E%3Cruby%3EABC%3Crt%3Eabc%3C%2Frt%3E%3C%2Fruby%3E%3Crt%3Exyz%3C%2Fruby%3E
<fantasai> It should continue to work, fundamentally. It's ok if the
exact spacing is a bit off, but not ok if the two
annotations paint on top of each other.
florian: xidorn: the screenshots in the issue are just FF with a bit
of photoshop
xidorn: What's going on it's the whitespace taking height
xidorn: You can remove it and you see what you want
fantasai: So currently nested ruby works in both Chrome and FF
fantasai: so we need to make sure that it keeps working correctly
myles: Nested ruby is actually pretty common in books
astearns: Agree, that's why I think we should define it in the spec
RESOLVED: Accept the proposal in the issue, with the caveat that it
should apply only to in-flow content
Received on Friday, 15 May 2020 22:48:22 UTC