W3C home > Mailing lists > Public > www-style@w3.org > May 2020

[CSSWG] Minutes Virtual F2F 2020-05-06 Part I: CSS Ruby [css-ruby]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 15 May 2020 18:47:34 -0400
Message-ID: <CADhPm3tN1U33erfFH5PwuiHCMm6H2dROA9wsz6DMGUJS-v6WSA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 15 May 2020 22:48:22 UTC