- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 20:00:03 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3u1HDO=OmV=oGFRVFnjDytsCbrvTtTO1M6rjwc6yyiUmw@mail.gmail.com>
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