- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:38:39 -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.
=========================================
Ruby
----
- 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
github.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-two-time-slot-b
Ruby
====
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 -
http://fantasai.inkedblade.net/weblog/2011/ruby/ruby-intro.png
<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
separation.
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
sufficiently.
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
similar.
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
so.
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
be.
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
off.
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
base.
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
'baseline'
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
inline.
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
works.
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…
https://codepen.io/AmeliaBR/pen/c3d360bb400822287b2650f607d66fec
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
relpos
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