[CSSWG] Minutes and Resolutions Kyoto F2F Thurs: Vertical Text, Bidi, Line Grid, Unencoded Characters

Many thanks to Florian for helping to create the summary.

Kyoto Forum Issues

   - Reviewed feedback from Kyoto Forum on CSS. Line stacking was a major issue.

   - Discussed how to represent unencoded characters; concluded that this
     is a content/semantics issue, and probably needs markup to be solved.

Line Grid

   - Discussed line stacking and the line grid. A new proposal was drawn
     up to address the issues and use cases, including for complex layouts
     (floats, positioning, multicol).

   - RESOLVED: Merge line grid proposal into css3-linebox. (No separate line
               grid spec.)

Writing Modes

   - Long discussion of 'text-orientation' cases. Concluded that all the values
     are indeed justified by actual use cases. A motion to change 'vertical-right'
     to 'auto' failed to gain a majority. Suggested to rename rotate-* to sideways-*.

   - RESOLVED: Rename the SVG-compatibility value for text-orientation
               from 'auto' to something more specific, and mark the value

   - Reviewed how baselines work in vertical text. Nat noted that the ideographic
     baseline in the images copied from css3-linebox was wrong.

   - RESOLVED: Remove OpenType baselines section from the Writing Modes spec.

   - Redesigned existing 'text-combine' property to work better with markup,
     and to add some controls for whether/how to scale to fit.

   - Reviewed interaction of 'text-orientation' and punctuation. Inconclusive,
     other than "this is hard".

   - Rearranged some of the new values of 'unicode-bidi' to create a simpler
     and more consistent model for 'plaintext'.

   - RESOLVED: The sides of a box that are drawn when it is broken across
               lines is determined by the 'direction' of the parent, not
               the inline itself. Fix this in CSS2.1 and CSS3 Writing Modes.

====== Full minutes below ======

   David Baron (Mozilla)
   Bert Bos (W3C)
   John Daggett (Mozilla)
   Daniel Davis (Opera)
   Elika Etemad (Invited Expert)
   Sylvain Galineau (Microsoft)
   Vincent Hardy (Adobe)
   Koji Ishii (invited Expert)
   Peter Linss (HP)
   Nat McCully (Adobe)
   Luke Macpherson (Google)
   Alex Mogilevsky (Microsoft)
   Shinyu Murakami (Antenna House)
   Ted O'Connor (Apple)
   Florian Rivoal (Opera)
   Shunchi Seko (NTT)
   Shane Stevens (Google)
   Kazutaka Yamamoto (NTT)
   Taro Yamamoto (Adobe)
   Steve Zilles (Adobe)

<RRSAgent> logging to http://www.w3.org/2011/06/02-css-irc
Meeting: CSS Working Group Face-to-Face Meeting, Kyoto, Japan

