W3C home > Mailing lists > Public > www-style@w3.org > October 2013

[CSSWG] Minutes Paris F2F 2013-09-13 Fri IV: Ruby

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 30 Sep 2013 20:00:03 -0400
Message-ID: <CADhPm3u1HDO=OmV=oGFRVFnjDytsCbrvTtTO1M6rjwc6yyiUmw@mail.gmail.com>
To: www-style@w3.org
CSS Ruby
--------
  - The new proposal for CSS Ruby was discussed section by section.  The
      WG had several questions and concerns about most sections, but
      decided to move to WD after fantasai added some text clarifying
      the intention of the 'auto' keyword.
  - RESOLVED: Publish fantasai's Ruby draft as WD.

=====FULL MINUTES BELOW======

CSS Ruby
--------
  Scribe: dbaron

  http://dev.w3.org/csswg/css-ruby/
  fantasai: koji and I went through entire document. The problem with
            the previous ruby draft was had properties but didn't
            describe layout model.
  previous: http://www.w3.org/TR/css3-ruby/
  fantasai: Previous draft has nice pictures,
  fantasai: but it lacked box generation rules, etc.

  fantasai: We created 2 sections: the ruby formatting model which
            describes ruby-specific display properties, anonymous boxes,
            pairing with bases, whitespace, layout, styling,
            linebreaking, etc.
  fantasai: Also a handful of controls: ruby-position and ruby-align
            from the old draft, ruby-merge is new for Jukugo ruby
  fantasai: And removed some controls that seemed more obscure and also
            defined default or left it up to UA.
  fantasai: We and added default style sheet for HTML.
  fantasai: There's an old XHTML module for complex ruby layout;
             css-ruby was based on that.
  fantasai: HTML5 introduced a new ruby model with less markup; only
            handled basic use cases.
  fantasai: Ruby extension spec being worked on by Robin Berjon, in
            coordination with fantasai and i18n WG, to address use cases
            to handle various requirements.
  fantasai: This draft is written to be able to handle all the ruby
             markups so far proposed for HTML5
  fantasai: And can handle most of the stuff in complex ruby as well.

  fantasai: There's a bunch of changes we made from previous ruby stuff.
  fantasai: [summarizes] http://dev.w3.org/csswg/css-ruby/#changes
  fantasai: ... (within summary) changed values of ruby-position to
            match values of text-emphasis-position
  fantasai: Changes section should say that those keywords being changed
            are values of ruby-align.
 * darobin ping me if you need me for any specific question

  fantasai: Ruby-merge is for jukugo ruby.
  fantasai: Separate: annotation centered across each base.
  fantasai: Collapse: center all the annotations / bases together, but
            still in the markup for line breaking.
  fantasai: Auto allows UA to do what it wants.
  fantasai: The reason for auto value is that jukugo ruby in jlreq and
            JIS X 4051 is more complicated than either of these options.
            We want to allow UAs to do that, or something else
            intelligent.
  fantasai: Initial value is separate.

  SteveZ: Why call it auto?
  fantasai: Do you have a better name?
  ChrisL: That's the usual keyword for "magic thing".
  SteveZ: Usually it's the default.
  SteveZ: I'm concerned at 2 levels: (1) inconsistent implementation of
          'auto' value, which will make it useless and (2) I think using
          auto in that sense is not the normal kind of magic.
  SteveZ: The normal kind of magic is "do what most people would want
           without having to say anything."
  fantasai: We want some way for the author to get the behavior that's
            hard to describe.

  fantasai: I don't mind making that the initial value and having
            separate be an acceptable behavior for 'auto'.
  SteveZ: I think separate is what most people want most of the time.
  SteveZ: I'm looking for a little more in the way of constraints on the
          implementation, but I think I understand the difficulty of a
          full description of jukugo.
  SteveZ: But it seems to me there are some constraints you can talk
          about that an implementation should meet.
  fantasai: We gave 2 examples for what auto might mean: one is the
            algorithm in jlreq, another is render as mono-ruby if all
            ruby fit within advances and switch to group ruby otherwise,
            which is a similar effect to jlreq but much simpler.

  SteveZ: If you give a constraint about what you do in the overflow
          case, saying the intent is to do grouping in case they don't
          fit, that seems a much more useful specification than "do
          anything".
  fantasai: We can expand the description to explain what's desired.
  SteveZ: Then it won't go into effect unless there's an overflow case.
  SteveZ: That suggests a name of 'overflow'.
  fantasai: 'Overflow' not a good name; goal is not to overflow. I can
             mark the name as an issue.

  fantasai: [back to summarizing changes section]
  SteveZ: Didn't inline value of ruby-position put parentheses?
  fantasai: I don't know, it wasn't defined.
  fantasai: [looks at old draft] It didn't do anything interesting.
  SteveZ: Display:inline of the before and after to get the parentheses
          will do it.
  fantasai: [shows UA default style sheet] ("Supporting Ruby Layout"
             section)
  fantasai: Previous spec said not allowed to break within ruby base or
            annotation, which is fine for some typical cases in Japanese
            where it's just 1-3 characters, but sometimes used for much
            larger sections.

  fantasai: So in the line breaking section of spec we talk about
            breaking between bases, which is going to be the default
            case.
  fantasai: We also talk about how to do breaking within the bases and
            how you do that.
  florian: Can you do that reasonably?
  fantasai: We have to split annotation and base at same spot -- it's
            going to be an arbitrary location. Valid line breaking
            opportunities in both base and annotations.
  ChrisL: That could mean you have a word on one line and the
          explanation on another.
  fantasai: If you have a semantic correspondence that should be encoded
            in the markup -- this is for the cases where the unit of
            semantic correspondence is long enough to need breaking.
  ChrisL: Ok, its fine if two long stretches correspond that you break
          in the middle. I was more concerned about when there are
          multiple short corresponding sections, that they be kept
          together when breaking.

  florian: If this works, it's tempting to use for cases where it's not
           appropriate and will discourage authors from using proper
           semantic pairing.
  fantasai: That's unlikely since (1) default style sheet forbids this
            type of breaking and (2) people using ruby should know
            better.
  florian, SteveZ: [skepticism about (2) but not (1)]

  fantasai: [shows 'ruby-position' property]
  fantasai: It takes values as text-emphasis-position and the
            inter-character value for bopomofo.
  fantasai: Ruby merge property, which we discussed.
  fantasai: Ruby-align: takes these values from alignment spec.
  fantasai: [shows pictures in spec]
  fantasai: Wide cell -- expansion opportunities between CJK characters
            but not Latin, so [?] will effectively center but [?] will
            space out. Get behavior described in jlreq but don't have to
            inspect text content.
  fantasai: Those are the three properties, that's all we think is
             necessary.

  SteveZ: Does the ruby contribute to line height?
  fantasai: Yes, I'll explain how in a bit.

  fantasai: The section on anonymous ruby box generation to fill in
             missing boxes for when not in the markup
  fantasai: This describes how which annotation matches to which base.
  fantasai: The interesting one is nested ruby (allowed in HTML5).
  fantasai: Since ruby interacts with stuff adjacent to it, you can't
            just put a box inside another box. Nested ruby basically
            defines spanning behavior, but tree structure with multiple
            levels of ruby.
  SteveZ: One example where I see wanting nested ruby is an example in
          the old spec with University on bottom and daigaku on top.
  fantasai: It will handle that case and other more pathological cases.

  steveZ: How to get different positions on different rubys?
  fantasai: ruby-position property;
  fantasai: If there's 2 on the same side, closest to base in markup
            ends up closest to base in rendering, stacked.

  fantasai: This section is weird; if the contents of ruby annotation
            box are identical to the base, it gets automatically hidden.
            It's to handle Word's furigana. So for accessibility reasons
            and fallback behavior we hide it.
  Bert: Is identical defined?
  fantasai: There's an issue on that whether it's prior to whitespace
            collapsing. It's a DOM content string match.
  SteveZ: which form of unicode?
  fantasai/koji: Probably codepoint-by-codepoint should be sufficient.
  fantasai: I don't know about whether it should be before/after
            whitespace collapsing. I'm happy to take implementor
            opinions.

  Bert: What if content is the same but markup is different, e.g., a
        span with a color on it?
  fantasai: Maybe we should do comparison on text content? Good point.

  fantasai: The section on trimming whitespace. The goal is so you can
            write ruby with appropriate indentation but have that
            whitespace break the correct results.
  fantasai: Typically in Japanese you don't want whitespace anywhere but
            want to indent your code.
  fantasai: Current implementers strip whitespace unilaterally which
            breaks use of ruby markup for non-CJK languages
  fantasai: Have to look at content, similar to way css3-text transforms
            linebreaks to whitespace or nothing.
  fantasai: This is a little more sophisticated than existing
            implementations.

  liam: It would help if middle of that example doesn't say "However,
        this markup will:"
  fantasai: Yes, that needs fixing.
  liam: You mean the second will display *with* spaces.
  fantasai: Nothing magic other than what's in css3-text. Just saying
            you trim before/after various ruby containers, and just use
            same rules as in css3-text.
  liam: I understand, spec just needs wording fix.

  fantasai: Ruby layout section describes layout. How to deal with base
            vs. annotation being wider. Align. [missed a bunch here]
  Bert: Question about that: you determine the width by measuring. Is
        there no upper limit on how wide ruby can get? Unlike floats
        which are limited to containing block.
  fantasai: You can wrap it, though if you have a really long word or no
            wrap it will get wider.
  fantasai: Which is just like long words in float.
  SteveZ: There was a recent posting of long ruby examples. There was
          one that just fit in the height.
  SteveZ: so your question is a reasonable one.

  fantasai: This one is interesting. In this level, I put in a section
            that box properties don't apply to base container or
            annotation container boxes. I put this in because I'm
            concerned about some implementations and how they store
            their ruby internally. May not make sense for their
            implementation architecture to have a concept of a ruby
            annotation container. Let me explain [on whiteboard].
  fantasai: Interesting boxes in ruby are the base boxes and the
            annotation boxes.
  fantasai: In the CSS model we also have boxes here [around base boxes]
            and here [around annotation boxes].
  fantasai: We couldn't think of a use case for styling them, and I know
            some implementations build boxes the other way around [draws
            grouping around each base/annotation pair]
  fantasai: So it's easier to make those boxes not style-able (and thus
            undetectable), as long as inheritance and pairing works as
            it should.
  fantasai: So I said no margins/borders/padding/backgrounds/outlines,
            both for lack of use cases and to avoid constraining
            architecture of existing implementations.
  SteveZ: what about color?
  SteveZ: Ah, color inherits, it works.
  fantasai: Right. { color: green }
  fantasai: You can just set it directly on the annotation boxes
  fantasai: So you only need to style that thing is to show bounds of
            those boxes.

  SteveZ: [mumble mumble]
  fantasai: I'm a little concerned about this restriction, but don't
            want AH to have to rewrite entire implementation, given
            they're doing column-based approach.
  SteveZ: How did they handle overflow?
  SteveZ: No reason you can't relax that in the future?
  fantasai: Right
  SteveZ: The main use case seems to be debugging.

  fantasai: Then the line breaking section, we looked at that.
  fantasai: I left bidi as an issue. None of previous specs talk about
            it, but the spec need to say what happens for bidi text
            inside a ruby container.
  fantasai: There's a bunch of proposals in comments in the source
            document, but for now we're leaving it as an open issue.
  SteveZ: So if I have ruby annotations on bidi text, is that obvious
          what to do?
  fantasai: I think reordering should be controlled by bases and
            annotations controlled by bases.
  SteveZ: Unless it's jukugo.

  fantasai: The problem is spanning annotations. Need to make sure
            spanning annotations don't get broken up, since bidi
            reordering can make something that was contiguous be
            noncontiguous.
  fantasai: Can we allow bidi reordering within ruby container, but only
            allow reordering within a region with a spanning annotation
            and not outside them? Could describe it as embedding or
            something like that, but not entirely sure what model to use
            to describe that.
  fantasai: The constraint is each ruby base and each spanning
            annotation needs to remain contiguous.

  fantasai: This section describes how line-height interacts with ruby.
  fantasai: It ensures that if all lines have equal spacing and equal
            amounts/positioning of ruby annotation, there's enough room
            to avoid overlap, but ruby annotations might extend outside
            the line box.
  fantasai: If line height varies, could get overlap; it's the
            responsibility of author to avoid that.

  fantasai: In the simple cases the line is at least as tall as ruby
            plus text, but still centered in line box as normal. Ruby
            doesn't affect position of base text with regards to the
            bounds of the line box.

  SteveZ: The ruby itself is not affecting the line height? The author
          has to set the line-height to handle ruby?
  Rossen: It will affect it if line-height is 1em and base+text is
          1.5em; in that case line-height will extend to be 1.5em
  Rossen: But the layout of the base is still centered in the middle and
          ruby text will be pushed out, half inside line and half
          bleeding into previous.
  fantasai: [reads relevant text] "Therefore, ordinarily, ruby
            annotation containers ... , none of the ruby containers
            would overlap."

  fantasai: [draws] Say my line height was 1, then you add leading.
  fantasai: So if we can detect the author's line spacing and it should
            be sufficient to accomodate ruby, then we don't do anything.
            If line-height value isn't sufficient to accomodate ruby, we
            add leading to accomodate ruby.
  Rossen: [clarification question, answered]

  dbaron: The annotations don't affect line height/positioning at all,
          except for this correction you do to increase the line height
          when it's not sufficient.

  Bert: So this rule of adding leading is based only on the
        'line-height' computed value of the base and dosen't take into
        account the line box which might already be increased?
  fantasai: Yes.
  Rossen: I think it should be the line box.
  fantasai: You're adding the leading to the ruby container, not to the
            line.
  fantasai: So if you have a 2em tall image, the extra leading won't
            increase the line height.

  dbaron: But what about on the other side?
  fantasai: It only adds leading on the side the ruby is on.
  dbaron: That seems wrong.
  fantasai: The goal is that if author is providing enough line spacing,
            we don't do anything special for the ruby.
  fantasai: But if the author is not providing enough space, e.g., on a
            mobile device where they want the spacing to be tight unless
            there's ruby,
  fantasai: In that case we do want the line-height to adjust to make
            space for the ruby, just on that line.
  ChrisL: So if you want consistent line spacing, set enough space to
          allow for ruby; if you don't and want things tight, you'll get
          uneven line spacing.

  SteveZ: In the first case, you don't contribute to line box
          calculation; in the second case, you do by putting extra
          leading on top.
  fantasai: Right, and the way you tell the difference between the cases
            is we measure the specified line-height on the
            ruby-container, and if it's not enough, we add more. If it
            is enough, assume previous line has provided half of our
            space.
  SteveZ: If I'm aligning a line with ruby on it to a line grid, then
          I'd better ensure the line-height is of the first kind and
          doesn't trigger extra leading. Because if I trigger extra
          leading it'll force the alignment down an extra line.
  Rossen: I think the general rule is if you have ruby set your line
          height big enough.

  SteveZ: Previously there was a property saying whether ruby should be
          included in line-height calculation or not,
  fantasai: Instead, we're doing something more automatic here,
  fantasai: Plus a note saying line layout module might add more
            control.
  fantasai: But this is a good default behavior.
  SteveZ: I think your automatic-ness is good, I'm unconvinced yet it's
          specified in the right way, need to think more.

  fantasai: It's possible to get overlap here. e.g., failure to detect
            a previous line doesn't have your line spacing
  Rossen: You can avoid by baseline-aligning in this case, which you're
          not going to have if ... . You're essentially increasing line
          box height to be that of ruby container but still positioning
          line in middle.
  fantasai: That's not how it's done in CSS
  fantasai: [Explains]
  Rossen: [Explaining again] This was about the case where line-height
          is 1em. In which case you obviously don't have enough space
          for ruby container, which needs 1.5em.
  Rossen: In this case, 2mins ago you said you might have overlap with
          previous line.
  fantasai: [draws]
  dbaron: If you had half the room you needed, you'd just add half?
  fantasai: Yes, and all to the top.

  Rossen: [draws]
  fantasai: Alignment with other content on the line is done solely with
            the base text.
  dbaron: Which value of vertical-align are you talking about?
  SteveZ: Center alignment is not within the line box, it's with regards
          to the baseline

  Scribe: TabAtkins

  dbaron: There are only two values of vertical-align that are relative
          to the line box, top and bottom.
  dbaron: I suppose we have some vertical-text version of those?
  fantasai: No, still "top" and "bottom".
  dbaron: All the other values are relative to the parent element.
  dbaron: So the centering you do in vertical text isn't in the line
          box; it's centering with respect to some other baseline
          established by another element.
  dbaron: And the line box can be asymmetric around that line.

  szilles: The default alignment of a replaced alignment is to align its
           bottom to the dominant baseline.
  szilles: Which means in this case the replaced element would stick out
           from the side.
  Rossen_: And the ruby base by default has alignment on the center.
  fantasai: The center of the ruby base.
  fantasai: If you increase one side of the line box, it doesn't shift
            with the line box. It's not centered in regards to to the
            line box.
  fantasai: That's what dbaron is trying to say.
  fantasai: Centering the characters is not centering within a
            container.
  fantasai: You're taking a bunch of things that have a baseline, which
            happens to cut through their center, and aligning the
            baselines.

  koji: Against what baseline should they be aligned?
  koji: If it's against the center of the parent container, this model
        will serve.
  fantasai: It won't, because it's not with respect to the size of the
            glyphs.
  Rossen_: Really? For vertical text?
  fantasai: Yes.
  fantasai: There's nothing in CSS that does centering between the two
            sides of the line boxes.

  szilles: There's a wonderful note by Eric Meyer that points out how
           complex the calculation of line boxes and their relationship
           with baselines can get.
  Rossen_: And when you implement it a couple times, you should know
           exactly how screwed up it is.
  szilles: And the same is true for center.
  fantasai: Remember, we're not adding leading to the line. You're
            adding stuff to the ruby container.
  fantasai: The center baseline doesn't shift - it's still in the middle
            of the ruby base.
  fantasai: The line box extends as a result of the ruby getting taller.

  SteveZ: I agree with the intent, not convinced that it works.
  fantasai: I'm pretty convinced it works.

  Bert: I'm more concerned about case where you don't increase the
        line-height.
  fantasai: Yes, then you can get overlap,
  fantasai: But we did that because otherwise you have to inspect the
            content before you, which gets complicated. I think this is
            a reasonable compromise.
  fantasai: Some complicated cases about changing font-size or leading
            or using images might not get handled.
  fantasai: It might not handle some cases automatically and you have to
            be careful.

  szilles: I agree with the intent. I'm less convinced that it works.
  fantasai: I'm pretty convinced that it does.
  fantasai: If you do things according to the CSS box model, it should
            work. If you're doing something slightly different as a
            shortcut, it might not work.

  Bert: What about when you have a heading and a paragraph? No margin
        below the heading. First line of paragraph has some ruby on top.
  Bert: There's a risk that the ruby overlaps the heading.
  fantasai: The mitigating factor there is that you're generally
            designing a page with X amount of gap between lines in a
            paragraph, you'll generally have at least X between
            paragraph and heading already.
  fantasai: If you dont' have that, it's probably ugly anyway.

  Bert: About line-breaking.
  Bert: It says you get a break if the ruby is ???, ???
  Bert: Figure 4, there's a break opportunity inside the annotation.
  Bert: Part of the ruby annotation is on one line, some on the next.
  Bert: But it also says that the annotation can be longer than the
        base.
  Bert: So maybe an annotation on one line with empty space, then on the
        next line is all the base with the rest of the annotation.
  fantasai: No, you can't have that.

  koji: The situation is one base character, and a large unbreakable
        annotation.
  fantasai: Okay, yes, in that case you can get annotation on a line by
            itself, if you explicitly opt into annotation breaking.
  fantasai: I dunno what to do there.
  TabAtkins: Shift the whole element to the next line?
  fantasai: In Text 4, we'll probably have a value that says "suppress
            wrapping, unless there's no other opportunity on this line".
  fantasai: And we'll probably shift ruby's default behavior to that.

  fantasai: I'd like to publish a WD for what's on the site right now,
            to replace the ancient incompatible /TR version.
  <dbaron> +1

  Bert: There was a more complex case where the ruby spans into an
        earlier or later characters...
  Bert: Overhang.
  Bert: It's fine to be without, but do you have an idea how it would be
        handled?
  fantasai: The default behavior is to allow a little bit of overhang.
  fantasai: Currently it's UA defined; in the future we'll probably add
            a control.
  fantasai: There's some detail about what character is next, which
            affects whether you can overhang, and we didn't want to
            tackle this.
  fantasai: Current spec says that overhanging by a quarter-em is
            generally safe.
  koji: Most ruby is 1/3 size, so if you overhang by at most 1/3 em
        you're generally safe.
  koji: But in general overhang is complex, so we don't want to do it in
        level 1.

  fantasai: I'm going to take an action item to clarify the intention of
            the 'auto' keyword for ruby-merge.
  fantasai: The reason we went with auto is that the simple
            implementation is to automatically choose between separate
            or collapse.
  fantasai: And easiest way to do that is auto.

  ChrisL: Can you do the clarification before publishing?
  fantasai: I can do it in like 15 minutes or so.
  ChrisL: Oh, so it's not really the kind of thing that needs review
          before getting publishing?
  fantasai: No.
  ChrisL: Ok.

  RESOLVED: Publish fantasai's Ruby draft as WD.
Received on Tuesday, 1 October 2013 00:00:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 00:00:32 UTC