/irc-logs / w3c / #css / 2011-06-02 / end

Options:

# Session Start: Thu Jun 02 00:00:00 2011
# Session Ident: #css
# [00:16] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# [00:18] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [00:19] * Joins: arno (arno@192.150.10.201)
# [00:55] * Joins: dbaron (dbaron@222.151.136.131)
# [01:00] * Joins: homata (homata@58.158.182.50)
# [01:06] * Joins: nmccully (nmccully@219.127.245.113)
# [01:18] * Quits: dbaron (dbaron@222.151.136.131) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [01:56] * Bert will be about 10 minutes late, sorry
# [02:05] * Joins: myakura (d2e8220d@64.62.228.82)
# [02:05] <nmccully> I will also be a bit late, sorry
# [02:05] * Quits: nmccully (nmccully@219.127.245.113) (Quit: nmccully)
# [02:07] * Joins: arronei_ (arron.eich@131.107.0.115)
# [02:08] * Quits: arronei (arron.eich@131.107.0.73) (Ping timeout)
# [02:09] * Joins: plinss (plinss@125.207.177.35)
# [02:10] * Joins: dbaron (dbaron@125.207.177.35)
# [02:15] * Joins: smfr (smfr@17.203.14.12)
# [02:15] * Quits: hober (ted@174.143.153.77) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [02:15] * Joins: hober (ted@125.207.177.35)
# [02:17] * Quits: myakura (d2e8220d@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
# [02:18] * Joins: sylvaing (sylvaing@125.207.177.35)
# [02:20] * Joins: jdaggett (jdaggett@125.207.177.35)
# [02:20] * Joins: murakami (murakami@118.154.209.3)
# [02:21] * Joins: myakura (d2e8220d@109.169.29.95)
# [02:22] * Joins: Kazutaka (yamamoto_k@125.207.177.35)
# [02:23] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [02:23] <RRSAgent> logging to http://www.w3.org/2011/06/02-css-irc
# [02:23] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [02:23] * Joins: vhardy (vhardy@125.207.177.35)
# [02:24] <dbaron> ScribeNick: dbaron
# [02:24] * Joins: kojiishi (kojiishi@125.207.177.35)
# [02:24] <dbaron> Meeting: CSS Working Group Face-to-Face Meeting, Kyoto, Japan
# [02:28] <dbaron> Present: Daniel Davis (Opera), John Daggett (Mozilla), Sylvain Galineau (Microsoft), David Baron (Mozilla), Koji Ishii, Florian Rivoal (Opera), Steve Zilles (Adobe), Vincent Hardy (Adobe), Bert Bos (W3C), Taro Yamamoto (Adobe), Nat McCully (Adobe), Shane Stevens (Google), Luke McPherson (Google), Ted O'Connor (Apple), Peter Linss (HP), Elika Etemad (Invited Expert), Shinyu Murakami (Antenna House), Shunchi Seko (NTT), Kazutaka Yamamoto (NTT)
# [02:29] <plinss> http://wiki.csswg.org/planning/japan-2011
# [02:29] <dbaron> Topic: Agenda
# [02:30] <dbaron> Steve: Want Writing Modes, Text, and Line Grid for today
# [02:30] * Joins: shans (qw3birc@128.30.52.28)
# [02:30] <dbaron> Nat: Here today, and tomorrow until noon.
# [02:30] <dbaron> Florian: Would like CSS Device Adaptation for tomorrow afternoon so Europe can call in
# [02:30] <dbaron> Ted: Simon wants to call in for animations and transitions, so morning better for that
# [02:30] * Joins: macpherson (qw3birc@128.30.52.28)
# [02:31] * Quits: mg (mg@83.227.44.127) (Ping timeout)
# [02:31] <dbaron> Present: Daniel Davis (Opera), John Daggett (Mozilla), Sylvain Galineau (Microsoft), David Baron (Mozilla), Koji Ishii, Florian Rivoal (Opera), Steve Zilles (Adobe), Alex Mogilevsky (Microsoft), Vincent Hardy (Adobe), Bert Bos (W3C), Taro Yamamoto (Adobe), Nat McCully (Adobe), Shane Stevens (Google), Luke McPherson (Google), Tab Atkins (Google), Ted O'Connor (Apple), Peter Linss (HP), Elika Etemad (Invited Expert), Shinyu Murakami (Antenna House), Shunchi Seko
# [02:31] <dbaron> (NTT), Kazutaka Yamamoto (NTT)
# [02:31] <dbaron> various: charter
# [02:31] * Joins: nmccully (nmccully@125.207.177.35)
# [02:31] <dbaron> jdaggett: Would like to do css3-fonts on Saturday morning.
# [02:31] * Joins: florian (florianr@125.207.177.35)
# [02:31] <dbaron> jdaggett: Would also like to discuss feature support (dbaron's post to list)
# [02:32] <dbaron> jdaggett: ... relates to one of font subjects and to vertical text.
# [02:32] <macpherson> s/McPherson/Macpherson
# [02:32] <dbaron> Sylvain: Talk about dropping prefixes?
# [02:32] <dbaron> Sylvain: If you have to submit test cases before dropping prefixes, and you have vendor prefixes in your test cases...
# [02:32] <dbaron> Steve: Taro can't be here after Friday for fonts.
# [02:33] <dbaron> jdaggett: I wanted to talk about sub/superscript and same origin; probably less interesting for Taro.
# [02:33] <dbaron> jdaggett: If we wanted to talk about IVS, we could do that tomorrow.
# [02:33] <dbaron> jdaggett: Elika put in an item about unifying variant glyphs; we can talk about it in the context of that.
# [02:34] <dbaron> Peter: Talk about feedback from forums earlier in the meeting? (This morning?)
# [02:34] * Joins: TabAtkins (tabatkins@125.207.177.35)
# [02:34] * Joins: szilles (chatzilla@125.207.177.35)
# [02:34] * Joins: alexmog (qw3birc@128.30.52.28)
# [02:35] <dbaron> Steve: Regions and Exclusions not Saturday afternoon (I have to leave)
# [02:39] <dbaron> Peter: I'll get the schedule on the wiki.
# [02:40] <dbaron> Topic: Feedback on the forum
# [02:41] <dbaron> 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.
# [02:41] * Joins: ourmaninjapan (danield@125.207.177.35)
# [02:41] <dbaron> 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.
# [02:41] <dbaron> Steve: This goes back to the discussion of how pixels relate to concrete units.
# [02:42] * ourmaninjapan is now known as danield
# [02:42] <dbaron> 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 is that size. So that's probably a red herring.
# [02:42] <dbaron> Alex: Nothing wrong with specifying font size in inches/centimeters.
# [02:42] <dbaron> Nat: Some authoring software has limits on font size, or may not be able to handle a canvas that big.
# [02:43] <dbaron> ?: Not a standards issue.
# [02:43] <dbaron> Nat: If we're interested, maybe Koji-san could get more feedback on details of what the problems were with signage.
# [02:44] <dbaron> Koji: Two or three publishers repeatedly said that they tried to use ruby but that ruby implementations changed line spacing so they gave up.
# [02:44] <dbaron> Ted: That seems like low-hanging fruit.
# [02:44] <dbaron> Nat: A number of issues about line-height calculation we can discuss (and then segue into grid).
# [02:45] <dbaron> Koji: Other big discussion was private characters (Gaiji). Related to IVS discussion; use cases for private characters were shown.
# [02:45] <dbaron> Koji: Important for people's names and place names.
# [02:46] <dbaron> Koji: The space of ideographs is open-ended.
# [02:46] <dbaron> Taro: Archaeologists may need to publish paper about ancient Chinese history that needs old Chinese characters that are not widely used in everyday Japanese.
# [02:47] <dbaron> 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).
# [02:47] <dbaron> 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.
# [02:48] <dbaron> Koji: Kumimoji can be discretionary ligatures, but still needs creation of fonts.
# [02:49] <dbaron> 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.
# [02:49] <dbaron> jdaggett: ... could be standardized as an OpenType feature.
# [02:49] <dbaron> jdaggett: There are a lot of correlary cases in Western text, and there are OpenType features to support that kind of thing.
# [02:50] <dbaron> jdaggett: We need to avoid letting stylization creep in to codepoints.
# [02:50] <dbaron> Nat: Can you get to arbitrary OpenType features from CSS?
# [02:50] <dbaron> jdaggett: With css3-fonts (and in Firefox 4), yes.
# [02:50] <dbaron> (description of how it works)
# [02:51] <dbaron> Taro: I think main usage of Gaiji (extraneous characters): variants of unencoded (?) characters, or special symbol on keyboard in computer manual.
# [02:51] <dbaron> Taro: I wonder if there's an easy method for user to access a glyph in a font if such a character is unencoded.
# [02:52] <dbaron> jdaggett: CSS only goes down to the codepoint level; beyond that it's up to the font.
# [02:52] <dbaron> jdaggett: No way to directly get a CID.
# [02:52] <dbaron> Nat: That's a problem for Japanese fonts -- the assumption that everything is encoded is not true.
# [02:52] <dbaron> jdaggett: What are those glyphs for?
# [02:52] <dbaron> Nat: Kanji that are not encoded in Unicode and not variants of a base character.
# [02:53] <dbaron> jdaggett: Sounds like a case for PUA.
# [02:53] <dbaron> 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.
# [02:53] <dbaron> jdaggett: What's the fallback?
# [02:53] <dbaron> 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.
# [02:54] <dbaron> 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.
# [02:55] <dbaron> Nat: I realize adding markup saying font=... cid=... is not a good thing to do.
# [02:55] <dbaron> Nat: But there is a definite need in Japanese fonts to access unencoded glyphs.
# [02:55] <dbaron> Florian: ...
# [02:56] <fantasai> dbaron: It feels like we're trying to add something to CSS to work around Unicode's failure to add something to Unicode
# [02:56] <fantasai> 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
# [02:57] <dbaron> Nat: ...
# [02:57] <dbaron> fantasai: What about ideographic description (codepoints in Unicode that allow description of a character as composition of others).
# [02:57] <dbaron> fantasai: For most characters that should get you something that's unique and that the font could make a ligature out of.
# [02:58] <dbaron> fantasai: Doesn't deal with ..., but as an escape hatch seems much better than using the replacement character.
# [02:59] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [02:59] <dbaron> Taro: Variants ... included in Adobe-Japan1 6 (?) ... possible to make a mapping table that says that ??? maps to this combination of IVS.
# [02:59] <dbaron> Taro: IDS (?) cannot uniquely reproduce intended glyph shape.
# [03:00] <dbaron> Taro: Without Adobe-Japan1 6 and ...
# [03:00] <dbaron> 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.
# [03:00] <dbaron> Nat: A little better than just a replacement character, but still can't go from that to a glyph.
# [03:01] <dbaron> fantasai: Each unencoded character likely to have unique IDS.
# [03:02] <dbaron> Nat: A lot of unencoded characters are very minor variants; many not encoded at all prior to Adobe-Japan1 4.
# [03:02] <dbaron> jdaggett: We're talking about CIDs here. I don't think most people in room aware of what CID is. Not a generalized solution.
# [03:03] <dbaron> 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.
# [03:04] <dbaron> Nat: For TrueType fonts you just have glyph IDs which are in any order.
# [03:04] <dbaron> 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?
# [03:04] <dbaron> Nat: Adobe controls CIDs...
# [03:04] <dbaron> 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.
# [03:05] * Joins: szilles (chatzilla@125.207.177.35)
# [03:05] <dbaron> jdaggett: The term Gaiji is problematic -- you're not sure what people are talking about it when they use it.
# [03:06] <dbaron> 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.
# [03:06] <dbaron> Nat: We should consider this and acknowledge that there's this need.
# [03:06] <dbaron> jdaggett: You're going to a very low level.
# [03:06] <dbaron> jdaggett: Everything we've done in CSS is predicated on dealing with a Unicode stream.
# [03:07] <dbaron> 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.
# [03:07] <dbaron> various: might be
# [03:08] <dbaron> jdaggett: Unicode folks have encoded emoticons, which are graphics. Apple has magical tables in fonts with 10.7.
# [03:09] <dbaron> 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.
# [03:09] <dbaron> Nat: Something to be added to WOFF?
# [03:09] <dbaron> jdaggett: I think we can't define anything until somebody else has said what the basis is.
# [03:10] <dbaron> 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.
# [03:10] <dbaron> 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?
# [03:10] <dbaron> jdaggett: I'd look at it more as whether there's a stable technology in common use that we can expose to authors.
# [03:12] <dbaron> 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.
# [03:12] <dbaron> Nat: Counter to my proposal would be to say that you do have to have every glyph encoded.
# [03:13] <dbaron> 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.
# [03:13] <dbaron> Nat: Maybe we could come up with a markup solution that's better than glyph IDs.
# [03:13] <dbaron> jdaggett: I think markup would be best for this. (?)
# [03:13] <dbaron> Florian: I'm not sure markup in the best place to do ...
# [03:13] <dbaron> jdaggett: You're not styling content; you're specifying the content -- should be in markup.
# [03:15] * Quits: smfr (smfr@17.203.14.12) (Quit: smfr)
# [03:15] <dbaron> (missed a little)
# [03:15] <dbaron> Steve: To represent something that isn't encoded, shouldn't use an encoding.
# [03:15] <dbaron> Nat: To some people this will be content, and to some it will be style.
# [03:15] <dbaron> Peter: There are other gray areas between content and presentation.
# [03:15] <dbaron> Peter: e.g., the 'content' property
# [03:16] <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
# [03:16] <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?]
# [03:16] <dbaron> Peter: actionable next steps?
# [03:16] <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.
# [03:17] <dbaron> jdaggett: Nat, if you want to come up with a proposal, I can work with you on figuring out the right set of things.
# [03:17] <dbaron> 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".
# [03:18] * Joins: boblet (Adium@122.27.197.150)
# [03:18] <dbaron> Peter: ...
# [03:18] <dbaron> jdaggett: Not sure content property is right
# [03:18] <dbaron> Steve: altGlyph was doing that in SVG.
# [03:19] <dbaron> 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.
# [03:19] <dbaron> Ted: really want the markup to carry the meaning fully, and be able to select for that meaning in the CSS.
# [03:19] <dbaron> jdaggett: Then you can write rules in the CSS to say how the fallback works.
# [03:20] <dbaron> Nat: Fallback can either be (a) give me what's semantically equivalent or (b) no, I really need this glyph shape.
# [03:20] <dbaron> jdaggett: I think we don't want to map ... into a fallback process.
# [03:21] <dbaron> Nat: Thinking of ... gives real Gaiji and on phone gives semantically equivalent base character.
# [03:21] <dbaron> jdaggett: Did we complete everything you wanted to say about Gaiji?
# [03:21] <dbaron> Koji: yes
# [03:21] <dbaron> Peter: Other topics we want to dive into?
# [03:21] <dbaron> Ted: Some things I thought was more an evangelism issue than feature needed in CSS.
# [03:21] <dbaron> Ted: e.g., mixed writing modes
# [03:22] <dbaron> jdaggett: Well, this is a feature still in development.
# [03:22] <dbaron> Peter: Could be they tried and found they can't rely on it.
# [03:22] <dbaron> Koji: Another issue: CSS can't center within the block progression direction.
# [03:22] <dbaron> fantasai: Tab is working on it.
# [03:23] <dbaron> fantasai: ... in flexbox.
# [03:23] <dbaron> fantasai: Would turn box into a BFC root and the contents would be centered.
# [03:23] <dbaron> Nat: distribute lines evenly?
# [03:23] <dbaron> fantasai: Don't have that yet, could work on.
# [03:24] <dbaron> fantasai: But we do need to finish things and then work on the next thing.
# [03:24] <dbaron> 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.
# [03:25] <dbaron> Florian: Easy bad way to do Gaiji is image, or vector graphic...
# [03:25] <dbaron> jdaggett: ... imagining features. No inherent advantage of SVG font over OpenType font, other than maybe being able to edit live.
# [03:25] <dbaron> Peter, Florian: People have tools to make SVG fonts.
# [03:26] <dbaron> jdaggett: That's a tools problem... and there are tools (fontforge) that can convert.
# [03:26] <dbaron> Florian: Why get it in to a font if you've drawn it in SVG?
# [03:26] <dbaron> 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.
# [03:27] <dbaron> Florian: I don't think it's the right solution; there's no current right solution.
# [03:27] <dbaron> jdaggett: I think people with certain workflows are making exaggerated statements... is a valid workflow but shouldn't be a required workflow.
# [03:27] <dbaron> Steve: Seems like the same problem that occurs everywhere on the Web -- if people find a way to do something, they'll use it.
# [03:28] <dbaron> Peter: It's been a characteristic of the Web (and a feature) since the beginning.
# [03:30] <dbaron> 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.
# [03:30] <dbaron> Taro: But this destroys the character model and is incompatible with standard glyph substitution. I wish W3C would guide them away from that.
# [03:30] <dbaron> Florian: But it shows that people want a way to say "give me that glyph in that font".
# [03:31] <dbaron> 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 and work in OpenType.
# [03:31] <dbaron> Koji: I think ??? was saying ???.
# [03:32] <fantasai> was saying to fall back to a description of the character (if it cannot be displayed)
# [03:32] <fantasai> fantasai thought that's what ideographic description sequences were for.
# [03:32] <dbaron> 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 in font.
# [03:32] <dbaron> s/needed in font/needed by publishers/
# [03:33] <dbaron> 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.
# [03:34] * Joins: SteveZ2 (chatzilla@125.207.177.35)
# [03:34] * Quits: szilles (chatzilla@125.207.177.35) (Connection reset by peer)
# [03:34] * SteveZ2 is now known as szilles
# [03:34] <dbaron> Koji shows example with character that can't be displayed and fallback to a textual description of the character
# [03:35] <dbaron> Steve: That's what markup jdaggett was suggesting would do.
# [03:35] <dbaron> fantasai: Isn't that what Ideographic Description Sequences are supposed to do? Why reinvent that?
# [03:35] <dbaron> Florian: Could add markup to fallback to description of character.
# [03:35] <dbaron> jdaggett: I don't know if IDS works... not supported in any browser.
# [03:36] <dbaron> fantasai: Information is there in IDS -- says "these two characters combine side by side", etc., which could be used to speak it out.
# [03:37] <dbaron> 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.
# [03:38] <dbaron> 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?
# [03:38] <dbaron> 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.
# [03:39] <dbaron> fantasai: The sequence can let you look up a CID, not let you try to synthesize the glyph.
# [03:40] <dbaron> (fantasai draws on whiteboard)
# [03:40] <kojiishi> http://www.shuiren.org/chuden/toyoshi/syoseki/chise_ids.html
# [03:41] <dbaron> Nat: Still doesn't say you want tiny tree on top rather than fat tree on top.
# [03:41] <dbaron> Florian: But that can be glyph variants.
# [03:42] <dbaron> 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.
# [03:42] <dbaron> Taro: Granularity of glyph selection is very fine, finer than expected for IDS.
# [03:43] <dbaron> Taro: ...., and when it fails parenthesized text could be presented to user.
# [03:44] <dbaron> Florian: Problem with using Unicode feature -- almost specifies the glyph but not quite, and likewise for markup seems almost good enough but not quite.
# [03:45] <dbaron> 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.
# [03:45] <dbaron> Steve: I'd suggest we end this topic with that.
# [03:45] <dbaron> Peter: 10-15 minute break.
# [03:45] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [03:46] * Quits: arronei_ (arron.eich@131.107.0.115) (Quit: arronei_)
# [03:46] * Joins: arronei (arron.eich@131.107.0.115)
# [03:49] * Quits: arno (arno@192.150.10.201) (Ping timeout)
# [04:03] * Quits: florian (florianr@125.207.177.35) (Ping timeout)
# [04:06] <jdaggett> http://people.mozilla.org/~jdaggett/tests/cleartype-waterfall.html
# [04:06] <dbaron> Peter: Any other feedback from forums?
# [04:07] <dbaron> 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.
# [04:07] <dbaron> Bert: still needed?
# [04:07] <dbaron> Peter: next topic on the agenda
# [04:07] <dbaron> Topic: Line Grid
# [04:08] <dbaron> 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.
# [04:09] <dbaron> 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.
# [04:09] <dbaron> Nat: More related to the ??? parts of what you're drawing than the conventios of Japanese text measurement.
# [04:10] <dbaron> jdaggett: You said yesterday that when you talk about embox placement, you are primraily talking about the stacking of lines, and not so much about the intercharacter spacing.
# [04:10] <dbaron> Nat: Either the baseline shift or the stacking of lines.
# [04:10] <dbaron> jdaggett: So not about a horizontal grid; it's about having a constant multiple of lines.
# [04:10] <dbaron> Nat: yes.
# [04:10] <dbaron> 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.
# [04:11] <dbaron> Nat: It didnot seem to me that the automatic behaviors will get users what they need.
# [04:11] <dbaron> Nat: I also think the line grid proposals may be trying to do many things at once that could be broken into separate buckets.
# [04:11] <dbaron> 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.
# [04:11] <dbaron> Nat: You can hav uneven leading and different point sizes and still have embox based typography.
# [04:12] <dbaron> 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).
# [04:12] <dbaron> Nat: So however many lines the paragraph is, you round up to the number of grid units and center within that space.
# [04:12] <dbaron> jdaggett: So the lines that are in that paragraph don't individually line up.
# [04:13] <dbaron> Nat: Right, but the edges of it line up.
# [04:13] <dbaron> 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.
# [04:13] <dbaron> Nat: If you try to shoehorn all these user scenarios into a single feature you might miss things.
# [04:14] <dbaron> 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).
# [04:14] <dbaron> Steve: What Bert was referring to, I believe, was a proposal in css3-linebox (not line grid), which refers to line stacking.
# [04:14] <dbaron> Bert: Not what I was referring to, but wanted to discuss.
# [04:15] <dbaron> 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.
# [04:16] <dbaron> Koji: Design grid was proposed by Microsoft... grid ... migrated into line stacking strategy. Some important features were lost dduring the migration. Would like to go back to original requirements.
# [04:16] <Bert> -> http://dev.w3.org/csswg/css3-linebox/#LineStacking line stacking proposal in css3-linebox
# [04:16] <dbaron> 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?
# [04:17] <dbaron> Koji: I read the line-stacking-strategy part.
# [04:17] <dbaron> jdaggett: It seems like there's crossover in what these things are trying to solve; we need to have one spec.
# [04:17] <dbaron> jdaggett: You're basing it on IE-like features; are these features used? They've been in IE for a long time, no?
# [04:17] <dbaron> Koji: As I understand, IE has implemented since IE 5.5.
# [04:17] <dbaron> jdaggett: Are people using it, and if so, for what, and if not, why not?
# [04:18] <dbaron> 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.
# [04:18] <dbaron> 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.
# [04:18] <dbaron> Koji: I'm not sure about this detail, but I think IE's implementation is different from implementation ... Murakami-san.
# [04:18] <dbaron> jdaggett: Need more detail on that.
# [04:19] <dbaron> Koji: Current implementation in IE doesn't match spec (2001 WD of text).
# [04:20] <dbaron> 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.
# [04:20] <dbaron> jdaggett: IS that how it's implemented now?
# [04:20] <dbaron> Koji: Microsoft stopped improving the feature since it was dropped.
# [04:20] <dbaron> Alex: May be different in standards mode. We don't see it used, so we don't know what kind of support we need.
# [04:21] <dbaron> ?: Other East Asian languages, not just Japanese?
# [04:21] <dbaron> Nat: Affects languages with em-square typography, Chinese, Japanese, Korean.
# [04:21] <dbaron> Koji: Has line progression part and inline direction part; line progression part important for Roman too.
# [04:22] <dbaron> jdaggett: We also have the line spec.
# [04:22] <dbaron> 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.
# [04:22] <dbaron> Nat: Sounds like we need to flesh out the requirements more.
# [04:23] <dbaron> 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
# [04:23] <dbaron> Koji: For the review, I focused on background section (scenarios) and future section.
# [04:23] <dbaron> Koji: I want to agree on use cases and problems we want to solve
# [04:24] <dbaron> 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.
# [04:25] <dbaron> 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.
# [04:25] <dbaron> 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.
# [04:26] <dbaron> Nat: On top of that, there's the grid. What points do you provide to snap it to? They're on the embox.
# [04:26] <dbaron> Steve: Another piece of the line stacking strategy was properties that turned on/off whether ruby contributed to the line height.
# [04:26] <dbaron> Nat: That seems like a hack.
# [04:27] <dbaron> Dbaron: Don't think there was a mistake in the history there; just a property.
# [04:27] * Joins: szilles (chatzilla@125.207.177.35)
# [04:27] <dbaron> 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.
# [04:28] * Zakim excuses himself; his presence no longer seems to be needed
# [04:28] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [04:28] <dbaron> 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 ???. So ruby should not be included in line height unless it causes overlap.
# [04:28] <dbaron> Nat: So then what? You go down to zero, and that line will have different line spacing?
# [04:28] <dbaron> Koji: also important for mobile phones, where people care about fitting more information rather than getting regular line spacing.
# [04:29] <dbaron> 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 collis
# [04:29] <dbaron> ion.
# [04:30] <dbaron> Steve: Depending on which strategy I either want them in or I don't want them.
# [04:31] <dbaron> 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, ...
# [04:33] <dbaron> 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.
# [04:34] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [04:35] <dbaron> Nat: Need that to get even line spacing.
# [04:36] <dbaron> Steve: Today, in CSS, you don't know where the baseline is.
# [04:36] <dbaron> dbaron: I don't think that's true.
# [04:37] <dbaron> Nat: line grid causes gyodori
# [04:37] <dbaron> Taro: The position of the first line must be specified by the user, and must not be changed by ... (differences between ascender and descender).
# [04:39] <fantasai> ...
# [04:40] <fantasai> dbaron: I don't see what in the existing CSS model breaks that, except stuff that's specific to ruby
# [04:40] <fantasai> 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.
# [04:40] <fantasai> 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
# [04:41] <fantasai> Florian: If the first line contains an image, the second one's nothing special, let's say the thir one has Ruby
# [04:41] <fantasai> Florian: These three lines will have different heights.
# [04:41] <fantasai> 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
# [04:41] <fantasai> Nat: image is red-herring, treated like a giant character
# [04:41] <fantasai> Nat: ruby and decorations are better
# [04:42] <fantasai> dbaron: decorations don't affect line spacing
# [04:42] <fantasai> Nat: Does in webkit
# [04:42] <fantasai> fantasai: that's a bug
# [04:42] <fantasai> dbaorn: Open question with ruby spec how if at all it should affect line spacing
# [04:42] <fantasai> s/Open/Let's say it's an open/
# [04:42] <fantasai> Florian draws three lines of text as squares
# [04:42] <fantasai> bottom line has ruby above it
# [04:43] <fantasai> Florian: spacing is different
# [04:43] <fantasai> dbaron: if you assume ruby affects line spacing, which current drafts say it shouldn't
# [04:43] <fantasai> multiple ppl talking
# [04:43] <fantasai> Steve: The other problem is the leading goes above and below
# [04:43] <fantasai> Nat draws leading above and below the lines
# [04:44] <fantasai> Nat: If this guy's leading is different from this leading, it'll behave differently than convention
# [04:44] <fantasai> Nat: Convention is t measure leading from top of line to next line
# [04:44] <fantasai> Nat: This is understandable to designers in Japan
# [04:44] <fantasai> Nat: But 1/2 of first line leading and 1/2 of second line leading is confusing
# [04:45] <fantasai> Nat: It's much easier to place body text when you're only dealing with one number
# [04:45] <fantasai> Nat: whether you measure from top of line to top of next line, or middle of line to middle of next line
# [04:45] <fantasai> Nat: the combination of half-leading is confusing
# [04:46] <fantasai> Steve: tate-chu-yoko is always measuring as 1em, not measuring more than that even if it overflows 1em
# [04:47] <fantasai> Nat: Often it'll stick out visually. Doesn't mean it needs to make the line taller
# [04:47] <fantasai> Nat: For tcy, you need to make the cap-height 1em
# [04:48] <fantasai> Nat: Otherwise it doesn't look good
# [04:48] <fantasai> 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.
# [04:48] <fantasai> Nat: No, just trying to describe the required behavior
# [04:49] <fantasai> dbaron: You talk about authors thinking or not thinking in 1/2 leading model
# [04:49] <fantasai> dbaron: I don't think authors understand the CSS model, be they Japanese or Western
# [04:49] <fantasai> dbaron: Maybe we need a way for them to opt into another model.
# [04:49] * hober imagines a "model: comprehensible" rule
# [04:50] <fantasai> Nat: ... embox top. If they wnat to do this, there are different point sizes here, so you get a+1/2b
# [04:50] <fantasai> 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 ..
# [04:50] <fantasai> 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.
# [04:50] <fantasai> dbaron: There's sort of two problems with that sort of leading model, I think
# [04:51] <fantasai> dbaron: related to what happens around the edges of boxes
# [04:51] <fantasai> dbaron: If you have multiple lines of text in a box, there are 2 cases you need to worry about.
# [04:51] <fantasai> dbaron: One is the box has some visual appearance,e.g. border or background, and you see the edges of the box
# [04:51] <fantasai> dbaron: So you need to think about the spacing between the text and the top of the box.
# [04:52] <fantasai> 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
# [04:52] <fantasai> dbaron: I'd be very uncomfortable with something that doesn't work right by default for the simple cases of both of those.
# [04:52] <fantasai> dbaron++ :)
# [04:52] <fantasai> Steve: Getting consistent line spacing seems to be easier to do with a model that involves snapping than stacking
# [04:53] <fantasai> Steve: Trying to get the stacking to work and have consistent spacing gets into issues that I don't think we're solving.
# [04:53] <fantasai> Nat: Please explain?
# [04:53] <fantasai> dbaron: If you have box-with-visual-appearance
# [04:53] <fantasai> dbaron: If you're talking about leading as something that goes below a line, you get problem with large line-spacing
# [04:53] <fantasai> dbaron: where text jams right up against the top border, and then a big gap at the bottom
# [04:53] <fantasai> Nat: You don't add the leading at the bottom of the box.
# [04:54] <fantasai> dbaron: That works well for the case where the box does have a visual appearance.
# [04:54] <fantasai> dbaron: but then that fails for the case where the box doesn't ahve a visual appearance.
# [04:54] <fantasai> 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.
# [04:54] <fantasai> dbaron: A <div>, by default, should be invisible.
# [04:55] <fantasai> dbaron: If you cancel at both edges, then you lose the spacing between the lines inside and outside the div
# [04:55] <fantasai> or before/after the div
# [04:55] <fantasai> dbaron: Whatever model we come up with, I think we're sort of stuck with that concept.
# [04:55] <fantasai> dbaron: We're not distinguishng between two categories of boxes
# [04:56] <fantasai> dbaron: The normal case I'm worried about is e.g. article in newspaper. You have paragraphs of text.
# [04:56] <fantasai> dbaron: You don't want a model where space between paragraphs is different from space between lines within paragraphs.
# [04:56] <fantasai> Nat: Now I understand why you do half on either side.
# [04:56] <fantasai> Nat: ...
# [04:56] <fantasai> Steve: You can set line-height on spans
# [04:57] <fantasai> ...
# [04:57] <fantasai> Nat: when you're flowing text between two frames
# [04:57] <fantasai> dbaron: frame?
# [04:57] <fantasai> dbaron: I could try to explain existing CSS model over lunch?
# [04:57] <fantasai> <br type="lunch">
# [05:06] * Quits: vhardy (vhardy@125.207.177.35) (Quit: vhardy)
# [05:19] * Quits: Kazutaka (yamamoto_k@125.207.177.35) (Ping timeout)
# [05:43] * Joins: szilles (chatzilla@125.207.177.35)
# [05:53] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [06:04] <TabAtkins> ScribeNick: TabAtkins
# [06:05] <TabAtkins> Nat: A bit of closure on the previous discussion.
# [06:05] <TabAtkins> Nat: [something about leading?]
# [06:05] * Joins: florian (florianr@125.207.177.35)
# [06:05] <TabAtkins> Nat: If there's no other available thing, then maybe it's true that we're stuck with half-leading model.
# [06:06] <TabAtkins> 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.
# [06:06] <TabAtkins> Nat: That is, where does the metric belong in the convoluted package of the line box.
# [06:06] <TabAtkins> 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?
# [06:07] <TabAtkins> Nat: In InDesign, we can control this. The 0 point by default is the roman baseline, but you can change this.
# [06:08] <TabAtkins> 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.
# [06:08] <TabAtkins> 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.
# [06:10] <TabAtkins> fantasai presents a new proposal
# [06:10] <TabAtkins> fantasai: We have a new property, 'line-grid', which takes an ident.
# [06:10] <TabAtkins> fantasai: Initial value is 'root'.
# [06:10] <TabAtkins> fantasai: It inherits.
# [06:11] <TabAtkins> 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.
# [06:11] <TabAtkins> fantasai: The line-grid consists of all of the baselines.
# [06:13] <TabAtkins> 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.
# [06:14] <TabAtkins> fantasai: A fresh grid starts at the content-box of the creating element.
# [06:14] <TabAtkins> dbaron: You probably want an option to say "don't put half the line-gap at the top and bottom".
# [06:14] <TabAtkins> fantasai: Yes.
# [06:14] <TabAtkins> fantasai: The idea is just to match what the text would look like if all the font was the same size/face/etc.
# [06:15] * Joins: Kazutaka (yamamoto_k@125.207.177.35)
# [06:15] <TabAtkins> Nat: I propose an offset from the top.
# [06:15] <TabAtkins> [discussion saying we should wait to see how the grid actually works]
# [06:15] <TabAtkins> dbaron: What's the use-case for a named line-grid, instead of just using the line-grid from an ancestor?
# [06:16] <TabAtkins> vhardy: You may want two floats that both use the same grid.
# [06:17] <TabAtkins> 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?
# [06:17] <TabAtkins> hober: Perhaps the middle content is sufficiently weird...
# [06:17] <TabAtkins> dbaron: Would that just be making the middle content not snap?
# [06:19] <TabAtkins> [dbaron isn't convinced there's an example where named grids are necessary]
# [06:19] <TabAtkins> [and we're continuing to listen to the rest of Elika's presentation]
# [06:20] <TabAtkins> fantasai: Next property is "line-grid: <baseline>".
# [06:20] <TabAtkins> "line-grid: <baseline> | bounds"
# [06:21] <TabAtkins> fantasai: It says "all the lineboxes that I'm a container for, shift them down until they snap to my grid."
# [06:21] <TabAtkins> fantasai: (until it's baseline snaps to the next baseline in the grid)
# [06:22] <TabAtkins> fantasai: The "bounds" value takes the text-top and text-bottom (em box top and bottom)...
# [06:22] <TabAtkins> 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.
# [06:23] <TabAtkins> 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.
# [06:23] <TabAtkins> fantasai: And the property is inherited. Also, "line-grid: <baseline> | bounds | none;". Initial is 'none'.
# [06:24] <TabAtkins> fantasai: There's a root linegrid by default, so you can use line-snap before setting up a line-grid.
# [06:24] <TabAtkins> [previous references to line-grid over the past several minutes are meant to be "line-snap"]
# [06:24] <TabAtkins> [Nat gives some example that I can't work out]
# [06:24] <dbaron> Note that around where fantasai said "The idea is just to match what the text would look like if all the font was the same size/face/etc." she also said we could add an option to control that for the text case, which would then also affect the grid establishment.
# [06:25] <TabAtkins> fantasai: We have a 'padding' property on boxes to shift their content down...
# [06:26] <TabAtkins> hober: [translation] When you've got the container that establishes your line-grid...
# [06:27] <TabAtkins> hober: The grid starts at the top of the content-box.
# [06:27] <TabAtkins> hober: If you have a region that happens to only partly overlap the element that establishes the line-grid...
# [06:27] <TabAtkins> hober: The text will then start at a weird spot in the region, because the grid doesn't start high enough.
# [06:28] <TabAtkins> fantasai: The grid extends infinitely in both directions.
# [06:30] <TabAtkins> Nat: So, frex, if you have some large header, you want to start the grid at the bottom of the header.
# [06:30] <TabAtkins> dbaron: You can just set the linegrid on a container for the body content. You don't have set it on the root.
# [06:31] <TabAtkins> Nat: [something about InDesign possibly having issues with exporting into HTML with that]
# [06:31] <TabAtkins> 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.
# [06:32] <TabAtkins> fantasai: Also, for t/r/b/l, a snap(<grid-name>) function.
# [06:33] <TabAtkins> dbaron: I was hoping to have a third property like "box-snap:bounds", which would center boxes within the necessary number of grid units.
# [06:33] <dbaron> Steve: What we're trying to do with this is gyodori for paragraphs.
# [06:34] <TabAtkins> fantasai: If you snap both your top and bottom, you have to figure out which box to align.
# [06:34] <TabAtkins> fantasai: I think if you're positioning a box, you'd snap top to the text-top and bottom to the text-bottom.
# [06:35] <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.)
# [06:35] * Joins: arron (Arron@24.17.123.244)
# [06:35] <TabAtkins> florian: In a kanji situation, it's common to snap images to the kanji-top.
# [06:36] <TabAtkins> fantasai: So, that's the overview. The box-snapping part needs work, but I think the rest is what we want.
# [06:36] <TabAtkins> kojiishi: My proposal is very similar in regards to defining grids.
# [06:37] <TabAtkins> kojiishi: When I aksed for review in Japan, descendants could be difficult if the descendant establishes a BFC.
# [06:37] <TabAtkins> dbaron: Using it within a float doesn't sound that bad; using it within something that's scrollable dos.
# [06:37] <TabAtkins> s/dos/does/
# [06:37] <TabAtkins> plinss: You'd just scroll the grid.
# [06:38] <TabAtkins> dbaron: Okay, I guess it doesn't break the model. Floats kinda do.
# [06:38] <dbaron> s/Floats kinda do./With floats, overflow:scroll did./
# [06:38] <TabAtkins> jdaggett: What happens with varying font-sizes?
# [06:39] <TabAtkins> jdaggett: Do you reach a point where you suddenly get larger gaps?
# [06:39] <TabAtkins> fantasai: Potentially, but you can use line-stacking-strategy to exclude parts, so things can still collide.
# [06:39] <TabAtkins> dbaron: So you generally would want to use a fairly restrict line-stacking-strategy, so you don't jump line-grids very often.
# [06:39] <dbaron> s/line-stacking-strategy/line-stacking-strategy or line-box-contain or whatever we end up with/
# [06:40] <dbaron> Peter: You could potentially add a value for tolerance (to allow a small amount of overlap).
# [06:40] <TabAtkins> Nat: What about paragraph-level gyodori?
# [06:41] <TabAtkins> szilles: The t/r/b/l stuff was for that. Dbaron and I think there may be a simpler answer for that.
# [06:41] <TabAtkins> szilles: Involving "box-snap:bounds".
# [06:43] <TabAtkins> vhardy: You may want to define multiple line-grids from the same element (at different sizes, frex).
# [06:43] <TabAtkins> fantasai: We can add multiple grids later if necessary.
# [06:44] <TabAtkins> dbaron: Yet another usecase for ::outside/inside!
# [06:44] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [06:44] <TabAtkins> alexmog: [channeling glazman] I'd hate to write an editor that exposes multiple grids defined on the same element.
# [06:45] <dbaron> (we could minute it as :glazou, for pseudo-glazou :-)
# [06:45] <hober> shouldn't it be ::glazou?
# [06:45] * dbaron things "glazou" sounds more like "class"
# [06:46] <TabAtkins> alexmog: Ruby doesn't affect line-stacking, right?
# [06:46] <TabAtkins> fantasai: If it affects line/block height, yes. Otherwise, no. By default, no.
# [06:47] * Joins: arron (Arron@24.17.123.244)
# [06:47] <TabAtkins> szilles: As an example, say you have a headline with some ruby on the top. What would an editor want for this?
# [06:47] <TabAtkins> 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.
# [06:49] <TabAtkins> [more discussion about ruby, and why you wouldn't include it in the line height]
# [06:51] <TabAtkins> kojiishi: Another request in this area, for a character-based grid.
# [06:52] <TabAtkins> 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.
# [06:52] <dbaron> 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.
# [06:53] <TabAtkins> kojiishi: This property would set up a grid in the orthogonal direction to the line-grid, so the linebox snaps to the nearest grid.
# [06:53] <dbaron> hober: You'd want the same thing for monospaced western fonts.
# [06:53] <dbaron> Steve: though that's not 1em wide...
# [06:54] <TabAtkins> Nat: I'm still distrubed 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.
# [06:54] <TabAtkins> Nat: They'd want the line-spacing to be based on one of those values.
# [06:54] <TabAtkins> Nat: [1em text, 1em spacing, 1em big text, 1em big spacing, etc.]
# [06:54] <dbaron> spacing -> 0.5em
# [06:55] <TabAtkins> Nat: I'm satisfied if we just log a note about how this half-leading works with grids.
# [06:56] <TabAtkins> fantasai: If you're snapping things to the line-grid, you may want to snap things to the layout-grid as well.
# [06:56] <TabAtkins> fantasai: Have the images align with the layout-grid, for example.
# [06:57] <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.
# [06:58] <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.
# [06:58] <TabAtkins> szilles: Why are we using grid here? I'm asking this because we have two orthogonal concepts.
# [06:59] <TabAtkins> 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.
# [06:59] <TabAtkins> fantasai: Do you have a suggestion?
# [06:59] <TabAtkins> plinss: We can have a note about that.
# [07:00] <TabAtkins> alexmog: So we have a new line-grid spec from Koji. Is this the base fro which we further develop, or do we have competing proposals?
# [07:00] <TabAtkins> jdaggett: I think there's overlapping functionality with Linebox, but not competing. But I don't think these should be two specs.
# [07:02] * Joins: szilles (chatzilla@125.207.177.35)
# [07:03] <TabAtkins> [discussion about how to organize the specs]
# [07:03] <TabAtkins> alexmog: Can we have a resolution about how we expect the specs to merge/alter?
# [07:04] * Quits: myakura (d2e8220d@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
# [07:05] <TabAtkins> Topic: text-orientation
# [07:05] * Quits: boblet (Adium@122.27.197.150) (Ping timeout)
# [07:06] <TabAtkins> RESOLVED: Eventually we'll have one Line spec, which includes current Linebox and Linegrid.
# [07:08] <TabAtkins> jdaggett: In section 5, there's a lot of weird lingo, like "bi-orientational transform".
# [07:08] <TabAtkins> jdaggett: Can we use simpler terms here?
# [07:08] * sylvaing bi-orientational does not make me think of CSS *cough*
# [07:08] * alexmog forgot to ask if paragraph level gyodori introduces clearance
# [07:09] <TabAtkins> jdaggett: [something I couldn't quite parse about the spec not matching what authors think of]
# [07:09] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [07:10] <TabAtkins> jdaggett: Another issue - not sure if stuff like the "intrinsic text orientation" is the right set of controls to use.
# [07:11] <TabAtkins> jdaggett: Once you're in vertical-lr/rl, there's a natural orientation that horizontal text can have.
# [07:11] <TabAtkins> fantasai: There's some behavior implied by the orientation, and some that's not.
# [07:11] <TabAtkins> fantasai: If you're using right-to-left columns up text, you'll either rotate [this way], or stack the text.
# [07:11] <TabAtkins> fantasai: And that's not intrinsic to the orientation of the script.
# [07:13] <TabAtkins> fantasai: [draws diagram of how Mongolian would orient horizontal text.
# [07:17] * Joins: stearns (qw3birc@128.30.52.28)
# [07:17] <TabAtkins> jdaggett: It seems like the behavior we want, rotate-normal...
# [07:17] <TabAtkins> fantasai: We want rotate-normal if we're a horizontal scripts. We want vertical-right for vertical scripts.
# [07:18] <TabAtkins> jdaggett: The behavior of rotate-normal changes based on the writing mode.
# [07:18] <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
# [07:18] <TabAtkins> jdaggett: So why not have the 'auto' setting work most of the time.
# [07:18] <TabAtkins> jdaggett: There's an exception, but the normal case for most scripts is to rotate it to the right.
# [07:18] <TabAtkins> fantasai: rotate-normal will rotate Chinese script sideways.
# [07:18] <dbaron> also http://en.wikipedia.org/wiki/Clear_script
# [07:19] * Joins: szilles (chatzilla@125.207.177.35)
# [07:19] <TabAtkins> jdaggett: The default we want is called "auto" that does the right thing...
# [07:19] <TabAtkins> fantasai: You can't do the right thing in all cases without defining the equivalent of rotate-left.
# [07:20] <TabAtkins> fantasai: I can't mix rotated English and Chinese without specifying these.
# [07:20] <TabAtkins> Nat: The vertical orientation specifies that English must rotate clockwise. So that should be the default.
# [07:21] <TabAtkins> fantasai: Which is what you get with vertical-right (keeps the chinese vertical) or rotate-right (rotates the Chinese too).
# [07:22] <TabAtkins> [something about mixing rtl and chinese/japanese]
# [07:23] <TabAtkins> [and some explanation of why all the values are necessary]
# [07:24] <TabAtkins> alexmog: It seems that the only two values that ever happen are that character are oriented with the baseline, or they are vertical.
# [07:25] <TabAtkins> fantasai: [shows example of English letters being stacked, or rotated with baseline on right or left]
# [07:25] <TabAtkins> 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.
# [07:27] <TabAtkins> fantasai: We could simplify more if we're willing to screw with the bidi algorithm. I was trying to leave bidi alone.
# [07:27] <TabAtkins> jdaggett: I think we should just change "vertical-right" to "auto".
# [07:28] <TabAtkins> szilles: That doesn't match with SVG.
# [07:28] * Joins: myakura (d2e8220d@109.169.29.95)
# [07:28] <TabAtkins> jdaggett: SVG can mess around with that themselves. It's deprecated!
# [07:28] * sylvaing ...I am sensing a consensus around mapping auto to bikeshedding
# [07:29] <TabAtkins> fantasai: it's not deprecated in SVG. We're deprecating their definition with our new one, is all.
# [07:31] <TabAtkins> jdaggett: Everything but vertical-right is exceptions to the general behavior, which we should call "auto".
# [07:31] <TabAtkins> fantasai: So, first issue is you want to rename "vertical-right" to "auto".
# [07:32] <TabAtkins> fantasai: But the reasonable default behavior changes based on the context.
# [07:32] <TabAtkins> You want "vertical-right" or "rotate-normal" based on Chinese vs English, frex.
# [07:32] <dbaron> 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'
# [07:38] <TabAtkins> fantasai: Next jdagget proposal is to drop the SVG-specific values.
# [07:38] <dbaron> 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?
# [07:42] <TabAtkins> [...]
# [07:43] <TabAtkins> Nat: Not all layout engines have the same idea of what is the default behavior.
# [07:44] <TabAtkins> Nat: That freedom should maybe be allowed.
# [07:44] <TabAtkins> 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? I didn't hear well]
# [07:47] * Joins: boblet (Adium@123.223.112.160)
# [07:48] <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
# [07:52] <TabAtkins> [whole lots of discussion I have no idea about]
# [07:52] <TabAtkins> fantasai: I can rename 'upright' to 'stacked'
# [07:55] <TabAtkins> 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.
# [07:55] <TabAtkins> dbaron: But then you tsill need vertical-left/right and an escape hatch, where instead of vertical-right (honoring the block-progression direction), you honor the inline-progression direction.
# [07:57] <TabAtkins> dbaron: This alternative doesn't give you [something], but that's it.
# [07:57] <TabAtkins> ???: 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.
# [07:58] <TabAtkins> ???: But when roman characters exist as well, their top is on the right, but then the arabic characters are on the left side.
# [07:58] <TabAtkins> ???: To resolve this contradiction, publishers will set arabic from bottom-to-top, and keep the roman on top-to-bottom.
# [07:59] <nmccully> ??? = Taro
# [08:01] <TabAtkins> szilles: When I rotate english to the left, it seems I'm in a bottom-to-top mode.
# [08:01] <TabAtkins> fantasai: Yes.
# [08:02] <TabAtkins> szilles: So then, is the 'auto' value for bottom-to-top to rotate everything left? Because there are effectively no bottom-to-top languages.
# [08:02] <TabAtkins> fantasai: Yes, which is why those btt languages will actually go ttb unless you set rotate-left.
# [08:02] <TabAtkins> fantasai: Any other issues that need to be discussed?
# [08:02] <TabAtkins> szilles: Yesterday in the forum, in the shift to upright, numbers went to traditional c/j encoding.
# [08:03] <TabAtkins> fantasai: It's not just a codepoint swap, they actually transformed [???]
# [08:03] <TabAtkins> jdaggett: It's numerical transforms.
# [08:03] <dbaron> 135 -> 百三十五
# [08:04] <dbaron> (not 135 -> 一三五!)
# [08:04] <dbaron> fantasai: escape hatch: <abbr title="百三十五">135</abbr> and abbr { content: attr(title); }
# [08:04] <TabAtkins> fantasai: Escape hatch for now is just hiding the alternate form in an attribute and pulling it in via "content: attr()".
# [08:05] <Bert> (And if I want to translate it to Chinese *and* convert to the Julian calendar? :-) )
# [08:05] <dbaron> Daniel Davis: Could rotate-right/left be baseline-right/left?
# [08:06] <dbaron> fantasai: which baseline?
# [08:10] * Quits: Kazutaka (yamamoto_k@125.207.177.35) (Quit: CHOCOA)
# [08:11] * Joins: boblet1 (Adium@123.223.112.160)
# [08:13] * Quits: boblet (Adium@123.223.112.160) (Ping timeout)
# [08:24] <fantasai> suggestion was sideways-left, sideways-right, and sideways (rotate-normal)
# [08:29] <TabAtkins> dbaron: If we ever add bottom-to-top, vertical-right is not going to be what we want for those.
# [08:33] <TabAtkins> 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.
# [08:33] <TabAtkins> Like, ttb-rtl would let us know that it's rtl in horizontal and ttb in vertical.
# [08:34] <TabAtkins> Straw Poll: The default value for text-orientation
# [08:34] <TabAtkins> Should it be named 'auto' or 'vertical-right'
# [08:35] <TabAtkins> danield: Abstain
# [08:35] <TabAtkins> jdaggett: auto
# [08:35] <TabAtkins> sylvaing: auto
# [08:35] <TabAtkins> dbaron: vertical-right
# [08:35] <TabAtkins> kojiishi: vertical-right
# [08:35] <TabAtkins> florian: vertical-right
# [08:35] <TabAtkins> szilles: auto
# [08:35] <TabAtkins> alexmog: auto
# [08:35] <TabAtkins> vhardy: auto
# [08:35] <TabAtkins> Bert: abstain
# [08:35] <dbaron> (vertical-right because I think there's actually relatively little logic to it, because the normal behavior of Mongolian is weird)
# [08:36] <TabAtkins> Taro: auto
# [08:36] <TabAtkins> Nat: auto
# [08:36] <TabAtkins> TabAtkins: abstain
# [08:36] <TabAtkins> hober: vertical-right
# [08:36] <TabAtkins> plinss: vertical-right
# [08:36] <TabAtkins> murakami: vertical-right
# [08:36] <TabAtkins> fantasai: vertical-right
# [08:36] * Bert thinks about 'normal' or maybe just 'vertical', because 'vertical-right' is a bit long...
# [08:37] <TabAtkins> 7 'auto', 7 'vertical-right', 3 'abstain'
# [08:37] <TabAtkins> plinss: 'auto' implies it will change behavior based on something else.
# [08:37] <TabAtkins> 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.
# [08:38] <TabAtkins> dbaron: And it just so happens that it all works out, because the normal behavior for Mongolian and Chinese turn the same way.
# [08:39] <dbaron> Steve: But Mongolian written horizontally actually runs left-to-right (due to Russian influence).
# [08:39] <TabAtkins> 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.
# [08:39] <dbaron> dbaron: oh
# [08:40] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [08:40] * sylvaing escape-hatch: auto;
# [08:41] * Joins: Ms2ger (Ms2ger@91.181.154.155)
# [08:41] <TabAtkins> szilles: I'll point out that if you have vertical tabs on multiple pages, the ones on opposite pages go in opposite directions.
# [08:42] <TabAtkins> fantasai: The next issue is the SVG property.
# [08:42] <nmccully> good point about English in vertical "auto" is biased toward Japanese default behavior, not some other convention
# [08:42] <TabAtkins> fantasai: SVG basically said that they'll do what we decide on.
# [08:42] <TabAtkins> szilles: Can we just call the value "svg-historic"?
# [08:43] <TabAtkins> jdaggett: Anything except "auto".
# [08:43] <TabAtkins> fantasai: agreed
# [08:43] <TabAtkins> fantasai: I can change it to "svg-historic" or "use-glyph-orientation" or something.
# [08:44] <TabAtkins> plinss: Maybe mark the value as at-risk.
# [08:45] <TabAtkins> RESOLVED: Renamed the 'auto' value for text-orientation, and mark the value as at-risk.
# [08:45] <TabAtkins> jdaggett: I'm confused about how vertical-align works for vertical text.
# [08:45] <TabAtkins> [something about multiple baselines]
# [08:46] <TabAtkins> fantasai: [points to the definition in the "introduction to baselines" chapter]
# [08:47] <TabAtkins> Nat: Incidentally, baselines are wrong for ideographic.
# [08:47] <TabAtkins> jdaggett: This example and text and such shouldn't be in this spec, though. It should be in the Linebox module.
# [08:47] <TabAtkins> 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.
# [08:48] <TabAtkins> fantasai: I need at least two baselines defined.
# [08:48] <TabAtkins> jdaggett: Right. We just don't need quite this much detail. There's also stuff about metrics, which is completely unnecessary.
# [08:48] <TabAtkins> szilles: I can fix the diagram to just provide the necessary info.
# [08:49] <TabAtkins> jdaggett: And then when we talk about metrics, this is completely not what browsers actually do.
# [08:49] <TabAtkins> szilles: We agreed on this text some time ago in the WG. It's in the 2.1 spec.
# [08:49] <TabAtkins> fantasai: Most of it.
# [08:49] <TabAtkins> jdaggett: Darn, then we have a larger issue.
# [08:50] <TabAtkins> szilles: It was put there to provide a reasonable set of fallbacks for dealing with what happens with real-world fonts.
# [08:50] <TabAtkins> jdaggett: And real-world fonts in Windows use the windows metrics.
# [08:50] <TabAtkins> szilles: They have nothing to do with the em box.
# [08:50] <TabAtkins> 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.
# [08:51] <TabAtkins> jdaggett: I'm not objecting that this is wrong behavior, it's just not what impls do.
# [08:54] * Joins: alexmog (qw3birc@128.30.52.28)
# [08:56] <TabAtkins> RESOLVED: Remove 4.2.1 from the Writing Modes spec.
# [08:58] <TabAtkins> fantasai: [explains how the spec deals with alphabetic/central baselines]
# [08:59] <TabAtkins> fantasai: There's sometimes a conflict between the parent and child in what baseline is dominant, but the spec defines that logic.
# [09:00] <TabAtkins> jdaggett: So the behavior for 'sub' and 'super' in vertical is to shift left/right?
# [09:00] <TabAtkins> fantasai: Yes.
# [09:00] <TabAtkins> jdaggett: And what about when tatechuyoko(sp?) is used?
# [09:00] <TabAtkins> fantasai: That's defined to basically synthesize a new glyphs which then has a singular baseline.
# [09:01] * Joins: howcome (howcome@80.203.19.137)
# [09:01] <TabAtkins> szilles: So you're asking about what happens if there is vertical-align'd text in tatechuyoko?
# [09:01] <TabAtkins> fantasai: Right now it's defined to *not* trigger tatechuyoko if there is any further structure.
# [09:03] <nmccully> It should be possible to set text inside the TCY using baselines (horizontal ones) for superscript or subscript
# [09:03] <nmccully> The whole thing would be centered in the vertical line
# [09:03] <TabAtkins> szilles: [some point about horizontal text in horizontal japanese?]
# [09:05] <TabAtkins> jdaggett: "The default alignment is 'baseline', and that uses the dominant baseline, which changes based on the script."
# [09:05] <TabAtkins> s/script/writing mode/
# [09:07] <jdaggett> http://people.mozilla.org/~jdaggett/images/tatechuyoko-percent.png
# [09:10] <TabAtkins> [looking at the email]
# [09:10] <TabAtkins> jdaggett: This was original meant for kumimoji, actually.
# [09:12] * Quits: myakura (d2e8220d@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
# [09:13] <TabAtkins> I also proposed "text-inline-horizontal: none | half | third | quarter".
# [09:13] <TabAtkins> [last was from jdaggett]
# [09:14] <TabAtkins> Taro: When two characters are combined, it's possible the editor wants to condense them to get them into 1em width.
# [09:14] <TabAtkins> Taro: That typically applies to 2-digit numbers without a decimal point.
# [09:14] <TabAtkins> Taro: The case with a decimal point is kind of an exception.
# [09:14] <TabAtkins> Nat: We have half and quarter-width characters, but I think that's mostly a throwback to when they weren't really scalable.
# [09:16] <TabAtkins> [jdaggett shows example from the spec about tatechuyoko]
# [09:16] <TabAtkins> jdaggett: You see the year and day are using tatechuyoko.
# [09:17] <TabAtkins> 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"
# [09:18] <TabAtkins> kojiishi: I think that 'automatic' is nice, but if we were only doing one or the other, we should do the explicit one first.
# [09:19] <TabAtkins> [jdagget shows another example from the email]
# [09:20] <TabAtkins> jdaggett: Here you have an example of where you want to do tatechuyoko on "up to 2" things.
# [09:20] <TabAtkins> The first date, with two digits, would use tatechuyoko.
# [09:20] <TabAtkins> 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.
# [09:22] <TabAtkins> jdaggett: Also, how does this combine with text-transform?
# [09:22] <TabAtkins> fantasai: Maybe text-transform would turn off automatically.
# [09:22] <TabAtkins> fantasai: If the number is too wide, use text-transform, otherwise use tatechuyoko.
# [09:23] <TabAtkins> jdaggett: I also think it should say that under no circumstances should it change the linebox.
# [09:24] <fantasai> ISSUE - define interaction with text-transform: fullwidht
# [09:24] <fantasai> ISSUE - make spec clear that the tcy is only 1em high
# [09:24] <fantasai> even if the glyphs bleed outside that 1em
# [09:24] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [09:25] * Quits: stearns (qw3birc@128.30.52.28) (Quit: Page closed)
# [09:27] <TabAtkins> 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.
# [09:27] <TabAtkins> jdaggett: In the single-digit case you may want to use wider characters, sometimes.
# [09:27] <fantasai> e.g. text-combine-auto: digits 3;
# [09:28] <TabAtkins> fantasai: We should be able to solve that by setting text-transform:fullwidth and turning it off when tcy applies.
# [09:29] <TabAtkins> fantasai: We do want a way to force tcy sometimes, too.
# [09:29] <TabAtkins> fantasai: If we want to deal with automatic stuff here, we can.
# [09:30] <TabAtkins> 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.
# [09:30] <TabAtkins> Nat: As long as you keep the edge cases in mind while designing the automatic thing, it'll work.
# [09:32] <TabAtkins> Nat: [discussion about processing, using "anything that fits into X" versus "all 2/3 digit numbers"]
# [09:32] <TabAtkins> Nat: [prefers the latter, as it doesn't require you to call down into the font renderer before deciding whether to use tcy]
# [09:33] <TabAtkins> jdaggett: I mainly just wanted dates to work, so you only needed one span to wrap a date with.
# [09:34] <TabAtkins> szilles: Automatic is good, but also I want to use tcy on arbitrary characters, so we want manual forcing as well.
# [09:34] <TabAtkins> Nat: jdaggett's proposal doesn't get "2010" to be quarter-width and "4" being full-width, though.
# [09:34] <TabAtkins> jdaggett: You can do manual overrides.
# [09:40] <TabAtkins> Nat: We find that anytime we do automatic, we get people angry because they're doing something weird.
# [09:41] <TabAtkins> szilles: That should be okay as long as there's an ability to override manually.
# [09:41] * Quits: dbaron (dbaron@125.207.177.35) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [09:41] <TabAtkins> 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.
# [09:42] <TabAtkins> Nat: If we can come up with a property for that and use it in tcy as well, that would be nice.
# [09:42] <TabAtkins> fantasai: What about "text-combine-horizontal: all | digits <number>? || alpha <number>?".
# [09:42] * Joins: dbaron (dbaron@125.207.177.35)
# [09:42] <TabAtkins> "all" is entire contents, no smushing.
# [09:48] <TabAtkins> fantasai: "... && [half | third | quarter]"
# [09:49] <TabAtkins> 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.
# [09:50] <TabAtkins> fantasai: or "... && fit"
# [09:50] <TabAtkins> fantasai: So you can specify "all", which just puts it all in tcy without smushing.
# [09:51] <TabAtkins> fantasai: Or "alpha <digit>" or "digits <integer>
# [09:51] <TabAtkins> s/<digit>/<integer>/
# [09:51] * Bert thinks: If this allows you to scale arbitrarily many glyphs to an arbitrary length, I can see designers use this to fit a headline to exactly fill the width; just needs a 'writing-mode', 'line-height' and 'text-combine' on it...
# [09:52] <TabAtkins> fantasai: Which swaps alphas/digits for the appropriate-width characters and does tcy.
# [09:54] <Bert> (1,000 is different from 1, 000)
# [09:54] <TabAtkins> "all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ]"
# [09:57] <TabAtkins> "none | all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ] && [ fit | scale ]"
# [09:58] <TabAtkins> "fit" means try to use the half/third/quarter-width glyphs first, otherwise fall back to scaling.
# [09:58] <TabAtkins> "none | all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ] && [ use-glyphs | scale ]"
# [10:02] <TabAtkins> 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.
# [10:04] <TabAtkins> plinss: We have enough progress here now. Take the rest for later.
# [10:04] <TabAtkins> jdaggett: Next issue is that we don't have any talk about form elements.
# [10:04] <TabAtkins> 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.
# [10:05] <TabAtkins> 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.
# [10:05] <TabAtkins> jdaggett: I just want to say "form controls follow the text direction", etc.
# [10:05] <TabAtkins> fantasai: It says that right now.
# [10:07] <fantasai> ISSUE - put in some examples, maybe using IE9 screenshots
# [10:07] <fantasai> :)
# [10:07] <Ms2ger> Hah
# [10:07] <TabAtkins> jdaggett: Next issue. Minor point, but I don't like that "writing-mode" is labelled the block direction.
# [10:08] <TabAtkins> jdaggett: It's influencing the direction in which text flows.
# [10:08] <TabAtkins> Bert: "block flow direction" is a technical term that means quite a lot.
# [10:09] * Joins: szilles (chatzilla@125.207.177.35)
# [10:09] <TabAtkins> Bert: It implies a bunch of typographic rules, including what's upright and what's rotated.
# [10:09] <TabAtkins> 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 verticla.
# [10:11] <TabAtkins> szilles: The title of the section could just be simplified to "The 'writing-mode' Property", to avoid the confusion.
# [10:12] * Ms2ger "Property" or "property"?
# [10:12] <TabAtkins> fantasai: The "writing mode" means 3 things (3 properties). The 'writing-mode' property is one aspect.
# [10:13] <TabAtkins> fantasai: If it was up to me I'd call it 'block-flow-direction', but I think it's too late now.
# [10:13] <TabAtkins> sylvaing: Why is it too late?
# [10:14] <TabAtkins> fantasai: maybe I can change it
# [10:14] <TabAtkins> fantasai: Last issue is text-orientation and punctuation.
# [10:16] <TabAtkins> jdaggett: I was suggesting as a loose default that you should specify all the scripts that are upright, and everything else is rotated.
# [10:16] <TabAtkins> jdaggett: For the common/inherited characters, use whatever the previous script block was.
# [10:16] <TabAtkins> Nat: The problem we ran into is that for the ambiguous chars (U+2000), depending on the font the glyph design was different.
# [10:17] <TabAtkins> Nat: Our method was that if it was in Shift-JIS and fullwidth, it was upright. Otherwise, rotated.
# [10:18] <TabAtkins> Nat: [some things are crazy]
# [10:18] <TabAtkins> jdaggett: Short version - "we're screwed".
# [10:18] <TabAtkins> 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.
# [10:21] <TabAtkins> 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.
# [10:23] <TabAtkins> [chatter about fonts and such]
# [10:27] <fantasai> ISSUE - add reference to Unicode database
# [10:28] <fantasai> dbaron: Refer to a particular version of Unicode
# [10:29] * Joins: r12a (rishida@128.30.52.169)
# [10:38] <fantasai> [unminuted discussion of font features]
# [10:38] <fantasai> e.g. vrt2
# [10:39] <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 htat the engines are unfamiliar with , we don't have access to the glyph ids
# [10:39] <fantasai> Nat: I'm not sure why that's common to the ones I know, but seems to me that it's difficult ...
# [10:40] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [10:40] <fantasai> 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
# [10:40] <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.
# [10:40] <Bert> -> http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2 Description of the vrt2 feature in OT
# [10:40] <fantasai> jdaggett: I think we have to do an implementation and see if using vrt2 actually work
# [10:42] <fantasai> jdaggett: puzzled why Unicode didn't deal with this stuff
# [10:42] <fantasai> fantasai: partly 'cuz they consider vertical layout out-of-scope
# [10:42] <fantasai> fantasai: and partly because the correct orientation depends on the font and how that glyph was designed
# [10:43] <fantasai> Nat: Unicode unified various characters, so ... it's a difficult problem.
# [10:44] <fantasai> 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.
# [10:45] <fantasai> topic: unicode-bidi
# [10:45] <fantasai> dbaron: So you've revised the values of unicode-bidi
# [10:45] <fantasai> dbaron: I looked it over, and I think it makes sense.
# [10:45] <fantasai> dbaron: I think the revision now allows the combinations that make sense and not some other combinations
# [10:45] <fantasai> dbaron: But I guess..
# [10:46] <fantasai> 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
# [10:47] <fantasai> fantasai: oh, hm, I'm not sure why I did that
# [10:49] <dbaron> 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
# [10:49] <dbaron> fantasai: so allowing combination of plaintext and isolate does not make sense
# [10:49] <fantasai> ACTION: fantasai edit the spec per above and check with smontagu
# [10:49] * trackbot noticed an ACTION. Trying to create it.
# [10:49] * RRSAgent records action 1
# [10:49] <trackbot> Created ACTION-321 - Edit the spec per above and check with smontagu [on Elika Etemad - due 2011-06-09].
# [10:50] <fantasai> dbaron: Other interesting ocnstraint 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
# [10:51] <fantasai> fantasai: so the remaining issue is the box model for bidi when you break the box across lines
# [10:51] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011May/0186.html
# [10:51] <dbaron> s/ocnstraint/constraint/
# [10:52] * Joins: szilles (chatzilla@125.207.177.35)
# [10:52] * Joins: vhardy (vhardy@125.207.177.35)
# [10:53] * alexmog slaps vhardy around a bit with a large fishbot
# [10:54] <alexmog> reposting for Vincent: http://lists.w3.org/Archives/Public/www-style/2011May/0186.html
# [10:56] <fantasai> dbaron: ... yes, I think that makes sense
# [10:56] <fantasai> fantasai: So should we fix this?
# [10:56] <fantasai> dbaron: So Gecko does what the spec says in this case and it looks stupid
# [10:57] <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
# [10:57] <fantasai> fantasai: I think someone said IE9 does what we're proposing
# [10:57] <fantasai> plinss: bidi was so broken in CSS2.1 that I don't think there's a backwards-compat issue
# [10:58] <fantasai> sylvain loads the testcase
# [10:58] <fantasai> dbaron: That's what fantasai said it should do
# [10:58] <fantasai> bunch of ppl gather around dbaron and sylvain's laptops
# [10:59] <dbaron> so Elika's proposal sounds good to me
# [11:01] <fantasai> RESOLVED: Fix this in CSS2.1 and CSS3 Writing Modes
# [11:01] * Quits: jdaggett (jdaggett@125.207.177.35) (Quit: jdaggett)
# [11:01] * Quits: hober (ted@125.207.177.35) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [11:04] <fantasai> Meeting closed.
# [11:05] * Quits: kojiishi (kojiishi@125.207.177.35) (Quit: Leaving...)
# [11:05] * Quits: vhardy (vhardy@125.207.177.35) (Quit: vhardy)
# [11:06] * Quits: nmccully (nmccully@125.207.177.35) (Quit: nmccully)
# [11:06] * Quits: dbaron (dbaron@125.207.177.35) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [11:06] * Parts: danield (danield@125.207.177.35)
# [11:08] * Quits: florian (florianr@125.207.177.35) (Ping timeout)
# [11:10] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [11:11] * Quits: sylvaing (sylvaing@125.207.177.35) (Ping timeout)
# [11:11] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [11:17] * Quits: plinss (plinss@125.207.177.35) (Quit: plinss)
# [11:18] <fantasai> RRSAgent: pointer
# [11:18] <RRSAgent> See http://www.w3.org/2011/06/02-css-irc#T09-15-14
# [11:18] <fantasai> RRSAgent: make logs public
# [11:18] <RRSAgent> I have made the request, fantasai
# [11:25] * Quits: TabAtkins (tabatkins@125.207.177.35) (Ping timeout)
# [11:26] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
# [11:26] * Joins: TabAtkins (tabatkins@125.207.177.35)
# [11:28] * Quits: macpherson (qw3birc@128.30.52.28) (Ping timeout)
# [11:29] * Quits: TabAtkins (tabatkins@125.207.177.35) (Ping timeout)
# [11:35] * Quits: boblet1 (Adium@123.223.112.160) (Quit: Leaving.)
# [11:48] * Joins: szilles (chatzilla@219.127.245.113)
# [11:51] * Joins: sylvaing (sylvaing@219.127.109.2)
# [11:55] * Quits: sylvaing (sylvaing@219.127.109.2) (Ping timeout)
# [12:01] * Joins: jdaggett (jdaggett@222.151.136.131)
# [12:14] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [12:17] * Joins: boblet (Adium@122.27.197.150)
# [12:40] * Quits: howcome (howcome@80.203.19.137) (Ping timeout)
# [13:00] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
# [13:24] * Joins: szilles (chatzilla@219.127.245.113)
# [13:28] * Quits: jdaggett (jdaggett@222.151.136.131) (Quit: jdaggett)
# [13:28] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [13:50] * Joins: myakura (myakura@118.111.219.27)
# [13:51] * Joins: Martijnc (Martijnc@84.192.44.100)
# [13:57] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [14:30] * Joins: sylvaing (sylvaing@219.127.109.11)
# [14:37] * Joins: szilles (chatzilla@219.127.245.113)
# [14:45] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [14:53] * Joins: Ms2ger` (Ms2ger@91.181.49.137)
# [14:54] * Quits: Ms2ger (Ms2ger@91.181.154.155) (Ping timeout)
# [14:58] * Ms2ger` is now known as Ms2ger
# [15:07] * Joins: jdaggett (jdaggett@222.151.136.131)
# [15:08] * Quits: jdaggett (jdaggett@222.151.136.131) (Quit: jdaggett)
# [15:16] * Quits: sylvaing (sylvaing@219.127.109.11) (Ping timeout)
# [15:22] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [15:23] * Joins: karl (karlcow@128.30.54.58)
# [15:27] * Joins: szilles (chatzilla@219.127.245.113)
# [15:36] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [16:03] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [16:07] * Joins: plinss (plinss@61.214.117.102)
# [16:08] * Joins: alexmog (qw3birc@128.30.52.28)
# [16:14] * Joins: arron (Arron@24.17.123.244)
# [16:18] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [16:27] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [16:27] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
# [16:45] * Joins: szilles (chatzilla@219.127.245.113)
# [16:48] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [17:01] * Quits: boblet (Adium@122.27.197.150) (Quit: Leaving.)
# [17:10] * Joins: arno (arno@192.150.10.200)
# [17:10] * Joins: boblet (Adium@122.27.197.150)
# [17:13] * Quits: arronei (arron.eich@131.107.0.115) (Ping timeout)
# [17:14] * Joins: arronei (arron.eich@131.107.0.115)
# [17:15] * Quits: boblet (Adium@122.27.197.150) (Quit: Leaving.)
# [17:17] * Quits: arronei (arron.eich@131.107.0.115) (Connection reset by peer)
# [17:19] * Joins: arronei (arron.eich@131.107.0.115)
# [17:28] * Quits: arronei (arron.eich@131.107.0.115) (Connection reset by peer)
# [17:31] * Joins: arronei (arron.eich@131.107.0.115)
# [17:54] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [17:54] * Joins: lhnz (lhnz@188.223.83.48)
# [17:57] * Joins: szilles (chatzilla@219.127.245.113)
# [18:00] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:01] * Joins: lhnz (lhnz@188.223.83.48)
# [18:03] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [18:17] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:17] * Joins: lhnz (lhnz@188.223.83.48)
# [18:19] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [18:20] * Joins: arno (arno@192.150.10.200)
# [18:20] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:21] * Joins: lhnz (lhnz@188.223.83.48)
# [18:31] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
# [18:32] * Joins: lhnz (lhnz@188.223.83.48)
# [19:12] * Joins: szilles (chatzilla@219.127.245.113)
# [19:15] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [19:23] * Quits: myakura (myakura@118.111.219.27) (Client exited)
# [19:47] * Joins: konaya (konaya@83.251.16.72)
# [20:01] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [20:03] * Joins: arno (arno@192.150.10.200)
# [20:03] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [20:25] * Joins: szilles (chatzilla@219.127.245.113)
# [20:33] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [20:54] * Joins: mg (mg@83.227.44.127)
# [21:05] * Joins: arno (arno@192.150.10.201)
# [21:18] * Parts: mg (mg@83.227.44.127)
# [21:36] * Quits: Ms2ger (Ms2ger@91.181.49.137) (Quit: nn)
# [21:43] * Joins: szilles (chatzilla@219.127.245.113)
# [21:46] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [22:41] * Quits: arno (arno@192.150.10.201) (Ping timeout)
# [22:49] * Joins: arno (arno@192.150.10.200)
# [22:50] * Quits: Martijnc (Martijnc@84.192.44.100) (Quit: Martijnc)
# [22:55] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [22:55] * Joins: szilles (chatzilla@219.127.245.113)
# [23:01] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [23:02] * Joins: arno (arno@192.150.10.201)
# [23:02] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [23:03] * Joins: arno (arno@192.150.10.201)
# [23:05] * Joins: Sidnicious (sidney@184.75.21.194)
# [23:06] <Sidnicious> Hey. I'm trying to figure out how to express something with the flexible box model. Here's an example that works in WebKit/Gecko: http://jsbin.com/upino6/
# [23:07] <Sidnicious> Essentially, I'd like the lower element to take up the extra space when there is extra space, but I'd like the upper element to gain a scrollbar and stay on screen when there isn't enough space, so that the body does not have a scrollbar.
# [23:07] <Sidnicious> Would that be possible?
# [23:25] * Joins: sylvaing (sylvaing@219.127.109.10)
# [23:39] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [23:45] * Joins: arno (arno@192.150.10.201)
# [23:48] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# Session Close: Fri Jun 03 00:00:00 2011

The end :)