Scribe: dbaron


   <plinss> http://wiki.csswg.org/planning/japan-2011
   Steve: Want Writing Modes, Text, and Line Grid for today, while Nat is here.
   Nat: Here today, and tomorrow until noon.
   Florian: Would like CSS Device Adaptation for tomorrow afternoon so
            Europe can call in
   Ted: Simon wants to call in for animations and transitions, so morning
        better for that
   various: charter
   jdaggett: Would like to do css3-fonts on Saturday morning.
   jdaggett: Would also like to discuss feature support (dbaron's post to list)
   jdaggett: ... relates to one of font subjects and to vertical text.
   Sylvain: Talk about dropping prefixes?
   Sylvain: If you have to submit test cases before dropping prefixes,
            and you have vendor prefixes in your test cases...
   Steve: Taro can't be here after Friday for fonts.
   jdaggett:  I wanted to talk about sub/superscript and same origin;
              probably less interesting for Taro.
   jdaggett: If we wanted to talk about IVS, we could do that tomorrow.
   jdaggett: fantasai put in an item about unifying variant glyphs; we can
             talk about it in the context of that.
   Peter: Talk about feedback from forums earlier in the meeting?
          (This morning?)
   Steve: Regions and Exclusions not Saturday afternoon (I have to leave)
   Peter: I'll get the schedule on the wiki.

Feedback from the Kyoto Forum

   <transcript of forum will be posted later>

   Steve: Things that struck me most from the forum: there's a requirement
          for simple formatting in vertical mode, and there's also a
          requirement for quality formatting in vertical mode.  To me
          that suggests an 80/20 solution where the default does 80% of
          the cases but we need a mechanism to specify the other 20% of
          the cases that require more careful control of the formatting.
   Steve: Another observation: there was a big discussion of signage and
          large things, and it seemed to me that was really related to
          the issue of the size on the canvas vs. the size the thing was
          actually displayed at.
   Steve: This goes back to the discussion of how pixels relate to
          concrete units.
   Steve: I don't think the people doing the signs were aware they don't
          have to make the fonts that size; they can make the fonts the
          size of a sheet of paper and the medium they project onto
          that size.  So that's probably a red herring.
   Alex: Nothing wrong with specifying font size in inches/centimeters.
   Nat: Some authoring software has limits on font size, or may not be
        able to handle a canvas that big.
   ?: Not a standards issue.
   Nat: If we're interested, maybe Koji-san could get more feedback on
        details of what the problems were with signage.

   Koji: Two or three publishers repeatedly said that they tried to use
         ruby but that ruby implementations changed line spacing so they
         gave up.
   Ted: That seems like low-hanging fruit.
   Nat: A number of issues about line-height calculation we can discuss
        (and then segue into grid).

Representing Unencoded Characters

   Koji: Other big discussion was private characters (Gaiji).  Related
         to IVS discussion; use cases for private characters were shown.
   Koji: Important for people's names and place names.
   Koji: The space of ideographs is open-ended.
   Taro: Archaeologists may need to publish paper about ancient Chinese
         history that needs old Chinese characters that are not widely
         used in everyday Japanese.
   Ted: Seems like two cases:  (1) you're the archaeologist who's
        discovered this character, but (2) probably more common use
        case is things like personal names... political party (4 glyphs).
   jdaggett: You can do kumimoji (4 glyphs) today as discretionary
             ligature, which is a much better solution than trying to
             define variants or new codepoints, since it's a stylization.
   Koji: Kumimoji can be discretionary ligatures, but still needs creation
         of fonts.
   jdaggett: Styling text in an old-style way (which he suggested was a
             use case for private characters) is a bad use case for codepoints.
   jdaggett: ... could be standardized as an OpenType feature.
   jdaggett: There are a lot of correlary cases in Western text, and there
             are OpenType features to support that kind of thing.
   jdaggett: We need to avoid letting stylization creep in to codepoints.
   Nat: Can you get to arbitrary OpenType features from CSS?
   jdaggett:  With css3-fonts (and in Firefox 4), yes.
   (description of how it works)
   Taro: I think main usage of Gaiji (extraneous characters): variants of
         unencoded (?) characters, or special symbol on keyboard in
         computer manual.
   Taro: I wonder if there's an easy method for user to access a glyph in
         a font if such a character is unencoded.
   jdaggett: CSS only goes down to the codepoint level; beyond that it's
             up to the font.
   jdaggett: No way to directly get a CID.
   Nat: That's a problem for Japanese fonts -- the assumption that
        everything is encoded is not true.
   jdaggett:  What are those glyphs for?
   Nat: Kanji that are not encoded in Unicode and not variants of a base
   jdaggett: Sounds like a case for PUA.
   Nat: PUA is a bad thing; in PDF we use the CID and the font. That's not
        the best way to do it in the general way.
   jdaggett: What's the fallback?
   Nat: At the point that you're dealing with a glyph that isn't encoded,
        you've really lost a lot of information.  You're just talking
        about a glyph, it doesn't have meaning and isn't searchable.
   Nat: When you insert those glyphs with the glyph panel in InDesign --
        we insert either U+FFFD or ... -- one of them we assume is a
        Japanese character by its mojikumi class and one we assume is
        a Roman character by its mojikumi class.
   Nat: I realize adding markup saying font=... cid=... is not a good thing
        to do.
   Nat: But there is a definite need in Japanese fonts to access unencoded
   Florian: ...
   dbaron: It feels like we're trying to add something to CSS to work
           around Unicode's failure to add something to Unicode
   dbaron: I think if there's a real need for this, people should go to
           Unicode and get the characters they need added to Unicode added
           to Unicode
   Nat: ...
   fantasai: What about ideographic description (codepoints in Unicode
             that allow description of a character as composition of others).
   fantasai: For most characters that should get you something that's unique
             and that the font could make a ligature out of.
   fantasai: Doesn't deal with ..., but as an escape hatch seems much better
             than using the replacement character.
   Taro: Variants ... included in Adobe-Japan1 6 (?) ... possible to make a
         mapping table that says that ??? maps to this combination of IVS.
   Taro: IDS (?) cannot uniquely reproduce intended glyph shape.
   Taro: Without Adobe-Japan1 6 and ...
   fantasai: I'm not saying we should use IDS to compose glyphs; I'm saying
             you can use IDS to describe the glyphs you're trying to access.
   Nat: A little better than just a replacement character, but still can't
        go from that to a glyph.
   fantasai: Each unencoded character likely to have unique IDS.
   Nat: A lot of unencoded characters are very minor variants; many not
        encoded at all prior to Adobe-Japan1 4.
   jdaggett: We're talking about CIDs here.  I don't think most people in
             room aware of what CID is.  Not a generalized solution.
   Nat: A CID is a glyph ID that is unique to a certain font technology
        called a CID-keyed font.  There's a mapping of character to glyph ID.
        Because the CID numbering is standardized across fonts Adobe-Japan1.6,
        1.5, 1.4 examples of collection... so you can get character that's
        semantically the same even across fonts.
   Nat: For TrueType fonts you just have glyph IDs which are in any order.
   Florian: The problem on the encoding point is that Unicode doesn't encode
            fast enough -- can't we just have the same problem with CIDs?
   Nat: Adobe controls CIDs...
   jdaggett: If you're using InDesign, you know the content and the font.
             You can't guarantee that on the Web across devices.  There's
             no possible fallback mechanism here.
   jdaggett: The term Gaiji is problematic -- you're not sure what people
             are talking about it when they use it.
   Nat: My first thought is that we need a way to access a glyph within a
        font that's not dependent on Unicode. The only way I can think to
        do that is saying that all bets are off, and you're depending on
        the font... specify exact font/version/even checksum.  Even though
        it's heavy-handed, it seems necessary.
   Nat: We should consider this and acknowledge that there's this need.
   jdaggett: You're going to a very low level.
   jdaggett: Everything we've done in CSS is predicated on dealing with a
             Unicode stream.
   Steve: This isn't an East Asian font problem -- my computer has a key
          with a flag on it that I suspect is not encoded in Unicode.
   various: might be
   jdaggett: Unicode folks have encoded emoticons, which are graphics.
             Apple has magical tables in fonts with 10.7.
   jdaggett: Problem is that the basic model of CSS text (and the same is
             true for SVG fonts) is that text you're not specifying paint --
             you're specifying a mask that's used to paint, and that outline
             is filled with the 'color'.  Not clear what happens how
             emoticons mix with the 'color' property.  Other things like
             this come into play, but I'm not sure how to address at CSS
             level... at least until Apple has standardized these tables.
   Nat: Something to be added to WOFF?
   jdaggett: I think we can't define anything until somebody else has said
             what the basis is.
   jdaggett: I'm uncomfortable pushing CSS into areas... we shouldn't be
             defining font formats.  WOFF is not really a font format;
             it's a font packaging format with OpenType.
   Nat: My understanding is... whether or not it should go into CSS should
        be based on whether the need is big enough for a convenient way
        to mark up the content?
   jdaggett: I'd look at it more as whether there's a stable technology in
             common use that we can expose to authors.
   jdaggett: I'm wary of inventing feature proposals.  We can sort of push
             back on the OpenType guys... for example, I've been saying the
             OpenType spec needs to be more flushed out about features not
             having set of defaults, which features are mutually exclusive,
             which win over which others.  We're gauging based on common
             practice for the spec.
   Nat: Counter to my proposal would be to say that you do have to have
        every glyph encoded.
   jdaggett:  I wouldn't necessarily say that.  We've had proposals to
              support horizontal scaling.  I think it's a good proposal,
              but I think we need to take things in steps, and I think
              that should go in a future version of the spec rather than
              what we're writing right now.  I see the problem and that
              it would be good to have a solution, but I don't see a
              clear path.
   Nat: Maybe we could come up with a markup solution that's better than
        glyph IDs.
   jdaggett:  I think markup would be best for this. (?)
   Florian: I'm not sure markup in the best place to do ...
   <florian> I meant: markup is good to specify that you want a particular
             unencoded character. You still need some way to specify what
             that character is supposed to look like, and that's probably
             not in markup.
   jdaggett:  You're not styling content; you're specifying the content --
              should be in markup.
   (missed a little)
   Steve: To represent something that isn't encoded, shouldn't use an encoding.
   Nat: To some people this will be content, and to some it will be style.
   Peter: There are other gray areas between content and presentation.
   Peter:  e.g., the 'content' property
   <Bert> -> http://www.unicode.org/versions/Unicode6.0.0/ch12.pdf
             Section 12.2 of Unicode describing I(deographic) D(escription) S(equences),
             a way to describe how an ideographs looks in 12 steps, in
             particular for ideographs that aren't in Unicode
   <Bert> -> http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#AlternateGlyphs
             SVG's altGlyph element [that should maybe be in HTML as well?]
   Peter: actionable next steps?
   jdaggett: Nat, if you want to come up with a proposal, I can work with
             you on figuring out the right set of things.
   Florian: I used to work on a non-HTML system... markup with image.
            CSS lets you say "use an image" or "use a video", but you
            can't say "use this glyph".
   Peter: ...
   jdaggett: Not sure content property is right
   Steve: altGlyph was doing that in SVG.
   jdaggett: It feels weird that authors would be authoring documents where
             they were putting in spans that they then go and specify the
             meaning of that span in CSS.
   Ted: really want the markup to carry the meaning fully, and be able to
        select for that meaning in the CSS.
   jdaggett:  Then you can write rules in the CSS to say how the fallback works.
   Nat: Fallback can either be (a) give me what's semantically equivalent or
        (b) no, I really need this glyph shape.
   jdaggett: I think we don't want to map ... into a fallback process.
   Nat: Thinking of ... gives real Gaiji and on phone gives semantically
        equivalent base character.
   jdaggett:  Did we complete everything you wanted to say about Gaiji?
   Koji: yes

More Agenda

   Peter: Other topics we want to dive into?
   Ted: Some things I thought was more an evangelism issue than feature
        needed in CSS.
   Ted: e.g., mixed writing modes
   jdaggett:  Well, this is a feature still in development.
   Peter: Could be they tried and found they can't rely on it.
   Koji: Another issue: CSS can't center within the block progression direction.
   fantasai: Tab is working on it.
   fantasai: ... in flexbox module
   fantasai: Would turn box into a BFC root and the contents would be centered.
   Nat: distribute lines evenly?
   fantasai: Don't have that yet, could work on.
   fantasai: But we do need to finish things and then work on the next thing.

More Unencoded Characters

   jdaggett: I was surprised at a number of ... repeated instances of
             misinformation.  e.g., this notion that I've seen both in
             tweets from Tokyo meeting and yesterday during presentation,
             that SVG fonts are necessary for Gaiji.  I don't understand
             where these memes start, and I think it's unfortunate.
   Florian: Easy bad way to do Gaiji is image, or vector graphic...
   jdaggett: ... imagining features.  No inherent advantage of SVG font
             over OpenType font, other than maybe being able to edit live.
   Peter, Florian: People have tools to make SVG fonts.
   jdaggett: That's a tools problem... and there are tools (fontforge) that
             can convert.
   Florian: Why get it in to a font if you've drawn it in SVG?
   jdaggett: It's a simplified view of how fonts work.  SVG fonts draw as
             a graphic rather than as text; SVG fonts draw as a graphic,
             not as text.  Don't have any subpixel AA, etc.
   Florian: I don't think it's the right solution; there's no current
            right solution.
   jdaggett:  I think people with certain workflows are making exaggerated
              statements... is a valid workflow but shouldn't be a required
   Steve: Seems like the same problem that occurs everywhere on the Web --
          if people find a way to do something, they'll use it.
   Peter: It's been a characteristic of the Web (and a feature) since the
   Taro: Question about SVG Fonts:  I hear from SVG advocates in Japan that
         SVG fonts that it's possible to use ligature mechanism to access a
         glyph in an SVG font.  So in typical Western case ("fi"), you
         specify component characters f and i and it results in the ligature
         for fi.  They want to use that mechanism to access Gaiji characters
         by specifying component characters that have nothing to with the
         Gaiji character.
   Taro: But this destroys the character model and is incompatible with
         standard glyph substitution. I wish W3C would guide them away from that.
   Florian: But it shows that people want a way to say "give me that glyph
            in that font".
   jdaggett: But it sort of ignores the complexity. If you're displaying in
             Turkish you have to be very careful.  OpenType handles this.
             While you could add this to SVG, it's duplicating features that
             work in OpenType.
   Koji: I think ??? was saying to fall back to a description of the character
         (if it cannot be displayed)
   fantasai thought that's what ideographic description sequences were for.
   Taro: I don't think Kobayashi's intention was wrong.  We don't have a
         method to directly specify glyph in font, which is needed by publishers.
   Taro: I'm not familiar with SVG ligature mechanism and CSS font ligature
         mechanism.... that kind of usage is wrong.  But understanding
         necessity of directly accessing glyph.
   Koji shows example with character that can't be displayed and fallback to
        a textual description of the character
   Steve: That's what markup jdaggett was suggesting would do.
   fantasai: Isn't that what Ideographic Description Sequences are supposed
             to do?  Why reinvent that?
   Florian:  Could add markup to fallback to description of character.
   jdaggett:  I don't know if IDS works... not supported in any browser.
   fantasai:  Information is there in IDS -- says "these two characters
              combine side by side", etc., which could be used to speak it out.
   Florian:  You want fallback that goes from these sequences to a Japanese
             description?  Unicode IDS is intended for machine consumption;
             this fallback is intended for human consumption.
   Nat: I don't think it's necessarily easy to translate from machine
        description to human description.  This textual description says to
        take mori (three trees, 森) and replace tree with water.  Which tree?
   Nat: I'm still unclear how far IDC gets you -- I'd need to see it in
        practice to see if it's good enough.
   fantasai: The sequence can let you look up a CID, not let you try to
             synthesize the glyph.
   (fantasai draws on whiteboard)
   <kojiishi> http://www.shuiren.org/chuden/toyoshi/syoseki/chise_ids.html
   Nat: Still doesn't say you want tiny tree on top rather than fat tree on top.
   Florian: But that can be glyph variants.
   Taro: I think IDS may be useful for rapid comparison of IDS sequence to see
         if there are any matching characters... maybe find more than one
         character or maybe just one.
   Taro: Granularity of glyph selection is very fine, finer than expected
         for IDS.
   Taro: ...., and when it fails parenthesized text could be presented to user.
   Florian: Problem with using Unicode feature -- almost specifies the glyph
            but not quite, and likewise for markup seems almost good enough
            but not quite.
   Steve: What I think I've heard so far is that markup for things that aren't
          encoded is the preferred solution, and attaching to that markup
          ways of accessing stuff in a font or an image to provide display
          seems to be the preferred solution.  In principle you could attach
          one of these sequences as well, because once you have the markup
          you can attach almost anything to it.  So that seemed to be a
          generic solution.
   Steve: I'd suggest we end this topic with that.
   Peter: 10-15 minute break.
   <jdaggett> http://people.mozilla.org/~jdaggett/tests/cleartype-waterfall.html

Line Grid

   Peter: Any other feedback from forums?
   Bert: You mentioned aligning the glyphs on a line to a grid.  We used to
         have a proposal for that in a module; don't have it anymore.
   Bert: still needed?
   Peter: next topic on the agenda

   Nat: Feedback I heard in Tokyo and Kyoto had to do with the current
        unpredictability of the traditional Japanese typographi is embox
        based.  Typography on the Web is not embox based.  That difference
        perturbs a lot of people.  People assume, when designing a Web
        page, that they can place text using embox placement, because
        that's how they design in other contexts.
   Nat: Because of standards limitations, text is placed in a Western
        font metrics based way, based on Roman baseline.  Attempts in
        newer standards to accomodate different baselines still doesn't
        get you all the way there.  It allows you to align text with each
        other, and within the line, but the placement of text within the
        line -- my current understanding is that it's not possible to do
        embox based placement.
   Nat: More related to the ??? parts of what you're drawing than the
        conventios of Japanese text measurement.
   jdaggett: You said yesterday that when you talk about embox placement,
             you are primarily talking about the stacking of lines, and
             not so much about the intercharacter spacing.
   Nat:  Either the baseline shift or the stacking of lines.
   jdaggett: So not about a horizontal grid; it's about having a constant
             multiple of lines.
   Nat: yes.
   Nat: I think we should go through in detail the line grid proposal.
        When I read through it I had several questions about what happens
        when the text doesn't match the grid, and what the automatic behaviors
        are supposed to be.
   Nat: It didnot seem to me that the automatic behaviors will get users
        what they need.
   Nat: I also think the line grid proposals may be trying to do many things
        at once that could be broken into separate buckets.
   Nat: The main need doesn't require grid.  You don't have to have a grid
        if you guarantee that the text line is going to be an embox tall
        and the glyphs within that line will be centered within that height.
   Nat: You can hav uneven leading and different point sizes and still have
        embox based typography.
   Nat: If you add a grid on top of that, you get several things: frame size
        will be multiple of embox size. You get gyodori (centering of title
        on multiple of embox size).
   Nat: So however many lines the paragraph is, you round up to the number
        of grid units and center within that space.
   jdaggett: So the lines that are in that paragraph don't individually line up.
   Nat: Right, but the edges of it line up.
   Nat: What you're missing from that is what the baseline grid gives you --
       for Roman typography, you have columns side by side and you want the
       baselines to line up.
   Nat: If you try to shoehorn all these user scenarios into a single feature
        you might miss things.
   Nat: I'd like to take these apart and not say, heavy handed, you have to
        use line grid and say that with line grid you might get lines
        painting on top of each other (which we don't have in InDesign).
   Steve: What Bert was referring to, I believe, was a proposal in css3-linebox
          (not line grid), which refers to line stacking.
   Bert: Not what I was referring to, but wanted to discuss.
   Steve: line-stacking had a number of options from XSL but added one called
          grid.  Not entirely clear, but the option said that whenever you
          stack something... may have treated each line separately in a title
          paragraph rather than the whole thing, but would say you'd always
          get an integral number of grid units in a stack.  That would keep
          the spacing regular without having to lay out a grid in any way.

   Koji: Design grid was proposed by Microsoft... grid ... migrated into
         line stacking strategy.  Some important features were lost during
         the migration.  Would like to go back to original requirements.
   <Bert> -> http://dev.w3.org/csswg/css3-linebox/#LineStacking line stacking
             proposal in css3-linebox
   jdaggett: A couple basic questions I have:  This is a feature now in IE?
             What's different about your proposal from what's in IE?  Have
             you gone through the linebox module?
   Koji: I read the line-stacking-strategy part.
   jdaggett:  It seems like there's crossover in what these things are
              trying to solve; we need to have one spec.
   jdaggett: You're basing it on IE-like features; are these features used?
             They've been in IE for a long time, no?
   Koji: As I understand, IE has implemented since IE 5.5.
   jdaggett:  Are people using it, and if so, for what, and if not, why not?
   Koji: People are not using it because it's IE-only.  And people's
         understanding is that its's not standard.  And it's in Word too.
   Florian:  Since IE 5.5, there was a period where it was like the only
             browser, so I don't think that's a sufficient explanation.
   Koji: I'm not sure about this detail, but I think IE's implementation is
         different from implementation ... Murakami-san.
   jdaggett:  Need more detail on that.
   Koji:  Current implementation in IE doesn't match spec (2001 WD of text).
   Murakami: I think the older draft had problem:  the line grid model in
             the older draft was only in one block, not for the whole page.
             So the lines line up in only one paragraph, not across them.
   jdaggett: Is that how it's implemented now?
   Koji: Microsoft stopped improving the feature since it was dropped.
   Alex: May be different in standards mode.  We don't see it used, so we
         don't know what kind of support we need.
   ?: Other East Asian languages, not just Japanese?
   Nat: Affects languages with em-square typography, Chinese, Japanese, Korean.
   Koji: Has line progression part and inline direction part; line
         progression part important for Roman too.
   jdaggett: We also have the line spec.
   Koji: line-stacking-strategy is controlled in each block, but there's
         a situation where you want to turn it off once and then turn it
         back, you need to know ... scope.
   Nat: Sounds like we need to flesh out the requirements more.
   jdaggett: That's my concern.  We're not taking existing specs and
             saying we need to solve this set of problems.  We're saying
             we need this set of features which happened to have been
             specced out at some point in time
   Koji: For the review, I focused on background section (scenarios) and
         future section.
   Koji: I want to agree on use cases and problems we want to solve

   Nat: It's possible to be compliant with grid and still have problems
        with placement if you don't solve the line height problem.  In
        Japanese traditional typography, the base font size is the only
        thing contributing to the line height.
   Nat: The push and pull with whether you want it to be able to write
        over the next line or not, we decided not to have any automatic
        protection against overlap.
   Nat: As someone who tries to develop a layout engine for this stuff,
        I want to have a predictable model:  want UI for setting Y
        position to translate to embox based world.  If we're worried
        about intrusions maybe it could be solved some other way.
   Nat: On top of that, there's the grid.  What points do you provide
        to snap it to?  They're on the embox.
   Steve: Another piece of the line stacking strategy was properties
          that turned on/off whether ruby contributed to the line height.
   Nat: That seems like a hack.
   dbaron: Don't think there was a mistake in the history there; just a property.

   Steve: There were 4 line stacking strategies:
            with embox stacking you don't want it to contribute;
            with the current CSS model you probably do want it to contribute,
            which is why I think there's an option.
   Koji: I proposed line-stacking-ruby: auto, which is a combination.
         Most publishers don't care about overlapping because they fix
         before releasing.  But with EPUB authors can't edit after rendering.
         So ruby should not be included in line height unless it causes overlap.
   Nat: So then what?  You go down to zero, and that line will have different
        line spacing?
   Koji: also important for mobile phones, where people care about fitting
         more information rather than getting regular line spacing.
   Steve: I'm now confused:  I understand line-stacking-strategy doesn't
          define a constant grid across the space. If I'm using classic
          CSS line stacking I want everything included and I won't get
          collisions based on the way it's defined.  So that seems to me
         to deal with the ??? problem.  If I want constant em-based
         typography, then I have the option of setting the lne-height so
         the line gap is sufficient for the kenten, ruby, underlines, so
         I don't get a collision.
   Steve: Depending on which strategy I either want them in or I don't want

   Nat: That's what happens today.  You can solve this by saying:  yes,
        include everything that's drawing in the line-height.  But then
        when you center on the embox, ...
   Nat: If we include ruby, kenten, etc., and make a larger line height,
        we still have an ideal alignment point (the center of the embox).
        But we don't have that information.
   Nat: Need that to get even line spacing.
   Steve: Today, in CSS, you don't know where the baseline is.
   dbaron: I don't think that's true.
   Nat: line grid causes gyodori
   Taro: The position of the first line must be specified by the user,
         and must not be changed by ... (differences between ascender and
Scribe: fantasai
   dbaron: I don't see what in the existing CSS model breaks that, except
           stuff that's specific to ruby
   Florian: when you have 2 lines, the second one will be placed so that
            the top of the second box is aligned with the bottom of the
            first box.
   Florian: If what you care is not the placement of the box, but the
            content of the lines, you need the distance between baselines,
            or middle-lines
   Florian: If the first line contains an image, the second one's nothing
            special, let's say the thir one has Ruby
   Florian: These three lines will have different heights.
   dbaron: Suppose the image is baseline-aligned so it sticks up, it makes
           the first line bigger, but doesn't change spacing between first
           and second line
   Nat: image is red-herring, treated like a giant character
   Nat: ruby and decorations are better
   dbaron: decorations don't affect line spacing
   Nat: Does in webkit
   fantasai: that's a bug
   dbaorn: Let's say it's an open question with ruby spec how if at all
           it should affect line spacing
   Florian draws three lines of text as squares
   bottom line has ruby above it
   Florian: spacing is different
   dbaron: if you assume ruby affects line spacing, which current drafts
           say it shouldn't
   multiple ppl talking

   Steve: The other problem is the leading goes above and below
   Nat draws leading above and below the lines
   Nat: If this guy's leading is different from this leading, it'll behave
        differently than convention
   Nat: Convention is to measure leading from top of line to next line
   Nat: This is understandable to designers in Japan
   Nat: But 1/2 of first line leading and 1/2 of second line leading is
   Nat: It's much easier to place body text when you're only dealing with
        one number
   Nat: whether you measure from top of line to top of next line, or middle
        of line to middle of next line
   Nat: the combination of half-leading is confusing
   Steve: tate-chu-yoko  is always measuring as 1em, not measuring more
          than that even if it overflows 1em
   Nat: Often it'll stick out visually. Doesn't mean it needs to make the
        line taller
   Nat: For tcy, you need to make the cap-height 1em
   Nat: Otherwise it doesn't look good
   Koji: I think the problem you're discussing is a problem we're trying
         to solve without changing the CSS model. You are trying to change
         the model, it seems.
   Nat: No, just trying to describe the required behavior
   dbaron: You talk about authors thinking or not thinking in 1/2 leading
   dbaron: I don't think authors understand the CSS model, be they Japanese
           or Western
   dbaron: Maybe we need a way for them to opt into another model.
   Nat: ... embox top. If they want to do this, there are different point
        sizes here, so you get a+1/2b
   Nat: It's much easier to present info in embox terms, and have engine
        be able to spit out CSS that may be hand-tuned ..
   Nat: CSS is a half-human-readable API. If you can express things in CSS
        using embox top leading model, it's so much easier.

   dbaron: There's sort of two problems with that sort of leading model, I think
   dbaron: related to what happens around the edges of boxes
   dbaron: If you have multiple lines of text in a box, there are 2 cases
           you need to worry about.
   dbaron: One is the box has some visual appearance,e.g. border or background,
           and you see the edges of the box
   dbaron: So you need to think about the spacing between the text and the
           top of the box.
   dbaron: Then there's the opposite case: you have a box that's interior
           to some visual effect, and you want consistent line-spacing
           between that and the preceding content
   dbaron: I'd be very uncomfortable with something that doesn't work right
           by default for the simple cases of both of those.
   <fantasai> dbaron++ :)
   Steve: Getting consistent line spacing seems to be easier to do with a
          model that involves snapping than stacking
   Steve: Trying to get the stacking to work and have consistent spacing
          gets into issues that I don't think we're solving.
   Nat: Please explain?
   dbaron: If you have box-with-visual-appearance
   dbaron: If you're talking about leading as something that goes below a
           line, you get problem with large line-spacing
   dbaron: where text jams right up against the top border, and then a big
           gap at the bottom
   Nat: You don't add the leading at the bottom of the box.
   dbaron: That works well for the case where the box does have a visual
   dbaron: but then that fails for the case where the box doesn't have a
           visual appearance.
   dbaron: One thing we try to preserve in CSS is that if you have a box,
           and you stick a <div> in there where there are already line
           breaks, the rendering doesn't change.
   dbaron: A <div>, by default, should be invisible.
   dbaron: If you cancel at both edges, then you lose the spacing between
           the lines inside and outside the div (or before/after the div)
   dbaron: Whatever model we come up with, I think we're sort of stuck with
           that concept.
   dbaron: We're not distinguishng between two categories of boxes
   dbaron: The normal case I'm worried about is e.g. article in newspaper.
           You have paragraphs of text.
   dbaron: You don't want a model where space between paragraphs is different
           from space between lines within paragraphs.
   Nat: Now I understand why you do half on either side.
   Nat: ...
   Steve: You can set line-height on spans
   Nat: when you're flowing text between two frames
   dbaron: frame?
   dbaron: I could try to explain existing CSS model over lunch?

<br type="lunch"/>

Scribe: TabAtkins
   Nat: A bit of closure on the previous discussion.
   Nat: [something about leading?]
   Nat: If there's no other available thing, then maybe it's true that we're
        stuck with half-leading model.
   Nat: Based on the history, I think it may be possible to keep most of the
        current workings if we provide a way for the UA & author to understand
        where to place the em box.
   Nat: That is, where does the metric belong in the convoluted package of
        the line box.
   Nat: What's the offset from the line-top to the top of the em box, or
        whatever, and where is the offset measured from?
   Nat: In InDesign, we can control this.  The 0 point by default is the
        roman baseline, but you can change this.
   Nat: You can specify whether it's most important to match the "baseline"
        of the em box to the baseline of the linebox, or the center, etc.
   Nat: So once I can place my nice Japanese world on top of the linebox
        accurately, then it doesn't matter very much that the rest of the
        inline layou tmodel exists.

   fantasai presents a new proposal
   fantasai: We have a new property, 'line-grid', which takes an ident.
   fantasai: Initial value is 'root'.
   fantasai: It inherits.
   fantasai: If you set it on an element, and no ancestor has the same value,
             it creates a line-grid out of the line-height and font-size
   fantasai: The line-grid consists of all of the baselines.
   fantasai: If I'm inside a paragraph and I say I want "line-grid:root",
             I'll get the root's grid, regardless of what other grids have
             been set up between the paragraph and the root.
   fantasai: A fresh grid starts at the content-box of the creating element.
   dbaron: You probably want an option to say "don't put half the line-gap
           at the top and bottom".
   fantasai: Yes.
   fantasai: The idea is just to match what the text would look like if all
             the font was the same size/face/etc.
   Nat: I propose an offset from the top.
   [discussion saying we should wait to see how the grid actually works]

   <dbaron> fantasai also said we could add an option to control that for the
            text case, which would then also affect the grid establishment.

   dbaron: What's the use-case for a named line-grid, instead of just
           using the line-grid from an ancestor?
   vhardy: You may want two floats that both use the same grid.
   dbaron: What about having an outer grid, an element with sets up a new
           grid, then a child that wants to use the outer grid again?
   hober: Perhaps the middle content is sufficiently weird...
   dbaron: Would that just be making the middle content not snap?
   [dbaron isn't convinced there's an example where named grids are necessary]
   [and we're continuing to listen to the rest of Elika's presentation]

   fantasai: Next property is "line-snap: <baseline>".
   "line-snap: <baseline> | bounds"
   fantasai: It says "all the lineboxes that I'm a container for, shift them
             down until they snap to my grid."
   fantasai: (until its baseline snaps to the next baseline in the grid)
   fantasai: The "bounds" value takes the text-top and text-bottom (embox
             top and bottom)...
   fantasai: And, if it fits between the text-top/text-bottom lines in the
             grid, centers them in there.  If it's wider, it finds the next
             text-bottom that it can fit between, and then centers.
   fantasai: In other words, it finds the next text-top, and then the nearest
             text-bottom that it'll fit into, and centers the linebox between
             those two lines.
   fantasai: And the property is inherited.  Also, need a none value.
             "line-snap: <baseline> | bounds | none;".  Initial is 'none'.
   fantasai: There's a root line-grid by default, so you can use line-snap
             before setting up a line-grid.

   [Nat gives some example that I can't work out]
   fantasai: We have a 'padding' property on boxes to shift their content
   hober: [translation] When you've got the container that establishes your
   hober: The grid starts at the top of the content-box.
   hober: If you have a region that happens to only partly overlap the
          element that establishes the line-grid...
   hober: The text will then start at a weird spot in the region, because
          the grid doesn't start high enough.
   fantasai: The grid extends infinitely in both directions.
   Nat: So, frex, if you have some large header, you want to start the grid
        at the bottom of the header.
   dbaron: You can just set the linegrid on a container for the body content.
           You don't have set it on the root.
   Nat: [something about InDesign possibly having issues with exporting
        into HTML with that]
   plinss: With all due respect, we're not implementing InDesign.  We just
           want to hit the use-cases that are necessary for publishing.
           Difficulties for existing programs to map into aren't as big a deal.

   fantasai: Also, for t/r/b/l, a snap(<grid-name>) function.
   Steve: What we're trying to do with this is gyodori for paragraphs.
   dbaron: I was hoping to have a third property like "box-snap:bounds",
           which would center boxes within the necessary number of grid units.
   fantasai: If you snap both your top and bottom, you center in between.
   fantasai: I think if you're positioning a box, you'd snap top to the
             text-top and bottom to the text-bottom.
   <dbaron> (Though the box-snap might *require* that we drop the named
            grids and just go to a mechanism for establishing a new line grid.)
   florian: In a kanji situation, it's common to snap images to the kanji-top.
   fantasai: So, that's the overview.  The box-snapping part needs work,
             but I think the rest is what we want.

   kojiishi: My proposal is very similar in regards to defining grids.
   kojiishi: When I asked for review in Japan, descendants could be difficult
             if the descendant establishes a BFC.
   dbaron: Using it within a float doesn't sound that bad; using it within
           something that's scrollable does.
   plinss: You'd just scroll the grid.
   dbaron: Okay, I guess it doesn't break the model. With floats,
           overflow:scroll did.
   jdaggett: What happens with varying font-sizes?
   jdaggett: Do you reach a point where you suddenly get larger gaps?
   fantasai: Potentially, but you can use line-stacking-strategy to decide
             what to exclude from the line height calculation, so you can
             still make things collide.
   dbaron: So you generally would want to use a fairly restricted
           line-stacking-strategy, so you don't jump line-grids very often.
   <dbaron> s/line-stacking-strategy/line-stacking-strategy or line-box-contain
            or whatever we end up with/
   Peter: You could potentially add a value for tolerance (to allow a small
          amount of overlap).

   Nat: What about paragraph-level gyodori?
   szilles: The t/r/b/l stuff was for that. dbaron and I think there may be
            a simpler answer for that.
   szilles: Involving "box-snap: bounds".
   vhardy: You may want to define multiple line-grids from the same element
           (at different sizes, frex).
   fantasai: We can add multiple grids later if necessary.
   dbaron: Yet another usecase for ::outside/inside!
   alexmog: [channeling glazman] I'd hate to write an editor that exposes
            multiple grids defined on the same element.
   <dbaron> (we could minute it as :glazou, for pseudo-glazou :-)
   <hober> shouldn't it be ::glazou?

   alexmog: Ruby doesn't affect line-stacking, right?
   fantasai: If it affects line/block height, yes. Otherwise, no. By default, no.
   szilles: As an example, say you have a headline with some ruby on the top.
            What would an editor want for this?
   Nat: You'd ignore the ruby and center based on the heading. But you'd
        also include some padding to make sure there's enough space for
        the ruby.
   [more discussion about ruby, and why you wouldn't include it in the
    line height]

   kojiishi: Another request in this area, for a character-based grid.
   kojiishi: In Chinese, each character is snapped to the grid, whereas
             in Japanese only the start and end of the line box need to
             be snapped.
   kojiishi: So, for example, if you have a float in the middle of some
             em-based script, the shortened lines by default would probably
             start off-alignment with the rest of the text.
   kojiishi: This property would set up a grid in the orthogonal direction
             to the line-grid, so the linebox snaps to the nearest grid.
   hober: You'd want the same thing for monospaced western fonts.
   Steve: though that's not 1em wide..
   Nat: I'm still disturbed by line-stacking, with 20pt text with 120%
        leading mixed with 24pt text with 120% leading, it's very difficult
        to get it to work like the japanese designer would want.
   Nat: They'd want the line-spacing to be based on one of those values.
   Nat: [1em text, 1em spacing, 1em big text, 1em big spacing, etc.]
   <dbaron> spacing -> 0.5em
   Nat: I'm satisfied if we just log a note about how this half-leading
        works with grids.
   <nmccully> My issue is that the space between lines is dependent on
              the leading value on _both_ lines, making it difficult for
              the author to get the look they want.
   <nmccully> If you add the ability to calculate line gap based on one
              or the other line's leading (and leading origin and direction,
              etc), then it makes it more predictable for Japanese authors,
              I think.

   fantasai: If you're snapping things to the line-grid, you may want to
             snap things to the layout-grid as well.
   fantasai: Have the images align with the layout-grid, for example.
   szilles: Why are we using grid here?  I'm asking this because we have
            two orthogonal concepts.
   szilles: A regular set of horizontal lines (or vertical), and a regular
            set of character positions.  Together they make a grid, but
            independently they're not.
   fantasai: Do you have a suggestion?
   plinss: We can have a note about that.
   alexmog: So we have a new line-grid spec from Koji.  Is this the base from
            which we further develop, or do we have competing proposals?
   jdaggett: I think there's overlapping functionality with Linebox, but not
             competing.  But I don't think these should be two specs.
   [discussion about how to organize the specs]
   alexmog: Can we have a resolution about how we expect the specs to merge/alter?
   RESOLVED: Eventually we'll have one Line spec, which includes current Linebox and Linegrid.


   jdaggett: In section 5, there's a lot of weird lingo, like "bi-orientational
   jdaggett: Can we use simpler terms here?
   fantasai: Suggestions?
   jdaggett: [something I couldn't quite parse about the spec not matching what
              authors think of]

   jdaggett: Another issue - not sure if stuff like the "intrinsic text
             orientation" is the right set of controls to use.
   jdaggett: Once you're in vertical-lr/rl, there's a natural orientation that
             horizontal text can have.
   fantasai: There's some behavior implied by the orientation, and some that's
   fantasai: If you're using right-to-left columns up text, you'll either
             rotate [this way], or stack the text.
   fantasai: And that's not intrinsic to the orientation of the script.
   fantasai: [draws diagram of how Mongolian would orient horizontal text]
   jdaggett: It seems like the behavior we want, rotate-normal...
   fantasai: We want rotate-normal if we're a horizontal scripts.  We want
             vertical-right for vertical scripts.
   jdaggett: The behavior of rotate-normal changes based on the writing mode.
   <dbaron> vertical-lr scripts:
   <dbaron> also http://en.wikipedia.org/wiki/Clear_script

   jdaggett: So why not have the 'auto' setting work most of the time.
   jdaggett: There's an exception, but the normal case for most scripts is to
             rotate it to the right.
   fantasai: rotate-normal will rotate Chinese script sideways.
   jdaggett: The default we want is called "auto" that does the right thing...
   fantasai: You can't do the right thing in all cases without defining
             the equivalent of rotate-left.
   fantasai: I can't mix rotated English and Chinese without specifying these.
   Nat: The vertical orientation specifies that English must rotate clockwise.
        So that should be the default.
   fantasai: Which is what you get with vertical-right (keeps the chinese
             vertical) or rotate-right (rotates the Chinese too).
   [something about mixing rtl and chinese/japanese]
   [and some explanation of why all the values are necessary]

   alexmog: It seems that the only two values that ever happen are that
            character are oriented with the baseline, or they are vertical.
   fantasai: [shows example of English letters being stacked, or rotated
             with baseline on right or left]

   dbaron: You're either leaving them in their normal orientation, or
           turning them so their inline progression matches the inline
           progression you're using, or the same with block progression.
   fantasai: We could simplify more if we're willing to screw with the
             bidi algorithm.  I was trying to leave bidi alone.
   jdaggett: I think we should just change "vertical-right" to "auto".
   szilles: That doesn't match with SVG.
   jdaggett: SVG can mess around with that themselves.  It's deprecated!
   fantasai: it's not deprecated in SVG yet.  We're deprecating their
             definition with our new one, is all.
   jdaggett: Everything but vertical-right is exceptions to the general
             behavior, which we should call "auto".
   fantasai: So, first issue is you want to rename "vertical-right" to "auto".
   fantasai: But the reasonable default behavior changes based on the context.
   fantasai: You want "vertical-right" or "rotate-normal" based on Chinese
             vs English, frex.
   fantasai: The normal thing in Mongolian and Chinese is to use 'vertical-right',
             the normal case in English, French, Arabic documents is to use
   dbaron: Are there any cases where there's embedded text rotated such that
           both its inline progression does not match the inline progression
           of the dominant script, and such that its block progression does
           not match the block progression of the dominant script?

   fantasai: Next jdagget proposal is to drop the SVG-specific values.
   Nat: Not all layout engines have the same idea of what is the default
   Nat: That freedom should maybe be allowed.
   fantasai: The requirements for vertical-right are that
             (1) vertical scripts *must* be in their default orientation, and
             (2) horizontal scripts *must* be rotated to the right

   <dbaron> I think another way to look at this is that the use case for
            'vertical-right' is honor-block-direction, the use case for
            'upright' is honor-natural-horientation, the Mongolian example
            with the English the other way around is 'honor-inline-direction',
            and the 'rotate-right' and 'rotate-left' cases are layout-affecting
            transforms rather than vertical text
   [whole lots of discussion I have no idea about]
   fantasai: I can rename 'upright' to 'stacked', if that helps.
   dbaron: Maybe this is crazy, but I have an alternate model in my head
           where the existing examples for rotate-right/left are
           layout-affecting transforms.
   dbaron: But then you still need vertical-left/right and an escape hatch,
           where instead of vertical-right (honoring the block-progression
           direction), you honor the inline-progression direction.
   dbaron: This alternative doesn't give you [something], but that's it.

   Yamamoto: When japanese characters are upright and arabic is used, naturally,
             only looking at those characters, it looks natural for the arabic
             characters to start at the top and proceed to the bottom.
   Yamamoto: But when roman characters exist as well, their top is on the right,
             but then the arabic characters are on the left side.
   Yamamoto: To resolve this contradiction, publishers will set arabic from
             bottom-to-top, and keep the roman on top-to-bottom.
   szilles: When I rotate english to the left, it seems I'm in a bottom-to-top
   fantasai: Yes.
   szilles: So then, is the 'auto' value for bottom-to-top to rotate everything
            left?  Because there are effectively no bottom-to-top languages.
   fantasai: Yes, which is why those btt languages will actually go ttb unless
             you set rotate-left.

   fantasai: Any other issues that need to be discussed?
   szilles: Yesterday in the forum, in the shift to upright, numbers went to
            traditional c/j encoding.
   fantasai: It's not just a codepoint swap, they actually transformed [???]
   jdaggett: It's numerical transforms.
   <dbaron> 135 -> 百三十五
   <dbaron> (not 135 -> 一三五!)
   fantasai: escape hatch:  <abbr title="百三十五">135</abbr> and
             abbr { content: attr(title); }
   fantasai: Escape hatch for now is just hiding the alternate form in an
             attribute and pulling it in via "content: attr()".

   Daniel Davis: Could rotate-right/left be baseline-right/left?
   fantasai: which baseline?
   <fantasai> suggestion was sideways-left, sideways-right, and sideways
   dbaron: If we ever add bottom-to-top, vertical-right is not going to be
           what we want for those.
   fantasai: The info we're missing to make this all super-intelligent is...
             We have ltr and rtl which gives us bidi for horizontal.  If we
             had similar for vertical, we could do a lot more here.
   fantasai: Like, ttb-rtl would let us know that it's rtl in horizontal
             and ttb in vertical.

   Straw Poll: The default value for text-orientation
   Should it be named 'auto' or 'vertical-right'
   danield: Abstain
   jdaggett: auto
   sylvaing: auto
   dbaron: vertical-right
   kojiishi: vertical-right
   florian: vertical-right
   szilles: auto
   alexmog: auto
   vhardy: auto
   Bert: abstain
   <dbaron> (vertical-right because I think there's actually relatively
            little logic to it, because the normal behavior of Mongolian
             is weird)
   Taro: auto
   Nat: auto
   TabAtkins: abstain
   hober: vertical-right
   plinss: vertical-right
   murakami: vertical-right
   fantasai: vertical-right
   7 'auto', 7 'vertical-right', 3 'abstain'
   plinss: 'auto' implies it will change behavior based on something else.
   dbaron: I went for 'vertical-right' because it seems that it's relying
           on the fact that "normal" use in mongolian is what I would
           personally consider really weird.
   dbaron: And it just so happens that it all works out, because the
           normal behavior for Mongolian and Chinese turn the same way.
   Steve: But Mongolian written horizontally actually runs left-to-right
          (due to Russian influence).
   Florian: I don't like 'auto' because if you're not aware of natively
            vertical scripts and you just want to turn some English to
            the side, you expect 'auto' to not turn it to the side.
   dbaron: oh
   szilles: I'll point out that if you have vertical tabs on multiple pages,
            the ones on opposite pages go in opposite directions.
   <nmccully> good point about English in vertical "auto" is biased toward
              Japanese default behavior, not some other convention

   fantasai: The next issue is the SVG property.
   fantasai: SVG basically said that they'll do what we decide on.
   szilles: Can we just call the value "svg-historic"?
   jdaggett: Anything except "auto".
   fantasai: agreed
   fantasai: I can change it to "svg-historic" or "use-glyph-orientation"
             or something.
   plinss: Maybe mark the value as at-risk.
   RESOLVED: Renamed the 'auto' value for text-orientation, and mark the
             value as at-risk.

Baselines in Vertical Text

   jdaggett: I'm confused about how vertical-align works for vertical text.
   [something about multiple baselines]
   fantasai: [points to the definition in the "introduction to baselines"
   Nat: Incidentally, baselines are wrong for ideographic in the pictures.
   jdaggett: This example and text and such shouldn't be in this spec, though.
             It should be in the Linebox module.
   jdaggett: I'm concerned that if we put non-normative text here, we'll
             imply behavior to impls that may conflict with the later
             normative text in Linebox.
   fantasai: I need at least two baselines defined.
   jdaggett: Right.  We just don't need quite this much detail.  There's
             also stuff about metrics, which is completely unnecessary.
   szilles: I can fix the diagram to just provide the necessary info.
   jdaggett: And then when we talk about metrics, this is completely not
             what browsers actually do.
   szilles: We agreed on this text some time ago in the WG.  It's in the
            2.1 spec.
   fantasai: Most of it.
   jdaggett: Darn, then we have a larger issue.
   szilles: It was put there to provide a reasonable set of fallbacks for
            dealing with what happens with real-world fonts.
   jdaggett: And real-world fonts in Windows use the windows metrics.
   szilles: They have nothing to do with the em box.
   jdaggett: A browser written on windows that's not written by adobe will
             use the metrics provided by the OS, which will generally be
             the windows metrics.
   jdaggett: I'm not objecting that this is wrong behavior, it's just not
             what impls do.
   RESOLVED: Remove 4.2.1 from the Writing Modes spec.

   fantasai: [explains how the spec deals with alphabetic/central baselines]
   jdaggett: So the behavior for 'sub' and 'super' in vertical is to shift
   fantasai: Yes.
   jdaggett: And what about when tatechuyoko(sp?) is used?
   fantasai: That's defined to basically synthesize a new glyph which then
             has a singular baseline.
   szilles: So you're asking about what happens if there is vertical-align'd
            text in tatechuyoko?
   fantasai: Right now it's defined to *not* trigger tatechuyoko if there
             is any further structure.
   <nmccully> It should be possible to set text inside the TCY using
              baselines (horizontal ones) for superscript or subscript
   <nmccully> The whole thing would be centered in the vertical line
   szilles: [some point about horizontal text in horizontal japanese?]
   jdaggett would like some more expanatory text here.
   jdaggett: "The default alignment is 'baseline', and that uses the
              dominant baseline, which changes based on the writing mode."

text-combine / tate-chu-yoko

   <jdaggett> http://people.mozilla.org/~jdaggett/images/tatechuyoko-percent.png
   [looking at the email]
   jdaggett: This property name was original meant for kumimoji, actually.
   I also proposed "text-inline-horizontal: none | half | third | quarter".
   [last was from jdaggett]

   Taro: When two characters are combined, it's possible the editor wants
         to condense them to get them into 1em width.
   Taro: That typically applies to 2-digit numbers without a decimal point.
   Taro: The case with a decimal point is kind of an exception.
   Nat: We have half and quarter-width characters, but I think that's mostly
        a throwback to when they weren't really scalable.
   [jdaggett shows example from the spec about tatechuyoko]
   jdaggett: You see the year and day are using tatechuyoko.
   jdaggett: The way it's currently defined, you have to wrap each number in
             spans.  Ideally, you could just say "use tatechuyoko when
   kojiishi: I think that 'automatic' is nice, but if we were only doing one
             or the other, we should do the explicit one first.
   [jdagget shows another example from the email]
   jdaggett: Here you have an example of where you want to do tatechuyoko on
             "up to 2" things.
   The first date, with two digits, would use tatechuyoko.
   The second date, with a 4-digit eyar, would stack the digits of the year,
     but use tatechuyoko for the month/day, as they are still two digits.
   jdaggett: Also, how does this combine with text-transform?
   fantasai: Maybe text-transform would turn off automatically.
   fantasai: If the number is too wide, use text-transform, otherwise use
   jdaggett: I also think it should say that under no circumstances should
             it change the linebox.
   ISSUE - define interaction with text-transform
   ISSUE - make spec clear that the tcy is only 1em high
   <fantasai> even if the glyphs bleed outside that 1em

   fantasai: There's a comment in the spec about automatic tcy saying we
             could maybe have a value like "digits" and a maximum number
             of digits to combine.
   jdaggett: In the single-digit case you may want to use wider characters,
   <fantasai> e.g. text-combine-auto: digits 3;
   fantasai: We should be able to solve that by setting text-transform:fullwidth
             and turning it off when tcy applies.
   fantasai: We do want a way to force tcy sometimes, too.
   fantasai: If we want to deal with automatic stuff here, we can.
   Nat: I think you'll definitely get requests for it.  It'll be cumbersome
        for authors, and tcy, in the 80% case, is just two digits, and you'll
        want to auto-tcy *all* 2-digit numbers everywhere.
   Nat: As long as you keep the edge cases in mind while designing the
        automatic thing, it'll work.
   Nat: [discussion about processing, using "anything that fits into X"
         versus "all 2/3 digit numbers"]
   Nat: [prefers the latter, as it doesn't require you to call down into the
         font renderer before deciding whether to use tcy]
   jdaggett: I mainly just wanted dates to work, so you only needed one span
             to wrap a date with.
   szilles: Automatic is good, but also I want to use tcy on arbitrary
            characters, so we want manual forcing as well.
   Nat: jdaggett's proposal doesn't get "2010" to be quarter-width and
        "4" being full-width, though.
   jdaggett: You can do manual overrides.
   Nat: We find that anytime we do automatic, we get people angry because
        they're doing something weird.
   szilles: That should be okay as long as there's an ability to override
   Nat: Maybe we can combine these - use tcy for 2/3/4 digits, fullwidth
        for 1 digit, and let the author use whatever unicode digits they want.
   Nat: If we can come up with a property for that and use it in tcy as
        well, that would be nice.

   fantasai: What about "text-combine-horizontal: all | digits <number>? || alpha <number>?".
   "all" is entire contents, no smushing.
   fantasai: "... && [half | third | quarter]"
   Nat: For smushing, have the value somehow apply that it's about fitting,
        whether by using specified special glyphs or by scaling the glyphs
   fantasai: or "... && fit"
   fantasai: So you can specify "all", which just puts it all in tcy without
   fantasai: Or "alpha <integer>" or "digits <integer>
   fantasai: Which swaps alphas/digits for the appropriate-width characters
             and does tcy.
   <Bert> (1,000 is different from 1, 000)
   "all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ]"
   "none | all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ] && [ fit | scale ]"
   "fit" means try to use the half/third/quarter-width glyphs first, otherwise fall back to scaling.
   "none | all | [ digits <integer> || alpha <integer> || alphanumeric <integer> ] && [ use-glyphs | scale ]"

   Nat: My ideal is that by default, you don't do glyph substitution or scaling,
        and you have to specify to use glyphs or scaling.
   plinss: We have enough progress here now.  Take the rest for later.

Vertical Text: Form Controls / Editorial

   jdaggett: Next issue is that we don't have any talk about form elements.
   jdaggett: It's right that CSS doesn't apply to form controls internals,
             by definition, but still, the layout of a form control has a
             huge impact on the layout of other things.
   fantasai: I'm willing to put in examples of how form controls *should*
             work in vertical text, so impls can do it right.  I'm not
             willing to do normative text yet, though, because I'm not
             willing to define how form controls internals are exposed.
   jdaggett: I just want to say "form controls follow the text direction", etc.
   fantasai: It says that already.
   ISSUE - put in some examples, maybe using IE9 screenshots
   <Ms2ger> Hah

   jdaggett: Next issue.  Minor point, but I don't like that "writing-mode"
             is labelled the block direction.
   jdaggett: It's influencing the direction in which text flows.
   Bert: "block flow direction" is a technical term that means quite a lot.
   Bert: It implies a bunch of typographic rules, including what's upright
         and what's rotated.
   fantasai: That's "writing mode".  The block flow direction basically
             determines the direction in which block boxes and lineboxes
             stack, and whether the linebox is horizontal or vertical.
   szilles: The title of the section could just be simplified to "The
            'writing-mode' Property", to avoid the confusion.
   fantasai: The "writing mode" term encompasses 3 properties.  The
             'writing-mode' property is one aspect.
   fantasai: If it was up to me I'd call it 'block-flow-direction', but
             I think it's too late now.
   sylvaing: Why is it too late?
   fantasai: maybe I can change it

text-orientation and punctuation

   fantasai: Last issue is text-orientation and punctuation.
   jdaggett: I was suggesting as a loose default that you should specify
             all the scripts that are upright, and everything else is rotated.
   jdaggett: For the common/inherited characters, use whatever the previous
             script block was.

   Nat: The problem we ran into is that for the ambiguous chars (U+2000),
        depending on the font the glyph design was different.
   Nat: Our method was that if it was in Shift-JIS and fullwidth, it was
        upright.  Otherwise, rotated.
   Nat: [some things are crazy]
   jdaggett: Short version - "we're screwed".

   fantasai: There's a bunch of characters we can definitely tell for.
             We say that the ambiguous characters may be UA dependent,
             and point to two features that can be used for detection.
   Nat: Originally a bunch of chinese characters were in PUA, and outside
        our lists, so we rotated them.  We switched to looking at the font
        to see if it's a vertical script font, and treating the PUA as
        upright then.
   [chatter about fonts and such]
   ISSUE - add reference to Unicode database
   dbaron: Refer to a particular version of Unicode

   [unminuted discussion of font features, e.g. vrt2]

Scribe: fantasai
   Nat: I don't think it's useful to say to the UA to determine which ones
        are upright and which ones are not, because at the point that the
        engines are unfamiliar with, we don't have access to the glyph ids
   Nat: I'm not sure why that's common to the ones I know, but seems to me
       that it's difficult ...
   Nat explains that most engines he knows split the runs into roman (sideways)
       and non-roman (upright), and default mode is sideways, and vrt2
       requires not splitting runs and making everything upright because
       it has prerotated glyphs
   <Bert> -> http://www.microsoft.com/typography/otspec/recom.htm
             Adobe Type Manager/NT 4.1 and Windows 2000 require the vrt2
             feature in an OT font to do vertical writing.
   <Bert> -> http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2
             Description of the vrt2 feature in OT

   jdaggett: I think we have to do an implementation and see if using vrt2
             actually work
   jdaggett: puzzled why Unicode didn't deal with this stuff
   fantasai: partly 'cuz they consider vertical layout out-of-scope
   fantasai: and partly because the correct orientation depends on the font
             and how that glyph was designed
   Nat: Unicode unified various characters, so  ... it's a difficult problem.
   Nat: It would be nice if, Unicode is a good authority .. if they had to
        go through the exercise of making this table of which ones are
        upright and which are not, they might realize that maybe they should
        have separate codepoints.


   dbaron: So you've revised the values of unicode-bidi
   dbaron: I looked it over, and I think it makes sense.
   dbaron: I think the revision now allows the combinations that make sense
           and not some other combinations
   dbaron: But I guess..
   dbaron: I'm still a little fuzzy on the 'plaintext' thing and why it
           converts to 'isolate', given you can use the combination of
           plaintext and isolate
   fantasai: oh, hm, I'm not sure why I did that
   fantasai: we should have plaintext imply isolate, and then if you set
             it on an inline element it sets its embedding direction like
             it would have set its base direction if it were a block
   fantasai: so allowing combination of plaintext and isolate does not
             make sense
   ACTION: fantasai edit the spec per above and check with smontagu
   <trackbot> Created ACTION-321
   dbaron: Other interesting constraint is that the current restrictions
           on the values don't allow combinations of new values and old
           values, which is nice because we can prefix the new values and
           implement the whole new proposal

bidi box model

   fantasai: so the remaining issue is the box model for bidi when you
             break the box across lines
   dbaron: ... yes, I think that makes sense
   fantasai: So should we fix this?
   dbaron: So Gecko does what the spec says in this case and it looks stupid
   fantasai: I think someone said IE9 does what we're proposing
   plinss: bidi was so broken in CSS2.1 that I don't think there's a backwards-compat issue
   sylvain loads the testcase
   dbaron: That's what fantasai said it should do
   bunch of ppl gather around dbaron and sylvain's laptops
   <dbaron> so fantasai's proposal sounds good to me
   RESOLVED: Fix this in CSS2.1 and CSS3 Writing Modes

Meeting closed.

Received on Friday, 10 June 2011 15:49:13 UTC