- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 11 Jun 2011 00:48:38 +0900
- To: "www-style@w3.org" <www-style@w3.org>
Many thanks to Florian for helping to create the summary.
Kyoto Forum Issues
------------------
- Reviewed feedback from Kyoto Forum on CSS. Line stacking was a major issue.
- Discussed how to represent unencoded characters; concluded that this
is a content/semantics issue, and probably needs markup to be solved.
Line Grid
---------
- Discussed line stacking and the line grid. A new proposal was drawn
up to address the issues and use cases, including for complex layouts
(floats, positioning, multicol).
- RESOLVED: Merge line grid proposal into css3-linebox. (No separate line
grid spec.)
Writing Modes
-------------
- Long discussion of 'text-orientation' cases. Concluded that all the values
are indeed justified by actual use cases. A motion to change 'vertical-right'
to 'auto' failed to gain a majority. Suggested to rename rotate-* to sideways-*.
- RESOLVED: Rename the SVG-compatibility value for text-orientation
from 'auto' to something more specific, and mark the value
at-risk.
- Reviewed how baselines work in vertical text. Nat noted that the ideographic
baseline in the images copied from css3-linebox was wrong.
- RESOLVED: Remove OpenType baselines section from the Writing Modes spec.
- Redesigned existing 'text-combine' property to work better with markup,
and to add some controls for whether/how to scale to fit.
- Reviewed interaction of 'text-orientation' and punctuation. Inconclusive,
other than "this is hard".
- Rearranged some of the new values of 'unicode-bidi' to create a simpler
and more consistent model for 'plaintext'.
- RESOLVED: The sides of a box that are drawn when it is broken across
lines is determined by the 'direction' of the parent, not
the inline itself. Fix this in CSS2.1 and CSS3 Writing Modes.
====== Full minutes below ======
Present:
David Baron (Mozilla)
Bert Bos (W3C)
John Daggett (Mozilla)
Daniel Davis (Opera)
Elika Etemad (Invited Expert)
Sylvain Galineau (Microsoft)
Vincent Hardy (Adobe)
Koji Ishii (invited Expert)
Peter Linss (HP)
Nat McCully (Adobe)
Luke Macpherson (Google)
Alex Mogilevsky (Microsoft)
Shinyu Murakami (Antenna House)
Ted O'Connor (Apple)
Florian Rivoal (Opera)
Shunchi Seko (NTT)
Shane Stevens (Google)
Kazutaka Yamamoto (NTT)
Taro Yamamoto (Adobe)
Steve Zilles (Adobe)
<RRSAgent> logging to http://www.w3.org/2011/06/02-css-irc
Meeting: CSS Working Group Face-to-Face Meeting, Kyoto, Japan
Scribe: dbaron
Agenda
------
<plinss> http://wiki.csswg.org/planning/japan-2011
Steve: Want Writing Modes, Text, and Line Grid for today, while Nat is here.
Nat: Here today, and tomorrow until noon.
Florian: Would like CSS Device Adaptation for tomorrow afternoon so
Europe can call in
Ted: Simon wants to call in for animations and transitions, so morning
better for that
various: charter
jdaggett: Would like to do css3-fonts on Saturday morning.
jdaggett: Would also like to discuss feature support (dbaron's post to list)
jdaggett: ... relates to one of font subjects and to vertical text.
Sylvain: Talk about dropping prefixes?
Sylvain: If you have to submit test cases before dropping prefixes,
and you have vendor prefixes in your test cases...
Steve: Taro can't be here after Friday for fonts.
jdaggett: I wanted to talk about sub/superscript and same origin;
probably less interesting for Taro.
jdaggett: If we wanted to talk about IVS, we could do that tomorrow.
jdaggett: fantasai put in an item about unifying variant glyphs; we can
talk about it in the context of that.
Peter: Talk about feedback from forums earlier in the meeting?
(This morning?)
Steve: Regions and Exclusions not Saturday afternoon (I have to leave)
Peter: I'll get the schedule on the wiki.
Feedback from the Kyoto Forum
-----------------------------
<transcript of forum will be posted later>
Steve: Things that struck me most from the forum: there's a requirement
for simple formatting in vertical mode, and there's also a
requirement for quality formatting in vertical mode. To me
that suggests an 80/20 solution where the default does 80% of
the cases but we need a mechanism to specify the other 20% of
the cases that require more careful control of the formatting.
Steve: Another observation: there was a big discussion of signage and
large things, and it seemed to me that was really related to
the issue of the size on the canvas vs. the size the thing was
actually displayed at.
Steve: This goes back to the discussion of how pixels relate to
concrete units.
Steve: I don't think the people doing the signs were aware they don't
have to make the fonts that size; they can make the fonts the
size of a sheet of paper and the medium they project onto
that size. So that's probably a red herring.
Alex: Nothing wrong with specifying font size in inches/centimeters.
Nat: Some authoring software has limits on font size, or may not be
able to handle a canvas that big.
?: Not a standards issue.
Nat: If we're interested, maybe Koji-san could get more feedback on
details of what the problems were with signage.
Koji: Two or three publishers repeatedly said that they tried to use
ruby but that ruby implementations changed line spacing so they
gave up.
Ted: That seems like low-hanging fruit.
Nat: A number of issues about line-height calculation we can discuss
(and then segue into grid).
Representing Unencoded Characters
---------------------------------
Koji: Other big discussion was private characters (Gaiji). Related
to IVS discussion; use cases for private characters were shown.
Koji: Important for people's names and place names.
Koji: The space of ideographs is open-ended.
Taro: Archaeologists may need to publish paper about ancient Chinese
history that needs old Chinese characters that are not widely
used in everyday Japanese.
Ted: Seems like two cases: (1) you're the archaeologist who's
discovered this character, but (2) probably more common use
case is things like personal names... political party (4 glyphs).
jdaggett: You can do kumimoji (4 glyphs) today as discretionary
ligature, which is a much better solution than trying to
define variants or new codepoints, since it's a stylization.
Koji: Kumimoji can be discretionary ligatures, but still needs creation
of fonts.
jdaggett: Styling text in an old-style way (which he suggested was a
use case for private characters) is a bad use case for codepoints.
jdaggett: ... could be standardized as an OpenType feature.
jdaggett: There are a lot of correlary cases in Western text, and there
are OpenType features to support that kind of thing.
jdaggett: We need to avoid letting stylization creep in to codepoints.
Nat: Can you get to arbitrary OpenType features from CSS?
jdaggett: With css3-fonts (and in Firefox 4), yes.
(description of how it works)
Taro: I think main usage of Gaiji (extraneous characters): variants of
unencoded (?) characters, or special symbol on keyboard in
computer manual.
Taro: I wonder if there's an easy method for user to access a glyph in
a font if such a character is unencoded.
jdaggett: CSS only goes down to the codepoint level; beyond that it's
up to the font.
jdaggett: No way to directly get a CID.
Nat: That's a problem for Japanese fonts -- the assumption that
everything is encoded is not true.
jdaggett: What are those glyphs for?
Nat: Kanji that are not encoded in Unicode and not variants of a base
character.
jdaggett: Sounds like a case for PUA.
Nat: PUA is a bad thing; in PDF we use the CID and the font. That's not
the best way to do it in the general way.
jdaggett: What's the fallback?
Nat: At the point that you're dealing with a glyph that isn't encoded,
you've really lost a lot of information. You're just talking
about a glyph, it doesn't have meaning and isn't searchable.
Nat: When you insert those glyphs with the glyph panel in InDesign --
we insert either U+FFFD or ... -- one of them we assume is a
Japanese character by its mojikumi class and one we assume is
a Roman character by its mojikumi class.
Nat: I realize adding markup saying font=... cid=... is not a good thing
to do.
Nat: But there is a definite need in Japanese fonts to access unencoded
glyphs.
Florian: ...
dbaron: It feels like we're trying to add something to CSS to work
around Unicode's failure to add something to Unicode
dbaron: I think if there's a real need for this, people should go to
Unicode and get the characters they need added to Unicode added
to Unicode
Nat: ...
fantasai: What about ideographic description (codepoints in Unicode
that allow description of a character as composition of others).
fantasai: For most characters that should get you something that's unique
and that the font could make a ligature out of.
fantasai: Doesn't deal with ..., but as an escape hatch seems much better
than using the replacement character.
Taro: Variants ... included in Adobe-Japan1 6 (?) ... possible to make a
mapping table that says that ??? maps to this combination of IVS.
Taro: IDS (?) cannot uniquely reproduce intended glyph shape.
Taro: Without Adobe-Japan1 6 and ...
fantasai: I'm not saying we should use IDS to compose glyphs; I'm saying
you can use IDS to describe the glyphs you're trying to access.
Nat: A little better than just a replacement character, but still can't
go from that to a glyph.
fantasai: Each unencoded character likely to have unique IDS.
Nat: A lot of unencoded characters are very minor variants; many not
encoded at all prior to Adobe-Japan1 4.
jdaggett: We're talking about CIDs here. I don't think most people in
room aware of what CID is. Not a generalized solution.
Nat: A CID is a glyph ID that is unique to a certain font technology
called a CID-keyed font. There's a mapping of character to glyph ID.
Because the CID numbering is standardized across fonts Adobe-Japan1.6,
1.5, 1.4 examples of collection... so you can get character that's
semantically the same even across fonts.
Nat: For TrueType fonts you just have glyph IDs which are in any order.
Florian: The problem on the encoding point is that Unicode doesn't encode
fast enough -- can't we just have the same problem with CIDs?
Nat: Adobe controls CIDs...
jdaggett: If you're using InDesign, you know the content and the font.
You can't guarantee that on the Web across devices. There's
no possible fallback mechanism here.
jdaggett: The term Gaiji is problematic -- you're not sure what people
are talking about it when they use it.
Nat: My first thought is that we need a way to access a glyph within a
font that's not dependent on Unicode. The only way I can think to
do that is saying that all bets are off, and you're depending on
the font... specify exact font/version/even checksum. Even though
it's heavy-handed, it seems necessary.
Nat: We should consider this and acknowledge that there's this need.
jdaggett: You're going to a very low level.
jdaggett: Everything we've done in CSS is predicated on dealing with a
Unicode stream.
Steve: This isn't an East Asian font problem -- my computer has a key
with a flag on it that I suspect is not encoded in Unicode.
various: might be
jdaggett: Unicode folks have encoded emoticons, which are graphics.
Apple has magical tables in fonts with 10.7.
jdaggett: Problem is that the basic model of CSS text (and the same is
true for SVG fonts) is that text you're not specifying paint --
you're specifying a mask that's used to paint, and that outline
is filled with the 'color'. Not clear what happens how
emoticons mix with the 'color' property. Other things like
this come into play, but I'm not sure how to address at CSS
level... at least until Apple has standardized these tables.
Nat: Something to be added to WOFF?
jdaggett: I think we can't define anything until somebody else has said
what the basis is.
jdaggett: I'm uncomfortable pushing CSS into areas... we shouldn't be
defining font formats. WOFF is not really a font format;
it's a font packaging format with OpenType.
Nat: My understanding is... whether or not it should go into CSS should
be based on whether the need is big enough for a convenient way
to mark up the content?
jdaggett: I'd look at it more as whether there's a stable technology in
common use that we can expose to authors.
jdaggett: I'm wary of inventing feature proposals. We can sort of push
back on the OpenType guys... for example, I've been saying the
OpenType spec needs to be more flushed out about features not
having set of defaults, which features are mutually exclusive,
which win over which others. We're gauging based on common
practice for the spec.
Nat: Counter to my proposal would be to say that you do have to have
every glyph encoded.
jdaggett: I wouldn't necessarily say that. We've had proposals to
support horizontal scaling. I think it's a good proposal,
but I think we need to take things in steps, and I think
that should go in a future version of the spec rather than
what we're writing right now. I see the problem and that
it would be good to have a solution, but I don't see a
clear path.
Nat: Maybe we could come up with a markup solution that's better than
glyph IDs.
jdaggett: I think markup would be best for this. (?)
Florian: I'm not sure markup in the best place to do ...
<florian> I meant: markup is good to specify that you want a particular
unencoded character. You still need some way to specify what
that character is supposed to look like, and that's probably
not in markup.
jdaggett: You're not styling content; you're specifying the content --
should be in markup.
(missed a little)
Steve: To represent something that isn't encoded, shouldn't use an encoding.
Nat: To some people this will be content, and to some it will be style.
Peter: There are other gray areas between content and presentation.
Peter: e.g., the 'content' property
<Bert> -> http://www.unicode.org/versions/Unicode6.0.0/ch12.pdf
Section 12.2 of Unicode describing I(deographic) D(escription) S(equences),
a way to describe how an ideographs looks in 12 steps, in
particular for ideographs that aren't in Unicode
<Bert> -> http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#AlternateGlyphs
SVG's altGlyph element [that should maybe be in HTML as well?]
Peter: actionable next steps?
jdaggett: Nat, if you want to come up with a proposal, I can work with
you on figuring out the right set of things.
Florian: I used to work on a non-HTML system... markup with image.
CSS lets you say "use an image" or "use a video", but you
can't say "use this glyph".
Peter: ...
jdaggett: Not sure content property is right
Steve: altGlyph was doing that in SVG.
jdaggett: It feels weird that authors would be authoring documents where
they were putting in spans that they then go and specify the
meaning of that span in CSS.
Ted: really want the markup to carry the meaning fully, and be able to
select for that meaning in the CSS.
jdaggett: Then you can write rules in the CSS to say how the fallback works.
Nat: Fallback can either be (a) give me what's semantically equivalent or
(b) no, I really need this glyph shape.
jdaggett: I think we don't want to map ... into a fallback process.
Nat: Thinking of ... gives real Gaiji and on phone gives semantically
equivalent base character.
jdaggett: Did we complete everything you wanted to say about Gaiji?
Koji: yes
More Agenda
-----------
Peter: Other topics we want to dive into?
Ted: Some things I thought was more an evangelism issue than feature
needed in CSS.
Ted: e.g., mixed writing modes
jdaggett: Well, this is a feature still in development.
Peter: Could be they tried and found they can't rely on it.
Koji: Another issue: CSS can't center within the block progression direction.
fantasai: Tab is working on it.
fantasai: ... in flexbox module
fantasai: Would turn box into a BFC root and the contents would be centered.
Nat: distribute lines evenly?
fantasai: Don't have that yet, could work on.
fantasai: But we do need to finish things and then work on the next thing.
More Unencoded Characters
-------------------------
jdaggett: I was surprised at a number of ... repeated instances of
misinformation. e.g., this notion that I've seen both in
tweets from Tokyo meeting and yesterday during presentation,
that SVG fonts are necessary for Gaiji. I don't understand
where these memes start, and I think it's unfortunate.
Florian: Easy bad way to do Gaiji is image, or vector graphic...
jdaggett: ... imagining features. No inherent advantage of SVG font
over OpenType font, other than maybe being able to edit live.
Peter, Florian: People have tools to make SVG fonts.
jdaggett: That's a tools problem... and there are tools (fontforge) that
can convert.
Florian: Why get it in to a font if you've drawn it in SVG?
jdaggett: It's a simplified view of how fonts work. SVG fonts draw as
a graphic rather than as text; SVG fonts draw as a graphic,
not as text. Don't have any subpixel AA, etc.
Florian: I don't think it's the right solution; there's no current
right solution.
jdaggett: I think people with certain workflows are making exaggerated
statements... is a valid workflow but shouldn't be a required
workflow.
Steve: Seems like the same problem that occurs everywhere on the Web --
if people find a way to do something, they'll use it.
Peter: It's been a characteristic of the Web (and a feature) since the
beginning.
Taro: Question about SVG Fonts: I hear from SVG advocates in Japan that
SVG fonts that it's possible to use ligature mechanism to access a
glyph in an SVG font. So in typical Western case ("fi"), you
specify component characters f and i and it results in the ligature
for fi. They want to use that mechanism to access Gaiji characters
by specifying component characters that have nothing to with the
Gaiji character.
Taro: But this destroys the character model and is incompatible with
standard glyph substitution. I wish W3C would guide them away from that.
Florian: But it shows that people want a way to say "give me that glyph
in that font".
jdaggett: But it sort of ignores the complexity. If you're displaying in
Turkish you have to be very careful. OpenType handles this.
While you could add this to SVG, it's duplicating features that
work in OpenType.
Koji: I think ??? was saying to fall back to a description of the character
(if it cannot be displayed)
fantasai thought that's what ideographic description sequences were for.
Taro: I don't think Kobayashi's intention was wrong. We don't have a
method to directly specify glyph in font, which is needed by publishers.
Taro: I'm not familiar with SVG ligature mechanism and CSS font ligature
mechanism.... that kind of usage is wrong. But understanding
necessity of directly accessing glyph.
Koji shows example with character that can't be displayed and fallback to
a textual description of the character
Steve: That's what markup jdaggett was suggesting would do.
fantasai: Isn't that what Ideographic Description Sequences are supposed
to do? Why reinvent that?
Florian: Could add markup to fallback to description of character.
jdaggett: I don't know if IDS works... not supported in any browser.
fantasai: Information is there in IDS -- says "these two characters
combine side by side", etc., which could be used to speak it out.
Florian: You want fallback that goes from these sequences to a Japanese
description? Unicode IDS is intended for machine consumption;
this fallback is intended for human consumption.
Nat: I don't think it's necessarily easy to translate from machine
description to human description. This textual description says to
take mori (three trees, 森) and replace tree with water. Which tree?
Nat: I'm still unclear how far IDC gets you -- I'd need to see it in
practice to see if it's good enough.
fantasai: The sequence can let you look up a CID, not let you try to
synthesize the glyph.
(fantasai draws on whiteboard)
<kojiishi> http://www.shuiren.org/chuden/toyoshi/syoseki/chise_ids.html
Nat: Still doesn't say you want tiny tree on top rather than fat tree on top.
Florian: But that can be glyph variants.
Taro: I think IDS may be useful for rapid comparison of IDS sequence to see
if there are any matching characters... maybe find more than one
character or maybe just one.
Taro: Granularity of glyph selection is very fine, finer than expected
for IDS.
Taro: ...., and when it fails parenthesized text could be presented to user.
Florian: Problem with using Unicode feature -- almost specifies the glyph
but not quite, and likewise for markup seems almost good enough
but not quite.
Steve: What I think I've heard so far is that markup for things that aren't
encoded is the preferred solution, and attaching to that markup
ways of accessing stuff in a font or an image to provide display
seems to be the preferred solution. In principle you could attach
one of these sequences as well, because once you have the markup
you can attach almost anything to it. So that seemed to be a
generic solution.
Steve: I'd suggest we end this topic with that.
Peter: 10-15 minute break.
<jdaggett> http://people.mozilla.org/~jdaggett/tests/cleartype-waterfall.html
Line Grid
---------
Peter: Any other feedback from forums?
Bert: You mentioned aligning the glyphs on a line to a grid. We used to
have a proposal for that in a module; don't have it anymore.
Bert: still needed?
Peter: next topic on the agenda
Nat: Feedback I heard in Tokyo and Kyoto had to do with the current
unpredictability of the traditional Japanese typographi is embox
based. Typography on the Web is not embox based. That difference
perturbs a lot of people. People assume, when designing a Web
page, that they can place text using embox placement, because
that's how they design in other contexts.
Nat: Because of standards limitations, text is placed in a Western
font metrics based way, based on Roman baseline. Attempts in
newer standards to accomodate different baselines still doesn't
get you all the way there. It allows you to align text with each
other, and within the line, but the placement of text within the
line -- my current understanding is that it's not possible to do
embox based placement.
Nat: More related to the ??? parts of what you're drawing than the
conventios of Japanese text measurement.
jdaggett: You said yesterday that when you talk about embox placement,
you are primarily talking about the stacking of lines, and
not so much about the intercharacter spacing.
Nat: Either the baseline shift or the stacking of lines.
jdaggett: So not about a horizontal grid; it's about having a constant
multiple of lines.
Nat: yes.
Nat: I think we should go through in detail the line grid proposal.
When I read through it I had several questions about what happens
when the text doesn't match the grid, and what the automatic behaviors
are supposed to be.
Nat: It didnot seem to me that the automatic behaviors will get users
what they need.
Nat: I also think the line grid proposals may be trying to do many things
at once that could be broken into separate buckets.
Nat: The main need doesn't require grid. You don't have to have a grid
if you guarantee that the text line is going to be an embox tall
and the glyphs within that line will be centered within that height.
Nat: You can hav uneven leading and different point sizes and still have
embox based typography.
Nat: If you add a grid on top of that, you get several things: frame size
will be multiple of embox size. You get gyodori (centering of title
on multiple of embox size).
Nat: So however many lines the paragraph is, you round up to the number
of grid units and center within that space.
jdaggett: So the lines that are in that paragraph don't individually line up.
Nat: Right, but the edges of it line up.
Nat: What you're missing from that is what the baseline grid gives you --
for Roman typography, you have columns side by side and you want the
baselines to line up.
Nat: If you try to shoehorn all these user scenarios into a single feature
you might miss things.
Nat: I'd like to take these apart and not say, heavy handed, you have to
use line grid and say that with line grid you might get lines
painting on top of each other (which we don't have in InDesign).
Steve: What Bert was referring to, I believe, was a proposal in css3-linebox
(not line grid), which refers to line stacking.
Bert: Not what I was referring to, but wanted to discuss.
Steve: line-stacking had a number of options from XSL but added one called
grid. Not entirely clear, but the option said that whenever you
stack something... may have treated each line separately in a title
paragraph rather than the whole thing, but would say you'd always
get an integral number of grid units in a stack. That would keep
the spacing regular without having to lay out a grid in any way.
Koji: Design grid was proposed by Microsoft... grid ... migrated into
line stacking strategy. Some important features were lost during
the migration. Would like to go back to original requirements.
<Bert> -> http://dev.w3.org/csswg/css3-linebox/#LineStacking line stacking
proposal in css3-linebox
jdaggett: A couple basic questions I have: This is a feature now in IE?
What's different about your proposal from what's in IE? Have
you gone through the linebox module?
Koji: I read the line-stacking-strategy part.
jdaggett: It seems like there's crossover in what these things are
trying to solve; we need to have one spec.
jdaggett: You're basing it on IE-like features; are these features used?
They've been in IE for a long time, no?
Koji: As I understand, IE has implemented since IE 5.5.
jdaggett: Are people using it, and if so, for what, and if not, why not?
Koji: People are not using it because it's IE-only. And people's
understanding is that its's not standard. And it's in Word too.
Florian: Since IE 5.5, there was a period where it was like the only
browser, so I don't think that's a sufficient explanation.
Koji: I'm not sure about this detail, but I think IE's implementation is
different from implementation ... Murakami-san.
jdaggett: Need more detail on that.
Koji: Current implementation in IE doesn't match spec (2001 WD of text).
Murakami: I think the older draft had problem: the line grid model in
the older draft was only in one block, not for the whole page.
So the lines line up in only one paragraph, not across them.
jdaggett: Is that how it's implemented now?
Koji: Microsoft stopped improving the feature since it was dropped.
Alex: May be different in standards mode. We don't see it used, so we
don't know what kind of support we need.
?: Other East Asian languages, not just Japanese?
Nat: Affects languages with em-square typography, Chinese, Japanese, Korean.
Koji: Has line progression part and inline direction part; line
progression part important for Roman too.
jdaggett: We also have the line spec.
Koji: line-stacking-strategy is controlled in each block, but there's
a situation where you want to turn it off once and then turn it
back, you need to know ... scope.
Nat: Sounds like we need to flesh out the requirements more.
jdaggett: That's my concern. We're not taking existing specs and
saying we need to solve this set of problems. We're saying
we need this set of features which happened to have been
specced out at some point in time
Koji: For the review, I focused on background section (scenarios) and
future section.
Koji: I want to agree on use cases and problems we want to solve
Nat: It's possible to be compliant with grid and still have problems
with placement if you don't solve the line height problem. In
Japanese traditional typography, the base font size is the only
thing contributing to the line height.
Nat: The push and pull with whether you want it to be able to write
over the next line or not, we decided not to have any automatic
protection against overlap.
Nat: As someone who tries to develop a layout engine for this stuff,
I want to have a predictable model: want UI for setting Y
position to translate to embox based world. If we're worried
about intrusions maybe it could be solved some other way.
Nat: On top of that, there's the grid. What points do you provide
to snap it to? They're on the embox.
Steve: Another piece of the line stacking strategy was properties
that turned on/off whether ruby contributed to the line height.
Nat: That seems like a hack.
dbaron: Don't think there was a mistake in the history there; just a property.
Steve: There were 4 line stacking strategies:
with embox stacking you don't want it to contribute;
with the current CSS model you probably do want it to contribute,
which is why I think there's an option.
Koji: I proposed line-stacking-ruby: auto, which is a combination.
Most publishers don't care about overlapping because they fix
before releasing. But with EPUB authors can't edit after rendering.
So ruby should not be included in line height unless it causes overlap.
Nat: So then what? You go down to zero, and that line will have different
line spacing?
Koji: also important for mobile phones, where people care about fitting
more information rather than getting regular line spacing.
Steve: I'm now confused: I understand line-stacking-strategy doesn't
define a constant grid across the space. If I'm using classic
CSS line stacking I want everything included and I won't get
collisions based on the way it's defined. So that seems to me
to deal with the ??? problem. If I want constant em-based
typography, then I have the option of setting the lne-height so
the line gap is sufficient for the kenten, ruby, underlines, so
I don't get a collision.
Steve: Depending on which strategy I either want them in or I don't want
them.
Nat: That's what happens today. You can solve this by saying: yes,
include everything that's drawing in the line-height. But then
when you center on the embox, ...
Nat: If we include ruby, kenten, etc., and make a larger line height,
we still have an ideal alignment point (the center of the embox).
But we don't have that information.
Nat: Need that to get even line spacing.
Steve: Today, in CSS, you don't know where the baseline is.
dbaron: I don't think that's true.
Nat: line grid causes gyodori
Taro: The position of the first line must be specified by the user,
and must not be changed by ... (differences between ascender and
descender).
...
Scribe: fantasai
dbaron: I don't see what in the existing CSS model breaks that, except
stuff that's specific to ruby
Florian: when you have 2 lines, the second one will be placed so that
the top of the second box is aligned with the bottom of the
first box.
Florian: If what you care is not the placement of the box, but the
content of the lines, you need the distance between baselines,
or middle-lines
Florian: If the first line contains an image, the second one's nothing
special, let's say the thir one has Ruby
Florian: These three lines will have different heights.
dbaron: Suppose the image is baseline-aligned so it sticks up, it makes
the first line bigger, but doesn't change spacing between first
and second line
Nat: image is red-herring, treated like a giant character
Nat: ruby and decorations are better
dbaron: decorations don't affect line spacing
Nat: Does in webkit
fantasai: that's a bug
dbaorn: Let's say it's an open question with ruby spec how if at all
it should affect line spacing
Florian draws three lines of text as squares
bottom line has ruby above it
Florian: spacing is different
dbaron: if you assume ruby affects line spacing, which current drafts
say it shouldn't
multiple ppl talking
Steve: The other problem is the leading goes above and below
Nat draws leading above and below the lines
Nat: If this guy's leading is different from this leading, it'll behave
differently than convention
Nat: Convention is to measure leading from top of line to next line
Nat: This is understandable to designers in Japan
Nat: But 1/2 of first line leading and 1/2 of second line leading is
confusing
Nat: It's much easier to place body text when you're only dealing with
one number
Nat: whether you measure from top of line to top of next line, or middle
of line to middle of next line
Nat: the combination of half-leading is confusing
Steve: tate-chu-yoko is always measuring as 1em, not measuring more
than that even if it overflows 1em
Nat: Often it'll stick out visually. Doesn't mean it needs to make the
line taller
Nat: For tcy, you need to make the cap-height 1em
Nat: Otherwise it doesn't look good
Koji: I think the problem you're discussing is a problem we're trying
to solve without changing the CSS model. You are trying to change
the model, it seems.
Nat: No, just trying to describe the required behavior
dbaron: You talk about authors thinking or not thinking in 1/2 leading
model
dbaron: I don't think authors understand the CSS model, be they Japanese
or Western
dbaron: Maybe we need a way for them to opt into another model.
Nat: ... embox top. If they want to do this, there are different point
sizes here, so you get a+1/2b
Nat: It's much easier to present info in embox terms, and have engine
be able to spit out CSS that may be hand-tuned ..
Nat: CSS is a half-human-readable API. If you can express things in CSS
using embox top leading model, it's so much easier.
dbaron: There's sort of two problems with that sort of leading model, I think
dbaron: related to what happens around the edges of boxes
dbaron: If you have multiple lines of text in a box, there are 2 cases
you need to worry about.
dbaron: One is the box has some visual appearance,e.g. border or background,
and you see the edges of the box
dbaron: So you need to think about the spacing between the text and the
top of the box.
dbaron: Then there's the opposite case: you have a box that's interior
to some visual effect, and you want consistent line-spacing
between that and the preceding content
dbaron: I'd be very uncomfortable with something that doesn't work right
by default for the simple cases of both of those.
<fantasai> dbaron++ :)
Steve: Getting consistent line spacing seems to be easier to do with a
model that involves snapping than stacking
Steve: Trying to get the stacking to work and have consistent spacing
gets into issues that I don't think we're solving.
Nat: Please explain?
dbaron: If you have box-with-visual-appearance
dbaron: If you're talking about leading as something that goes below a
line, you get problem with large line-spacing
dbaron: where text jams right up against the top border, and then a big
gap at the bottom
Nat: You don't add the leading at the bottom of the box.
dbaron: That works well for the case where the box does have a visual
appearance.
dbaron: but then that fails for the case where the box doesn't have a
visual appearance.
dbaron: One thing we try to preserve in CSS is that if you have a box,
and you stick a <div> in there where there are already line
breaks, the rendering doesn't change.
dbaron: A <div>, by default, should be invisible.
dbaron: If you cancel at both edges, then you lose the spacing between
the lines inside and outside the div (or before/after the div)
dbaron: Whatever model we come up with, I think we're sort of stuck with
that concept.
dbaron: We're not distinguishng between two categories of boxes
dbaron: The normal case I'm worried about is e.g. article in newspaper.
You have paragraphs of text.
dbaron: You don't want a model where space between paragraphs is different
from space between lines within paragraphs.
Nat: Now I understand why you do half on either side.
Nat: ...
Steve: You can set line-height on spans
...
Nat: when you're flowing text between two frames
dbaron: frame?
dbaron: I could try to explain existing CSS model over lunch?
<br type="lunch"/>
Scribe: TabAtkins
Nat: A bit of closure on the previous discussion.
Nat: [something about leading?]
Nat: If there's no other available thing, then maybe it's true that we're
stuck with half-leading model.
Nat: Based on the history, I think it may be possible to keep most of the
current workings if we provide a way for the UA & author to understand
where to place the em box.
Nat: That is, where does the metric belong in the convoluted package of
the line box.
Nat: What's the offset from the line-top to the top of the em box, or
whatever, and where is the offset measured from?
Nat: In InDesign, we can control this. The 0 point by default is the
roman baseline, but you can change this.
Nat: You can specify whether it's most important to match the "baseline"
of the em box to the baseline of the linebox, or the center, etc.
Nat: So once I can place my nice Japanese world on top of the linebox
accurately, then it doesn't matter very much that the rest of the
inline layou tmodel exists.
fantasai presents a new proposal
fantasai: We have a new property, 'line-grid', which takes an ident.
fantasai: Initial value is 'root'.
fantasai: It inherits.
fantasai: If you set it on an element, and no ancestor has the same value,
it creates a line-grid out of the line-height and font-size
settings.
fantasai: The line-grid consists of all of the baselines.
fantasai: If I'm inside a paragraph and I say I want "line-grid:root",
I'll get the root's grid, regardless of what other grids have
been set up between the paragraph and the root.
fantasai: A fresh grid starts at the content-box of the creating element.
dbaron: You probably want an option to say "don't put half the line-gap
at the top and bottom".
fantasai: Yes.
fantasai: The idea is just to match what the text would look like if all
the font was the same size/face/etc.
Nat: I propose an offset from the top.
[discussion saying we should wait to see how the grid actually works]
<dbaron> fantasai also said we could add an option to control that for the
text case, which would then also affect the grid establishment.
dbaron: What's the use-case for a named line-grid, instead of just
using the line-grid from an ancestor?
vhardy: You may want two floats that both use the same grid.
dbaron: What about having an outer grid, an element with sets up a new
grid, then a child that wants to use the outer grid again?
hober: Perhaps the middle content is sufficiently weird...
dbaron: Would that just be making the middle content not snap?
[dbaron isn't convinced there's an example where named grids are necessary]
[and we're continuing to listen to the rest of Elika's presentation]
fantasai: Next property is "line-snap: <baseline>".
"line-snap: <baseline> | bounds"
fantasai: It says "all the lineboxes that I'm a container for, shift them
down until they snap to my grid."
fantasai: (until its baseline snaps to the next baseline in the grid)
fantasai: The "bounds" value takes the text-top and text-bottom (embox
top and bottom)...
fantasai: And, if it fits between the text-top/text-bottom lines in the
grid, centers them in there. If it's wider, it finds the next
text-bottom that it can fit between, and then centers.
fantasai: In other words, it finds the next text-top, and then the nearest
text-bottom that it'll fit into, and centers the linebox between
those two lines.
fantasai: And the property is inherited. Also, need a none value.
"line-snap: <baseline> | bounds | none;". Initial is 'none'.
fantasai: There's a root line-grid by default, so you can use line-snap
before setting up a line-grid.
[Nat gives some example that I can't work out]
fantasai: We have a 'padding' property on boxes to shift their content
down...
hober: [translation] When you've got the container that establishes your
line-grid...
hober: The grid starts at the top of the content-box.
hober: If you have a region that happens to only partly overlap the
element that establishes the line-grid...
hober: The text will then start at a weird spot in the region, because
the grid doesn't start high enough.
fantasai: The grid extends infinitely in both directions.
Nat: So, frex, if you have some large header, you want to start the grid
at the bottom of the header.
dbaron: You can just set the linegrid on a container for the body content.
You don't have set it on the root.
Nat: [something about InDesign possibly having issues with exporting
into HTML with that]
plinss: With all due respect, we're not implementing InDesign. We just
want to hit the use-cases that are necessary for publishing.
Difficulties for existing programs to map into aren't as big a deal.
fantasai: Also, for t/r/b/l, a snap(<grid-name>) function.
Steve: What we're trying to do with this is gyodori for paragraphs.
dbaron: I was hoping to have a third property like "box-snap:bounds",
which would center boxes within the necessary number of grid units.
fantasai: If you snap both your top and bottom, you center in between.
fantasai: I think if you're positioning a box, you'd snap top to the
text-top and bottom to the text-bottom.
<dbaron> (Though the box-snap might *require* that we drop the named
grids and just go to a mechanism for establishing a new line grid.)
florian: In a kanji situation, it's common to snap images to the kanji-top.
fantasai: So, that's the overview. The box-snapping part needs work,
but I think the rest is what we want.
kojiishi: My proposal is very similar in regards to defining grids.
kojiishi: When I asked for review in Japan, descendants could be difficult
if the descendant establishes a BFC.
dbaron: Using it within a float doesn't sound that bad; using it within
something that's scrollable does.
plinss: You'd just scroll the grid.
dbaron: Okay, I guess it doesn't break the model. With floats,
overflow:scroll did.
jdaggett: What happens with varying font-sizes?
jdaggett: Do you reach a point where you suddenly get larger gaps?
fantasai: Potentially, but you can use line-stacking-strategy to decide
what to exclude from the line height calculation, so you can
still make things collide.
dbaron: So you generally would want to use a fairly restricted
line-stacking-strategy, so you don't jump line-grids very often.
<dbaron> s/line-stacking-strategy/line-stacking-strategy or line-box-contain
or whatever we end up with/
Peter: You could potentially add a value for tolerance (to allow a small
amount of overlap).
Nat: What about paragraph-level gyodori?
szilles: The t/r/b/l stuff was for that. dbaron and I think there may be
a simpler answer for that.
szilles: Involving "box-snap: bounds".
vhardy: You may want to define multiple line-grids from the same element
(at different sizes, frex).
fantasai: We can add multiple grids later if necessary.
dbaron: Yet another usecase for ::outside/inside!
alexmog: [channeling glazman] I'd hate to write an editor that exposes
multiple grids defined on the same element.
<dbaron> (we could minute it as :glazou, for pseudo-glazou :-)
<hober> shouldn't it be ::glazou?
alexmog: Ruby doesn't affect line-stacking, right?
fantasai: If it affects line/block height, yes. Otherwise, no. By default, no.
szilles: As an example, say you have a headline with some ruby on the top.
What would an editor want for this?
Nat: You'd ignore the ruby and center based on the heading. But you'd
also include some padding to make sure there's enough space for
the ruby.
[more discussion about ruby, and why you wouldn't include it in the
line height]
kojiishi: Another request in this area, for a character-based grid.
kojiishi: In Chinese, each character is snapped to the grid, whereas
in Japanese only the start and end of the line box need to
be snapped.
kojiishi: So, for example, if you have a float in the middle of some
em-based script, the shortened lines by default would probably
start off-alignment with the rest of the text.
kojiishi: This property would set up a grid in the orthogonal direction
to the line-grid, so the linebox snaps to the nearest grid.
hober: You'd want the same thing for monospaced western fonts.
Steve: though that's not 1em wide..
.
Nat: I'm still disturbed by line-stacking, with 20pt text with 120%
leading mixed with 24pt text with 120% leading, it's very difficult
to get it to work like the japanese designer would want.
Nat: They'd want the line-spacing to be based on one of those values.
Nat: [1em text, 1em spacing, 1em big text, 1em big spacing, etc.]
<dbaron> spacing -> 0.5em
Nat: I'm satisfied if we just log a note about how this half-leading
works with grids.
<nmccully> My issue is that the space between lines is dependent on
the leading value on _both_ lines, making it difficult for
the author to get the look they want.
<nmccully> If you add the ability to calculate line gap based on one
or the other line's leading (and leading origin and direction,
etc), then it makes it more predictable for Japanese authors,
I think.
fantasai: If you're snapping things to the line-grid, you may want to
snap things to the layout-grid as well.
fantasai: Have the images align with the layout-grid, for example.
szilles: Why are we using grid here? I'm asking this because we have
two orthogonal concepts.
szilles: A regular set of horizontal lines (or vertical), and a regular
set of character positions. Together they make a grid, but
independently they're not.
fantasai: Do you have a suggestion?
plinss: We can have a note about that.
alexmog: So we have a new line-grid spec from Koji. Is this the base from
which we further develop, or do we have competing proposals?
jdaggett: I think there's overlapping functionality with Linebox, but not
competing. But I don't think these should be two specs.
[discussion about how to organize the specs]
alexmog: Can we have a resolution about how we expect the specs to merge/alter?
RESOLVED: Eventually we'll have one Line spec, which includes current Linebox and Linegrid.
text-orientation
----------------
jdaggett: In section 5, there's a lot of weird lingo, like "bi-orientational
transform".
jdaggett: Can we use simpler terms here?
fantasai: Suggestions?
jdaggett: [something I couldn't quite parse about the spec not matching what
authors think of]
jdaggett: Another issue - not sure if stuff like the "intrinsic text
orientation" is the right set of controls to use.
jdaggett: Once you're in vertical-lr/rl, there's a natural orientation that
horizontal text can have.
fantasai: There's some behavior implied by the orientation, and some that's
not.
fantasai: If you're using right-to-left columns up text, you'll either
rotate [this way], or stack the text.
fantasai: And that's not intrinsic to the orientation of the script.
fantasai: [draws diagram of how Mongolian would orient horizontal text]
jdaggett: It seems like the behavior we want, rotate-normal...
fantasai: We want rotate-normal if we're a horizontal scripts. We want
vertical-right for vertical scripts.
jdaggett: The behavior of rotate-normal changes based on the writing mode.
<dbaron> vertical-lr scripts:
http://en.wikipedia.org/wiki/Mongolian_script
http://en.wikipedia.org/wiki/Manchu_script
http://en.wikipedia.org/wiki/Old_Uyghur_alphabet
<dbaron> also http://en.wikipedia.org/wiki/Clear_script
jdaggett: So why not have the 'auto' setting work most of the time.
jdaggett: There's an exception, but the normal case for most scripts is to
rotate it to the right.
fantasai: rotate-normal will rotate Chinese script sideways.
jdaggett: The default we want is called "auto" that does the right thing...
fantasai: You can't do the right thing in all cases without defining
the equivalent of rotate-left.
fantasai: I can't mix rotated English and Chinese without specifying these.
Nat: The vertical orientation specifies that English must rotate clockwise.
So that should be the default.
fantasai: Which is what you get with vertical-right (keeps the chinese
vertical) or rotate-right (rotates the Chinese too).
[something about mixing rtl and chinese/japanese]
[and some explanation of why all the values are necessary]
alexmog: It seems that the only two values that ever happen are that
character are oriented with the baseline, or they are vertical.
fantasai: [shows example of English letters being stacked, or rotated
with baseline on right or left]
dbaron: You're either leaving them in their normal orientation, or
turning them so their inline progression matches the inline
progression you're using, or the same with block progression.
fantasai: We could simplify more if we're willing to screw with the
bidi algorithm. I was trying to leave bidi alone.
jdaggett: I think we should just change "vertical-right" to "auto".
szilles: That doesn't match with SVG.
jdaggett: SVG can mess around with that themselves. It's deprecated!
fantasai: it's not deprecated in SVG yet. We're deprecating their
definition with our new one, is all.
jdaggett: Everything but vertical-right is exceptions to the general
behavior, which we should call "auto".
fantasai: So, first issue is you want to rename "vertical-right" to "auto".
fantasai: But the reasonable default behavior changes based on the context.
fantasai: You want "vertical-right" or "rotate-normal" based on Chinese
vs English, frex.
fantasai: The normal thing in Mongolian and Chinese is to use 'vertical-right',
the normal case in English, French, Arabic documents is to use
'rotate-normal'
dbaron: Are there any cases where there's embedded text rotated such that
both its inline progression does not match the inline progression
of the dominant script, and such that its block progression does
not match the block progression of the dominant script?
fantasai: Next jdagget proposal is to drop the SVG-specific values.
[...]
Nat: Not all layout engines have the same idea of what is the default
behavior.
Nat: That freedom should maybe be allowed.
fantasai: The requirements for vertical-right are that
(1) vertical scripts *must* be in their default orientation, and
(2) horizontal scripts *must* be rotated to the right
<dbaron> I think another way to look at this is that the use case for
'vertical-right' is honor-block-direction, the use case for
'upright' is honor-natural-horientation, the Mongolian example
with the English the other way around is 'honor-inline-direction',
and the 'rotate-right' and 'rotate-left' cases are layout-affecting
transforms rather than vertical text
[whole lots of discussion I have no idea about]
fantasai: I can rename 'upright' to 'stacked', if that helps.
dbaron: Maybe this is crazy, but I have an alternate model in my head
where the existing examples for rotate-right/left are
layout-affecting transforms.
dbaron: But then you still need vertical-left/right and an escape hatch,
where instead of vertical-right (honoring the block-progression
direction), you honor the inline-progression direction.
dbaron: This alternative doesn't give you [something], but that's it.
Yamamoto: When japanese characters are upright and arabic is used, naturally,
only looking at those characters, it looks natural for the arabic
characters to start at the top and proceed to the bottom.
Yamamoto: But when roman characters exist as well, their top is on the right,
but then the arabic characters are on the left side.
Yamamoto: To resolve this contradiction, publishers will set arabic from
bottom-to-top, and keep the roman on top-to-bottom.
szilles: When I rotate english to the left, it seems I'm in a bottom-to-top
mode.
fantasai: Yes.
szilles: So then, is the 'auto' value for bottom-to-top to rotate everything
left? Because there are effectively no bottom-to-top languages.
fantasai: Yes, which is why those btt languages will actually go ttb unless
you set rotate-left.
fantasai: Any other issues that need to be discussed?
szilles: Yesterday in the forum, in the shift to upright, numbers went to
traditional c/j encoding.
fantasai: It's not just a codepoint swap, they actually transformed [???]
jdaggett: It's numerical transforms.
<dbaron> 135 -> 百三十五
<dbaron> (not 135 -> 一三五!)
fantasai: escape hatch: <abbr title="百三十五">135</abbr> and
abbr { content: attr(title); }
fantasai: Escape hatch for now is just hiding the alternate form in an
attribute and pulling it in via "content: attr()".
Daniel Davis: Could rotate-right/left be baseline-right/left?
fantasai: which baseline?
<fantasai> suggestion was sideways-left, sideways-right, and sideways
(rotate-normal)
dbaron: If we ever add bottom-to-top, vertical-right is not going to be
what we want for those.
fantasai: The info we're missing to make this all super-intelligent is...
We have ltr and rtl which gives us bidi for horizontal. If we
had similar for vertical, we could do a lot more here.
fantasai: Like, ttb-rtl would let us know that it's rtl in horizontal
and ttb in vertical.
Straw Poll: The default value for text-orientation
Should it be named 'auto' or 'vertical-right'
danield: Abstain
jdaggett: auto
sylvaing: auto
dbaron: vertical-right
kojiishi: vertical-right
florian: vertical-right
szilles: auto
alexmog: auto
vhardy: auto
Bert: abstain
<dbaron> (vertical-right because I think there's actually relatively
little logic to it, because the normal behavior of Mongolian
is weird)
Taro: auto
Nat: auto
TabAtkins: abstain
hober: vertical-right
plinss: vertical-right
murakami: vertical-right
fantasai: vertical-right
7 'auto', 7 'vertical-right', 3 'abstain'
plinss: 'auto' implies it will change behavior based on something else.
dbaron: I went for 'vertical-right' because it seems that it's relying
on the fact that "normal" use in mongolian is what I would
personally consider really weird.
dbaron: And it just so happens that it all works out, because the
normal behavior for Mongolian and Chinese turn the same way.
Steve: But Mongolian written horizontally actually runs left-to-right
(due to Russian influence).
Florian: I don't like 'auto' because if you're not aware of natively
vertical scripts and you just want to turn some English to
the side, you expect 'auto' to not turn it to the side.
dbaron: oh
szilles: I'll point out that if you have vertical tabs on multiple pages,
the ones on opposite pages go in opposite directions.
<nmccully> good point about English in vertical "auto" is biased toward
Japanese default behavior, not some other convention
fantasai: The next issue is the SVG property.
fantasai: SVG basically said that they'll do what we decide on.
szilles: Can we just call the value "svg-historic"?
jdaggett: Anything except "auto".
fantasai: agreed
fantasai: I can change it to "svg-historic" or "use-glyph-orientation"
or something.
plinss: Maybe mark the value as at-risk.
RESOLVED: Renamed the 'auto' value for text-orientation, and mark the
value as at-risk.
Baselines in Vertical Text
--------------------------
jdaggett: I'm confused about how vertical-align works for vertical text.
[something about multiple baselines]
fantasai: [points to the definition in the "introduction to baselines"
chapter]
Nat: Incidentally, baselines are wrong for ideographic in the pictures.
jdaggett: This example and text and such shouldn't be in this spec, though.
It should be in the Linebox module.
jdaggett: I'm concerned that if we put non-normative text here, we'll
imply behavior to impls that may conflict with the later
normative text in Linebox.
fantasai: I need at least two baselines defined.
jdaggett: Right. We just don't need quite this much detail. There's
also stuff about metrics, which is completely unnecessary.
szilles: I can fix the diagram to just provide the necessary info.
jdaggett: And then when we talk about metrics, this is completely not
what browsers actually do.
szilles: We agreed on this text some time ago in the WG. It's in the
2.1 spec.
fantasai: Most of it.
jdaggett: Darn, then we have a larger issue.
szilles: It was put there to provide a reasonable set of fallbacks for
dealing with what happens with real-world fonts.
jdaggett: And real-world fonts in Windows use the windows metrics.
szilles: They have nothing to do with the em box.
jdaggett: A browser written on windows that's not written by adobe will
use the metrics provided by the OS, which will generally be
the windows metrics.
jdaggett: I'm not objecting that this is wrong behavior, it's just not
what impls do.
RESOLVED: Remove 4.2.1 from the Writing Modes spec.
fantasai: [explains how the spec deals with alphabetic/central baselines]
jdaggett: So the behavior for 'sub' and 'super' in vertical is to shift
left/right?
fantasai: Yes.
jdaggett: And what about when tatechuyoko(sp?) is used?
fantasai: That's defined to basically synthesize a new glyph which then
has a singular baseline.
szilles: So you're asking about what happens if there is vertical-align'd
text in tatechuyoko?
fantasai: Right now it's defined to *not* trigger tatechuyoko if there
is any further structure.
<nmccully> It should be possible to set text inside the TCY using
baselines (horizontal ones) for superscript or subscript
<nmccully> The whole thing would be centered in the vertical line
szilles: [some point about horizontal text in horizontal japanese?]
jdaggett would like some more expanatory text here.
jdaggett: "The default alignment is 'baseline', and that uses the
dominant baseline, which changes based on the writing mode."
text-combine / tate-chu-yoko
----------------------------
<jdaggett> http://people.mozilla.org/~jdaggett/images/tatechuyoko-percent.png
[looking at the email]
jdaggett: This property name was original meant for kumimoji, actually.
I also proposed "text-inline-horizontal: none | half | third | quarter".
[last was from jdaggett]
Taro: When two characters are combined, it's possible the editor wants
to condense them to get them into 1em width.
Taro: That typically applies to 2-digit numbers without a decimal point.
Taro: The case with a decimal point is kind of an exception.
Nat: We have half and quarter-width characters, but I think that's mostly
a throwback to when they weren't really scalable.
[jdaggett shows example from the spec about tatechuyoko]
jdaggett: You see the year and day are using tatechuyoko.
jdaggett: The way it's currently defined, you have to wrap each number in
spans. Ideally, you could just say "use tatechuyoko when
necessary/possible"
kojiishi: I think that 'automatic' is nice, but if we were only doing one
or the other, we should do the explicit one first.
[jdagget shows another example from the email]
jdaggett: Here you have an example of where you want to do tatechuyoko on
"up to 2" things.
The first date, with two digits, would use tatechuyoko.
The second date, with a 4-digit eyar, would stack the digits of the year,
but use tatechuyoko for the month/day, as they are still two digits.
jdaggett: Also, how does this combine with text-transform?
fantasai: Maybe text-transform would turn off automatically.
fantasai: If the number is too wide, use text-transform, otherwise use
tatechuyoko.
jdaggett: I also think it should say that under no circumstances should
it change the linebox.
ISSUE - define interaction with text-transform
ISSUE - make spec clear that the tcy is only 1em high
<fantasai> even if the glyphs bleed outside that 1em
fantasai: There's a comment in the spec about automatic tcy saying we
could maybe have a value like "digits" and a maximum number
of digits to combine.
jdaggett: In the single-digit case you may want to use wider characters,
sometimes.
<fantasai> e.g. text-combine-auto: digits 3;
fantasai: We should be able to solve that by setting text-transform:fullwidth
and turning it off when tcy applies.
fantasai: We do want a way to force tcy sometimes, too.
fantasai: If we want to deal with automatic stuff here, we can.
Nat: I think you'll definitely get requests for it. It'll be cumbersome
for authors, and tcy, in the 80% case, is just two digits, and you'll
want to auto-tcy *all* 2-digit numbers everywhere.
Nat: As long as you keep the edge cases in mind while designing the
automatic thing, it'll work.
Nat: [discussion about processing, using "anything that fits into X"
versus "all 2/3 digit numbers"]
Nat: [prefers the latter, as it doesn't require you to call down into the
font renderer before deciding whether to use tcy]
jdaggett: I mainly just wanted dates to work, so you only needed one span
to wrap a date with.
szilles: Automatic is good, but also I want to use tcy on arbitrary
characters, so we want manual forcing as well.
Nat: jdaggett's proposal doesn't get "2010" to be quarter-width and
"4" being full-width, though.
jdaggett: You can do manual overrides.
Nat: We find that anytime we do automatic, we get people angry because
they're doing something weird.
szilles: That should be okay as long as there's an ability to override
manually.
Nat: Maybe we can combine these - use tcy for 2/3/4 digits, fullwidth
for 1 digit, and let the author use whatever unicode digits they want.
Nat: If we can come up with a property for that and use it in tcy as
well, that would be nice.
fantasai: What about "text-combine-horizontal: all | digits <number>? || alpha <number>?".
"all" is entire contents, no smushing.
fantasai: "... && [half | third | quarter]"
Nat: For smushing, have the value somehow apply that it's about fitting,
whether by using specified special glyphs or by scaling the glyphs
directly.
fantasai: or "... && fit"
fantasai: So you can specify "all", which just puts it all in tcy without
smushing.
fantasai: Or "alpha <integer>" or "digits <integer>
fantasai: Which swaps alphas/digits for the appropriate-width characters
and does tcy.
<Bert> (1,000 is different from 1, 000)
"all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ]"
"none | all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ] && [ fit | scale ]"
"fit" means try to use the half/third/quarter-width glyphs first, otherwise fall back to scaling.
"none | all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ] && [ use-glyphs | scale ]"
Nat: My ideal is that by default, you don't do glyph substitution or scaling,
and you have to specify to use glyphs or scaling.
plinss: We have enough progress here now. Take the rest for later.
Vertical Text: Form Controls / Editorial
----------------------------------------
jdaggett: Next issue is that we don't have any talk about form elements.
jdaggett: It's right that CSS doesn't apply to form controls internals,
by definition, but still, the layout of a form control has a
huge impact on the layout of other things.
fantasai: I'm willing to put in examples of how form controls *should*
work in vertical text, so impls can do it right. I'm not
willing to do normative text yet, though, because I'm not
willing to define how form controls internals are exposed.
jdaggett: I just want to say "form controls follow the text direction", etc.
fantasai: It says that already.
ISSUE - put in some examples, maybe using IE9 screenshots
<Ms2ger> Hah
jdaggett: Next issue. Minor point, but I don't like that "writing-mode"
is labelled the block direction.
jdaggett: It's influencing the direction in which text flows.
Bert: "block flow direction" is a technical term that means quite a lot.
Bert: It implies a bunch of typographic rules, including what's upright
and what's rotated.
fantasai: That's "writing mode". The block flow direction basically
determines the direction in which block boxes and lineboxes
stack, and whether the linebox is horizontal or vertical.
szilles: The title of the section could just be simplified to "The
'writing-mode' Property", to avoid the confusion.
fantasai: The "writing mode" term encompasses 3 properties. The
'writing-mode' property is one aspect.
fantasai: If it was up to me I'd call it 'block-flow-direction', but
I think it's too late now.
sylvaing: Why is it too late?
fantasai: maybe I can change it
text-orientation and punctuation
--------------------------------
fantasai: Last issue is text-orientation and punctuation.
jdaggett: I was suggesting as a loose default that you should specify
all the scripts that are upright, and everything else is rotated.
jdaggett: For the common/inherited characters, use whatever the previous
script block was.
Nat: The problem we ran into is that for the ambiguous chars (U+2000),
depending on the font the glyph design was different.
Nat: Our method was that if it was in Shift-JIS and fullwidth, it was
upright. Otherwise, rotated.
Nat: [some things are crazy]
jdaggett: Short version - "we're screwed".
fantasai: There's a bunch of characters we can definitely tell for.
We say that the ambiguous characters may be UA dependent,
and point to two features that can be used for detection.
Nat: Originally a bunch of chinese characters were in PUA, and outside
our lists, so we rotated them. We switched to looking at the font
to see if it's a vertical script font, and treating the PUA as
upright then.
[chatter about fonts and such]
ISSUE - add reference to Unicode database
dbaron: Refer to a particular version of Unicode
[unminuted discussion of font features, e.g. vrt2]
Scribe: fantasai
Nat: I don't think it's useful to say to the UA to determine which ones
are upright and which ones are not, because at the point that the
engines are unfamiliar with, we don't have access to the glyph ids
Nat: I'm not sure why that's common to the ones I know, but seems to me
that it's difficult ...
Nat explains that most engines he knows split the runs into roman (sideways)
and non-roman (upright), and default mode is sideways, and vrt2
requires not splitting runs and making everything upright because
it has prerotated glyphs
<Bert> -> http://www.microsoft.com/typography/otspec/recom.htm
Adobe Type Manager/NT 4.1 and Windows 2000 require the vrt2
feature in an OT font to do vertical writing.
<Bert> -> http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2
Description of the vrt2 feature in OT
jdaggett: I think we have to do an implementation and see if using vrt2
actually work
jdaggett: puzzled why Unicode didn't deal with this stuff
fantasai: partly 'cuz they consider vertical layout out-of-scope
fantasai: and partly because the correct orientation depends on the font
and how that glyph was designed
Nat: Unicode unified various characters, so ... it's a difficult problem.
Nat: It would be nice if, Unicode is a good authority .. if they had to
go through the exercise of making this table of which ones are
upright and which are not, they might realize that maybe they should
have separate codepoints.
unicode-bidi
------------
dbaron: So you've revised the values of unicode-bidi
dbaron: I looked it over, and I think it makes sense.
dbaron: I think the revision now allows the combinations that make sense
and not some other combinations
dbaron: But I guess..
dbaron: I'm still a little fuzzy on the 'plaintext' thing and why it
converts to 'isolate', given you can use the combination of
plaintext and isolate
fantasai: oh, hm, I'm not sure why I did that
fantasai: we should have plaintext imply isolate, and then if you set
it on an inline element it sets its embedding direction like
it would have set its base direction if it were a block
fantasai: so allowing combination of plaintext and isolate does not
make sense
ACTION: fantasai edit the spec per above and check with smontagu
<trackbot> Created ACTION-321
dbaron: Other interesting constraint is that the current restrictions
on the values don't allow combinations of new values and old
values, which is nice because we can prefix the new values and
implement the whole new proposal
bidi box model
--------------
fantasai: so the remaining issue is the box model for bidi when you
break the box across lines
http://lists.w3.org/Archives/Public/www-style/2011May/0186.html
dbaron: ... yes, I think that makes sense
fantasai: So should we fix this?
dbaron: So Gecko does what the spec says in this case and it looks stupid
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22line-height%3A%202%22%3Ethis%20is%20a%20%3Cspan%20style%3D%22unicode-bidi%3A%20bidi-override%3B%20direction%3A%20rtl%3B%20border%3A%20medium%20solid%20green%22%3Eabcde%3Cbr%3Efghij%3C%2Fspan%3E%20text.%3C%2Fp%3E
fantasai: I think someone said IE9 does what we're proposing
plinss: bidi was so broken in CSS2.1 that I don't think there's a backwards-compat issue
sylvain loads the testcase
dbaron: That's what fantasai said it should do
bunch of ppl gather around dbaron and sylvain's laptops
<dbaron> so fantasai's proposal sounds good to me
RESOLVED: Fix this in CSS2.1 and CSS3 Writing Modes
Meeting closed.
Received on Friday, 10 June 2011 15:49:13 UTC