[CSSWG] Minutes Virtual F2F 2020-04-30 Part II: Ruby [css-ruby]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: No change, because mbp already handles this case
              sufficiently. (Issue #4932: Ruby Offset)
  - RESOLVED: The height of the content are of ruby boxes and
              annotations is calculated the same as for inline boxes
              (Issue #4935: Define the height of the content area of
              ruby bases, ruby annotations)
  - RESOLVED: Height of the content area of ruby container box is
              calculated the same as inline boxes (Issue #4936: Define
              the height of the content area of ruby containers)
  - There was no use case on vertical-align on ruby bases (Issue
      #4987) so the desire was to keep the solution simple. However,
      there was no agreement on what simple meant. There were options
      to leave it undefined, have vertical-align affect ruby bases
      like other inline boxes, or have the ruby base shift
      independently from everything else. Discussion will continue on


Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-two-time-slot-b

  Scribe: TabAtkins

Ruby Offset
  github: https://github.com/w3c/csswg-drafts/issues/4932

  florian: Request for something that allows you to move ruby
           annotation away from base text
  florian: Already in the spec, turns out
  florian: Box model isn't fully detailed, but
  florian: it *does* say that ruby bases and annotations can get mbp,
           and their margin boxes get positioned
  florian: So if you want to push ruby annotations away from base
           text, you can use mbp
  florian: So I hope we can conclude this is enough
  florian: And conclude that this isn't accidental, and we should keep
           it working as we work thru other issues
  <fremy> lgtm I guess

  florian: Also, since it's been 6years, do we need to re-explain ruby?
  [florian gives a quick rundown of what ruby is]
  <fantasai> picture -
  <astearns> https://en.wikipedia.org/wiki/Ruby_character
  <jensimmons> I've also seen folks advocate for using Ruby to
               annotate emoji — to add a bit of additional information
               to the emoji. So it's not just for CJK.
  <fantasai> abbr { display: ruby; } abbr::after { content: attr
             (title); display: ruby-text; font-size: 50%; }

  florian: So if you want to move the annotation away from the base,
           can put mbp on either and they'll move apart
  florian: Given we can do that, I don't think we need a dedicated
           property to move them apart some other way
  florian: If people agree, we'll resolve to close this issue with no
           action, because we already have the appropriate property

  AmeliaBR: There's an option to have the annotation above or below
            the base; I guess there's no logical property to say
            "offset away from the text" using margins
  AmeliaBR: Don't know enough about ruby to know if you'd likely be
            switching between top and bottom ruby in one doc, or if
            it's consistent
  florian: Mostly you have one layer of ruby, and it's mostly
           positioned according to language standards.
  florian: Rarely, you can have multiple ruby layers, and one might be
           above and one below
  florian: Also in subtitles, the top line's ruby is usually on top,
           the bottom line's usually on bottom.
  <fremy> (but they would have different margins if they represent
          different levels, so I think it's fine)
  myles: Seems like we should design based on the supposition people
         *might* ask for it
  AmeliaBR: Any practical example of... do margins work for this in
            the impls we have?
  florian: We have one impl; Firefox implements the spec. Other
           browsers have their own disconnected impls. But Firefox's
           impl does work with mbp.
  AmeliaBR: So sounds reasonable to WONTFIX
  fantasai: Sounds already fixed to me.

  stantonm: I'm not against this, but am concerned by implications.
  stantonm: People want this because the position where the UA
            displays the ruby above the text is derived from font
            metrics, and not always right.
  stantonm: So if an author is using margin to shift the annotation,
            and the font falls back, it might not have the desired
  florian: I think there's basically two usecases
  florian: One is what you just said, fixing alignment the browser
           got wrong
  florian: The other is, roughly speaking, a11y-driven
  florian: People can get too confused if the annotation is too close
           to the base. A type of dyslexia.
  florian: For that case what we have here works fine.
  florian: For the case you're describing, guess it depends on whether
           people are fixing because impls are bad, or if even once
           bugs are fixed it'll still need patching
  stantonm: Not sure. At least for us we use the ascent metric, and it
            looks pretty bad in common fonts, including NotoCJK
  fantasai: This is a general problem with the inline model that we've
            talked about solving with leading-trim
  fantasai: Recently resolved to apply it to inline boxes, and ruby
            annotations are inlines; this'll let you control what is
            the "top" of an inline box, defining it against a chosen
            font metric

  myles: A little something extra, about styling different based on
         fallback font.
  myles: There's an open issue about this, and it's a more general
         problem than just ruby
  myles: Authors often want line-height to change based on fallback
  <faceless2> https://github.com/w3c/csswg-drafts/issues/4792
  myles: So we shouldn't try to fix that case just for ruby; should do
         a general solution
  myles: Another avenue being discussed is allowing CSS to override
         the data in the font
  <tantek> I tend to agree with myles

  dbaron: It's not clear to me how much the spec says about how much
          the ruby should go; perhaps it should say more there
  florian: That's why we have 9 issues today, not just one ^_^

  Rossen: So any objection to resolving no change?

  RESOLVED: No change, because mbp already handle this case

Define the height of the content area of ruby bases, ruby annotations
  github: https://github.com/w3c/csswg-drafts/issues/4935

  florian: A number of places in the ruby spec that vaguely,
           implicitly, allude to bases and annotations being *quite
           similar* to inline boxes
  florian: But they're not inline, they're ruby, they're just very
  florian: But the precise way they're similar isn't specified

  florian: One way not specified is how to calculate height of the
           content area
  florian: For inlines we're working on specifying that
  florian: Like fantasai said, presumably once they work for inline,
           they should work for rubys
  florian: But they should. We've been implying that, but haven't said

  dbaron: I feel more strongly that ruby bases should behave like
          inlines, than that annotations should
  dbaron: Bases are basically just part of the line, and annotations
          are outside of them
  dbaron: So making bases different from inlines is bad, because it
          means when you have ruby your inline formatting becomes
          different in unexpected ways
  dbaron: While annotations might need some more differences
  <Rossen> +1 to dbaron
  florian: We do have some reasons to have bases differ from inlines;
           we don't have reasons for annotations to differ from bases.
  florian: If we find reasons later, we can differentiate them, while
           keeping the same for now
  Rossen: When ruby-overhang comes into play we might have some diffs,
          but otherwise agree

  xidorn: I think annotations should behave like inlines as well;
          annotation has a container and it basically just lines up
          inside the container like an inline
  AmeliaBR: I agree we should reuse as much inline model as possible,
            but let's not oversimplify
  AmeliaBR: Like, how line-height is integrated into the inline box
            will be more complex than just looking at the base...
  florian: Actually, that's a separate issue we'll get to

  florian: So proposed resolution is to define that the height of the
           content area of ruby bases and annotations is calculated
           the same as inline boxes
  AmeliaBR: Within what block context?
  AmeliaBR: An isolated block context created by the ruby container?
            Or same as if inlines were in the parent block context?
  fantasai: Why does that matter?
  AmeliaBR: Not sure
  fantasai: We're just talking about heights. Bases are considered to
            be part of the line: participate in line-height,
            justification, etc just as if they were inlines. They just
            get some extra space for annotations, otherwise they're
            just normal text.
  AmeliaBR: If it all adds up to the same, that's fine

  RESOLVED: The height of the content are of ruby boxes and
            annotations is calculated the same as for inline boxes

Define the height of the content area of ruby containers
  github: https://github.com/w3c/csswg-drafts/issues/4936

  florian: Around ruby bases and annotations, each have base
           containers and annotation containers, and around all of
           that there's a ruby container. We're talking about that one.
  florian: Its content height isn't defined either.
  florian: A bit subtle, we haven't talked about the various boxes
           yet. But you can put a background on the ruby container and
           see it's height.
  florian: In all impls, the answer here is the same as for previous
           question. They're treated as inlines; background goes
           behind the base layer and that's it.
  florian: Since we'll see in other issues that we don't need that box
           to grow, I'm inclined to match impls.
  <fantasai> sgtm

  <tantek> There's a lot of questions about & undefined aspects about
           Ruby layout despite there being multiple implementations,
           perhaps we need tests to see what existing implementations
           do and whether they've converged or not? Instead of a
           priori / aspirationally answering the questions of what
           "should" happen.
  <TabAtkins> Florian appears to have done so, tantek.
  <tantek> awesome TabAtkins, will check the issues more thoroughly

  AmeliaBR: What does that mean?
  fantasai: If a background is on <ruby> itself, it's the same as a
            background on a <span> around the ruby
  AmeliaBR: Is the annotation included?
  fantasai: No
  AmeliaBR: Are there use-cases for having it cover the annotation?
  <myles> AmeliaBR++
  fantasai: Dunno. Backgrounds on ruby in general doesn't appear
            existent in published materials.
  fantasai: If you don't care about linebreaking you can get that
            behavior by setting it to inline-block anyway.
  <faceless2> Styling the <rt> with <rt
              style="background-color:inherit"> works to give the
              annotation the same color
  <myles> faceless2: it's not the same, though. the RT and the RB can
          have different widths
  AmeliaBR: So if you actually want a background that highlights the
            base and the annotation, we're saying that's not possible
            without giving up fragmentation right now.
  florian: You can put a background on both bases and annotations.
  <fremy> ^ exactly what I was gonna way
  florian: They're contiguous.
  AmeliaBR: They're not the same length, are they?
  florian: They should be, yes. A little underspecified.
  fantasai: Given that the ruby box doesn't really affect layout, I
            think we should resolve on this; we can reconsider it if
            anyone asks for something different.
  Rossen: Objections?

  RESOLVED: height of the content area of ruby container box is
            calculated the same as inline boxes

vertical-align on ruby bases
  github: https://github.com/w3c/csswg-drafts/issues/4987

  florian: vertical-align on ruby bases, should it do something?
  florian: dbaron suggested a while back that it shouldn't
  florian: This simplifies things later
  florian: And afaict, no use-case for it having an effect
  florian: There's use-cases for aligning, but seems that selecting
           dominant baseline works there.

  xidorn: Currently in FF it's implemented differently.
  xidorn: I think dbaron's point is that vertical-align would affect
          height of the base container.
  xidorn: An alternative is to say base container's size is based on
          ruby base *without* vertical-align applied.
  xidorn: Because vertical-align needs to apply only after line is
          fully laid out, otherwise you don't know where things should
  xidorn: So when drawing ruby you're still in progress of laying out
          line, so you don't know where it ends up anyway.
  xidorn: So I think we can just say base container ignores the base's
          vertical-align for sizing.
  florian: Then vertical-align just visually shifts it at the end?
  xidorn: Yes. That's what ff currently does, doesn't seem to create
          lots of complexity.
  florian: I think I'm okay either way.
  stantonm: I've never seen it in ebooks.
  Rossen: So sounds like added complexity overall. Implemented in ff,
          but no real content use-cases. Perhaps we could skip?
  xidorn: I think FF's way isn't adding impl complexity.
  xidorn: Making it not do that would need some actual code to turn it

  fantasai: What do you mean by "vertical-align doesn't apply"? It
            always applies.
  florian: Everything besides "baseline" value.
  fantasai: How's that different from any other value?
  florian: They'd all shift together
  fantasai: Not if they're different font sizes
  fantasai: Two parts to vertical-align: what you're aligning, and
            how much you shift by.
  fantasai: Could say baseline-shift doesn't apply.
  fantasai: But that creates a discrepancy, where we are already
            dealing with differing positions.
  dbaron: I think fantasai's right, it's probably simplest to just say
          that vertical-align happens at the end, and still have all
          the existing rules to say what aligns to what.

  koji: Having trouble understanding the proposed resolution.
  koji: Haven't tested our impl yet. But if this doesn't have
        use-cases and there's no compat issues, is it reasonable to
        not define this in level 1?
  Rossen: My question was mostly if there are use-cases you're aware of
  koji: None that I know.
  Rossen: But also not disagreeing with fantasai and dbaron that this
          could just be a last step.
  Rossen: You could wrap it in an inline-block and align it that way.

  fantasai: Real problem here is the top and bottom values, which are
            relative to the whole line.
  fantasai: Doesn't make a lot of sense for a base to align to the top
            of the line.
  fantasai: If we could say that those values are treated as baseline
            or something, that would be fine.
  fantasai: But everything else should work; you're *always* vertical
            aligning text in a line, you can't not do it.

  dbaron: And it needs to be clear that the annotation moves with the
  xidorn: In vertical-align case, the annotation doesn't move with the
          base. The annotation is part of the annotation container, it
          doesn't move with the base itself.
  florian: The position of the annotation does depend on where the
           base ends up being, unless we make an exception here to say
           that vertical-align is a visual thing

  heycam: fantasai, you said vertical-align:top doesn't make sense.
  heycam: What if you wrap that on a span, is that equally nonsensical?
  fantasai: I think vertical-align on a span around and on the
            container itself, don't see why that shouldn't work.
  fantasai: Probably need some dfn for its "aligned subtree" though.
  fantasai: But vertical-align:top on the *base* doesn't make sense,
            can't shift the base to the top if it has stuff on top of
            it that's supposed to grow the line.
  fantasai: So we probably want to define what edges are used for
            aligning the ruby container.

  fantasai: For for bases, just want to apply it as normal, except
            that top/bottom/center (which are all relative to the line
            itself, not relative to the baseline) should be treated as
  heycam: And what about vertical-align on an annotation?
  fantasai: I think they should align with respect to each other
  florian: So no motivation for making it work, tho.
  fantasai: Motivation is that, if it doesn't work, that's a special
            exceptional behavior already.
  fantasai: And you *still* have to vertical-align *anyway*. You can't
            not do that. "Removing it" is just preventing you from
            *altering* the alignment.

  <AmeliaBR> I think we all agree we should keep it simple. We just
             don't agree what simple means.

  koji: Reason I prefer not defining vertical-align is that our
        current impl is pretty similar to wk, and in our layoutNG one,
        we're treating ruby base more similar to inline-block than
  koji: We wanna preserve our flexibility to make it more like inline
        boxes in the future.
  koji: If we make that change, this will affect how vertical-align
  koji: So unless there's an author need or compat issue, would prefer
        not to define this.
  florian: Reason I'm concerned with not defining things, is that back
           to the first issue, there is a need for authors to control
           alignment and spacing.
  florian: But if it works in some browsers, authors can depend on
           that, and we'll get frozen in behavior anyway. But
           vertical-align might not be that risky anyway.
  fantasai: I think, to the extent that we can define where we intend
            to go, we should do that in level 1. Can mark it optional
            or at risk.
  fantasai: But for people working on their impl or drafting from
            scratch, I think it's useful to know what we're aiming
            for, so they can make appropriate technical decisions
            for the future.

  dbaron: I'd add to that, since the beginning of this spec the idea
          is that ruby boxes act more like inlines than inline blocks.
          It was known at the time that this wasn't how Chrome/WK
          worked. We're N years down the path, and I'd prefer not to
          abandon that path over this issue.
  dbaron: In response to fantasai's comment about vertical-align
  dbaron: Talking about top/bottom/center, CSS2 has the idea of
          "aligned subtree", which defines what set of stuff that top/
          bottom/center *is*.
  dbaron: May want to adjust the dfn to include ruby annotations, or
          might not. But should make it clear.
  fantasai: agree
  myles: In response to dbaron, we're interested in changing our impl
         to more closely align with the ruby spec.

  florian: So do we have a proposed resolution?
  Rossen: Hearing that vertical-align on ruby base/annotation is
          independent of the container.
  dbaron: I think it's different from different ruby parts.
  dbaron: We've been talking about bases.
  Rossen: So let's scope to base. vertical-align affects bases same as
          any other inline box.
  fantasai: Except top/bottom/center are treated as baseline.
  xidorn: Can we leave that unspecified?
  koji: Is that due to current impls?
  fantasai: All of the other values align the box wrt the line.
  fantasai: But top/bottom/center align with respect to the line box.
  florian: For the other values, you align things wrt each other, then
           wrap a line around them.
  florian: For these three, you have to figure out the line box, then
           shift relative to it.
  <AmeliaBR> A test case if people want to look at what browsers
             currently do…

  dbaron: I'm not convinced there's circularity for top/bottom/center.
  fantasai: And then the annotation moves, changing the line size
  xidorn: But the annotation doesn't move
  fantasai: For the other values it does need to move tho
  Rossen: Xidorn says it doesn't move for any of the values, it's like
  fantasai: I disagree with that behavior

  dbaron: Another proposal: vertical-align affects ruby bases like
          other inline boxes. We open another issue on top/bottom/
          center to deal with those.
  florian: I don't disagree, but it doesn't answer Xidorn's question -
           layout or paint time?
  fantasai: I think it should work by laying out the boxes, aligning
            them, draw the base container around the aligned text. It
            can't work any other way.
  fantasai: Things shift relative to each other based on the dominant
            baseline anyway, no reason to not let vertical-align do
            the same.
  xidorn: ruby annotation is positioned based on the base container
          and annotation container base. *not* on specific bases.
  xidorn: So that makes me thing vertical-align on the base shouldn't
          affect the annotation position.
  fantasai: So when doing layout, ignoring vertical-align. If you have
            three bases, all different sizes, you have to align them.
  fantasai: Then you have to draw a ruby base container. Which box do
            you draw around? One of them? All of them?
  fantasai: Whichever, no reason not to vertical-align there too.
  dbaron: I think somebody needs to write down the steps for this
  dbaron: In terms of sizing and positioning base container vs
          annotation container, etc.
  * fantasai is signing up
  * xidorn is also signing up

Received on Friday, 15 May 2020 22:39:26 UTC