[CSSWG] Minutes and Resolutions Paris F2F 2012-02-08 Wed PM II: Writing Modes & UTR50, Fragmentation, Transforms

Writing Modes

   Discussion of UTR50 status and 'text-orientation' property.


   Rossen and fantasai produced a draft of a CSS3 module dedicated
   to breaking across pages/columns/regions/etc. (i.e. pagination).
     RESOLVED: publish FPWD of Fragmentation.


   - RESOLVED: matrix and matrix-3d continue to take unitless numbers, where
               they need units, they are implicitly px or 1/px.
   - Discussed status of issues, 2D/3D/CSS/SVG merge, and how fast it's
     possible to make progress.

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

Writing Modes
Scribe: Bert

   fantasai: Status is: Unicode is working on a proposal. Microsoft is
             providing data. Some data still missing. We'll talk to UTC
             tomorrow. *Maybe* it'll get done within 2 years...
   * fantasai is minuted-out
   John: Several modes within vertical: default mode, stacking mode
   John: former for Japanese
   John: many variations across script.
   John: Upright in our spec breaks shaping.
   John: but in their proposal it does not.
   [people looking at image, wondering if it wrong]
   David: [explains the hebrew image]
   John: Controversy is about bidi, flipping
   John: In their model, some punct always rotates.
   John: Certain things are not going to stack in the stacking mode.
   David: Is this PDF available?
   John: Only private mail so far.
   Sylvain: I can ask for more copies.
   John: Slightly diff orientations between what upright-right and upright.
   John: Until recently we had a proposal with default upright-right.
   John: Different things happen with different characters, depending
         on whether they rotate in certain conditions.
   John: This new proposal sets it up differently. Some characters are
         automatically rotated or not.
   fantasai: It was part if our original proposal as well.
   [John and fantasai working our what proposal said what]
   Florian: So, no way for author to set final orientation?
   John: Exactly.
   Fantasai: We didn't have override originally either.
   Florian: You want an 'upright-force'?
   John: Some symbols, arrows, are going to auto-rotate, isn't it, fantasai?
   fantasai: No, everything upright, except for certain for which we
             have no use-case (brackets and dashes)
   fantasai: We have no use-case for forcing everything upright.
   fantasai: Only for forcing most things upright.
   fantasai: We could add a force-upright.
   fantasai: But need a use-case first.
   John: Are the sideways forcing everything sideways?
   fantasai: Yes.
   florian: So we are not prevented from adding an override later.

   John: Hieroglyphs may mirror.
   fantasai: Typically they face the start of the line.
   fantasai: Maybe we don't need to implement that, but it is correct
   Florian: Chinese readers reading hieroglyphs
   Florian: Will they recognize the hieroglyphs?
   fantasai: People reading hiero will know about this...
   <dbaron> Table with Latin1, 日本, עִבְרִית, العربية, ᠮᠣᠨᠭᠭᠣᠯ, !@#, ([-]), and
            some hieroglyphs
   <dbaron> Table with Latin1, 日本㊥①, עִבְרִית‎, العربية, ᠮᠣᠨᠭᠭᠣᠯ, !@#, ([-]),
            and some hieroglyphs
   Steve: Upright is by cluster, not by character?
   fantasai: Yes.
   fantasai: We have a minimum definition that says you use a grapheme cluster,
             and can tailor it to include more.
   Steve: I heard it is not exactly the right term.
   fantasai: It is the closest that applies.
   fantasai: We have some text about other traditions in the text.
   fantasai: We asked for more details, but nobody is giving us any.
   Steve: So it is not a character property.
   fantasai: ...
   John: When you have clusters, with base and comb, char, then rotation
         is determined by base char.
   Steve: If you have a hyphenated combination (or apostrophe), do I want
          ... or... [drawings]
   Steve: Can the apostrophe be below the letter in vertical stacking, or
          always attached on the right of the letter ("l'")
   glazou: Attached.
   ACTION sylvain: try to get copies of the proposal from UTC for the WG.
   John: Koji, Elika and I evolved our knowledge. We have more details now.
   John: We could come up on proposal based on Unicode ranges and properties
         that covers 95%.
   John: But then with new Unicode version we would have to revise.
   John: So it's better if Unicode defines a property.
   John: Then we don't have to define anything.
   John: Previous proposal from Adobe with upright and sideways. Now UTC has
         more detailed proposal.
   fantasai: Eric (Unicode) ...
   John: Vertical Japanese in Eric's mind has orientation, but also spacing aspects.
   John: I think it is not good to mix the aspects.
   Steve: He changed recently. He observed
   Steve: there are two things that need char classes.
   Steve: (1) rotated or not (2) what spaces applies in each context.
   Steve: He wanted one set of char classes.
   Steve: That could define both.
   Steve: One set that solves both problems.
   Steve: But since then he concluded that upright is not a character-level
   Steve: Sometimes cluster.
   Steve: (He didn't send that proposal yet.)
   Steve: A mode in text combine that does the grouping in vertical stacking case.
   Steve: More TCY and" IJ" in Dutch kind of thing.
   John: So none of us heard this before.
   John: We'll find out tomorrow.
   John: We'll join UTC call tomorrow,

   John: OpenType doesn't have a clear model what features are turned on in
   John: It will probably need to involve Microsoft as well.
   Steve: In general you do not know which features apply,
   John: For each script you know which apply.
   John: But in vertical text for those same script it is not clear.
   John: We need implementer input.
   John: Final glyph in vertical can be a ligature, or not. Not clear.
   fantasai: Might also have a vertical ligature.
   John: Some trickery.
   John: Font has vertical ligatures and they are turned on sometimes.
   John: Uses a dummy glyph.
   John: We need to figure out what UA does with OpenType.
   fantasai: It needs a VLIG (vertical ligature) feature.
   Koji: So you are joining the OpenType standardization now, too? :-)
   <glazou> FWIW http://glazman.org/tmp/Vapostrophe.xhtml


   <smfr> http://dev.w3.org/csswg/css3-break/
   fantasai: We have a draft, should we publish it?
   fantasai: There are no new features in this draft.
   fantasai: It takes the various break-* properties, made tables and added
   Bert: If there is indeed noting new, then I'm OK.
   Alex: Do you plan to put anything else in the spec?
   Alex: Behavior of abspos across pages, floats across pages?
   fantasai: Varying page widths is in the spec.
   Anton: Text comes from which other specs?
   fantasai: CSS 2.1, multicol, paged media...
   florian: Dependencies?
   fantasai: Only CSS 2.1
   Alex: Which specs should define paged abspos?
   fantasai: Probably Positioning.
   fantasai: Probably let Fragmentation deal with normal block layout and
             then other modules can refer to this.
   Alex: It assumes that you *can* actually page abspos.
   Alex: It seems it belongs more in this spec.
   Alex: Spec should say what it claims to cover in the future.
   Alex: Related to call for exclusions.
   Alex: So good to have it there right away.
   Peter: We are never prevented from adding a chapter later.
   Alex: Yes, but scope is good to know from the start.
   Anton: This will come up all the time, with so many specs and dependencies.
   Anton: In some sense we want the framework here, but whether paging
          happens at all is defined in all other modules.
   Anton: This is lower-level framework.
   fantasai: Animations is an example.
   fantasai: Each spec defines whether or not a property animates, w/o
             defining how
   fantasai: Here we have a set of possible breakpoints in Fragmentation.
   fantasai: Other specs can add points to class-one breakpoint.
   fantasai: Tables module might add rows of a table to that,
   fantasai: Flexbox might add space between flexboxes to that.
   Alex: What is status of Tables?
   fantasai: It doesn't currently exist.
   fantasai: But Fragmentation refers to CSS 2.1 for tables and defines
             breaking for it.
   fantasai: Block layout is basic and needs to be covered here,
   Alex: I see no reason to not publish, but I want discussion about scope.
   Alex: FPWD should have (in ToC) a list of things intended to be covered.
   fantasai: We can add text about relations to other specs.
   CTION fantasai: Clarify in css3-break what other specs are supposed to
                   say about fragmentation
   <trackbot> Created ACTION-445
   Rossen: Each layout defines its own fragmentation.
   RESOLVED: publish FPWD of Fragmentation.
   Alex: I expected a combination of CSS 2.1 and Paged Media should be enough
         to define 2.1 layout completely for pagination.
   Alex: To understand exactly how 2.1 paginates, you need 2.1, Paged Media
         and Fragmentation.
   fantasai: Not Paged Media.
   Alex. OK.
   Alex: For other specs, I would need to figure out what the list is,
   fantasai: The CSS layout modules should define their pagination, and can
             refer to Fragmentation and add themselves to the hooks in that
   fantasai: All other specs will say you are allowed to break here and here
             with respect to a possible break points.
   fantasai: Positioning may have to say little bit more.

   fantasai: There is an issue with two different proposed behaviors for floats.
   fantasai: Option A and option B.
   fantasai: But we don't have to pick one today, can do it later. Can publish
             both for now.
   fantasai: Heard from Alex, but not from others. Need to publish first.
   ACTION fantasai to add pictures to Fragmentation
   <trackbot> Created ACTION-446

<dbaron> Whiteboard photos from today:


   <smfr> http://lists.w3.org/Archives/Public/www-style/2009Oct/0360.html
   <smfr> https://www.w3.org/Bugs/Public/showbug.cgi?id=15628
   David: [Draws on whiteboard]
   David: Related to matrix units.
   David: 2D transform uses matrices like this [draws]
             | a  c  e | | x |     | X |
             | b  d  f | | y |  =  | Y |
             | 0  0  1 | | 1 |     | 1 |
             translate(5px, 10px)
                            ^ ^^ ~ pixels implied
             3D has 16-value matrix with units of px and 1/px and z and
                      1/z mixed in
   David: (a,b,c,d,e,f)
   David: Multiply this by (xin, yin) and it gives (xout,yout)
   David: Some have units, some are unitless.
   David: Current draft says translate takes length arguments.
   David: But matrix uses px in translation part.
   David: Nowehere else in CSS do we say that unitless means px.
   David: We could add units to e and f.
   David: But then problem with 3D.
   David: 3D matrix has two arguments with px, one with a z-index, and
          some with "px/z-index"
   David: And some with 1/px.
             |   -      -    len/z  len |
             |   -      -    len/z  len |
             | z/len  z/len    -     z  |
             | 1/len  1/len   1/z    -  |
   David: So easy enough to fix for 2D matrix, but what then for 3D matrix?
   David: Gecko implemented at first with e and f requiring a unit.
   David: FF10 allows unitless, but accepts units, too,
   Chris: That sounds like a good way,
   David: But it tells users that px is good to use, which we so far tried
          to avoid.
   glazou: But nobody will ever use a matrix.
   glazou: Will decompose into rotate, translate, etc.
   Alex: But still more people understand matrix than margin collapsing :-)

   glazou: I want DOM to output a decomposed value, not a matrix.
   glazou: Don't care whether it is with or without units.
   Chris: What is the decomposition? Arbitrary sequence that is equivalent?
   Glazou: as long as it is editable.
   Simon: Return what was set on the element.
   Simon: Preserved.
   glazou: Preserved is perfect, but a minimal decomposition is fine.
   glazou: I don't care about the units on the translation part.
   Chris: If you use multiple length in multiple translations, will they
           be recomposed into px?
   Simon: Yes
   David: the units will be translated to underlying units, for screen that
          is generally px.
   Tab: Internally it is something like 1/16 px.
   David: It seems we have to allow unitless, should we also allow lengths?
   glazou: If you really want 2em, you can just add a translate().
   Tab: Issue was computed value.
   Simon: Animation...
   David: I think animation works on matrices.
   Chris: Some people working with 3D in HTML5 *do* want matrices.
   glazou: Yes, but you don't have to put the 2em in the matrix.
   David: So people seem leaning towards no units in matrix?
   Howcome: ...
   Tab: I all invertible matrices are decomposable,
   Tab: do the others do anything important?
   several: probably not.
   glazou: When we remove the commas from the matrix (as proposed earlier),
           then we can add units.
   David: I first raised this 2.5 years ago.
   David: At this point I'm going to leave it at unitless.
   Alex: What if somebody need 1/inch?
   David: Since in = 96px, use 1/96px
   Simon: matrix API cannot always resolve lengths, if you are not using
          it on a current element.
   Florian: Could have a single unit that applies to all of the matrix.
   David: Don't really want to do that...
   Glazou: Why not unitless?
   David: Consistent with general rule in CSS that there are no unitless
          lengths, so as not to tell people to use px.
   Vincent: SVG... unitless...
   Vincent: Transform is currently an attribute in SVG, not a property.
   David: CSS things used inside SVG allow unitless.
   Vincent: In an attribute I can use something that I cannot copy and paste
            to a CSS property.
   David: That is true of most attributes.
   Chris: Fonts, e.g.
   Peter: So we conclude no units on matrix?
   Chris: Also need a more efficient representation in JS, not a string,
          but a set of numbers.
   Peter: We could pick any unit.
   David: I hope spec is clear that they are px...
   Howcome: Add some language to warn that px aren't special, only used here.
   RESOLVED: matrix and matrix-3d continue to take unitless numbers, where
             they need units, they are implicitly px or 1/px.

   David: We should not merge 2d and 3d.
   David: Progress on 2d is more than 3d.
   glazou: What if 2d reached CR before 3d, what happens to the prefix of
   David: Then we need a prefix on the 3d functions.
   Simon: We will accept... prefixed... unprefixed....
   glazou: nightmare.
   glazou: You cannot remove prefixes on 2d then.
   Peter: We can take 2d to CR and decide to drop prefixes from 3d.
   Simon: 3d is a lot less interoperable.
   David: Don't know the details of the issues.
   David: There are some tests being made.
   Peter: They are not in our system, need different formats.
   Peter: Just put them in the submitted directory and Shepherd will tell
          you what is wrong.
   Peter: Put them there as soon as you want people to review them.
   Vincent: Merging with SVG, predictable model important.
   Vincent: Editorial issues, where is work going to happen?
   Vincent: One spec to CR, then a merged spec...
   Vincent: I don't know a solution.
   David: I don't want 2d to wait on SVG stuff.
   David: 2d is not going to change.
   David: There might be more variant syntaxes, but probably not more.
   Sylvain: We rejected px already because we cant change it anymore.
   Sylvain: So bigger changes not possible either.
   Chris: A bit strange though. We promise to work together and then
          publish one spec anyway.
   Chris: SVG also has had transforms for years.
   Chris: Probably only need to work on the wording, where it only makes
          sense for SVG or CSS.
   Chris: Coordination is good now, let's not put it at risk.
   Simon: Combined spec has a lot on 3d now.
   Tab: So we say we cannot change transforms 2d anymore, we rejected that
        argument this morning, what is different?
   Peter: What is going to change, the syntax or the functionality?
   Peter: Argument is that 2d transform has both fixed now, other specs not.
   Sylvain: Not sure we are as ready to publish 2d as we thought. We are
            thinking of some new functionality already.
   Sylvain: Stacking and fixed positioning issues.
   Tab: That is not syntax issue.
   David: Containing block.
   David: Have to walk through the subtree looking for fixedpos elements
   Vincent: We decided I think to merge, we need to discuss with FX group.
   Peter: Yes, but we made the caveat that we shouldn't delay CR.
   Sylvain: We can prioritize 2d.
   Peter: Real-world need for 2d.
   Chris: yes, but why did we make a merged spec since 9+ months, and now
          we are ignoring it.
   Chris: Can't we publish that spec?
   Vincent: Can we go over the issues first in the merged spec. Bringing 3d
            to SVG is another topic.
   Vincent: Then go over the list, and at least have one consistent model.
   Sylvain: Have a document by next ftf.
   Simon: Still the problem of dropping prefixes.
   Simon: I think we can drop prefixes early.
   Vincent: We should at least have a review of the issues, then we know if
            the issues are maybe minor.
   Simon:  syntax issues probably minor.
   Simon: Transform origin is harder.
   Chris: Not clear that SVG is holding that up.
   Simon: Should a test suite have SVG tests, and should UAs pass SVG before
          the spec can advance?
   David: A spec is not free. The spec is not done. It is holding things up,
          I think.
   Chris: A UA can implement only CSS or only SVG.
   Simon: Conformance classes. Four: {2d,3d}x{CSS,SVG}
   Chris: SVG has had transforms since 1998, we aren't starting from scratch.
   Chris: Mixing HTML and SVG and CSS is not rare, it is being used more and more.
   Peter: What is the path forward?
   Vincent: I like to have time to go over the issues with the W. There is not
            really SVG vs CSS. And we do't want two solutions in the end.
   Vincent: Dirk is working fulltime on transforms, listing the issues and
            looking at implementations
   Vincent: We have them on a wiki, we can discuss them in two weeks.
   Vincent: Would be good to understand first what the implications are.
   Vincent: I propose we look at the issues at the telcon.
   Simon: wiki or bugzilla?
   Vincent: wiki
   Simon: Move to bugzilla?
   Vincent: I think everything is there already, the wiki is to support.

   fantasai: So we have two unmaintained specs and one merged spec that is
   Simon: Yes?
   fantasai: Are all issues in the issues list?
   Vincent: Yes, should be.
   fantasai: How many? How long would going through them take?
   Vincent: 2d issues are tractable, 3d issues are bigger, more uncertain
   Simon: 48 issues, about 1/3 are 2d.
   fantasai: In general, we just cut unstable features and continue the rest.
   fantasai: Seems to me we should cut 3d, and make that the next level of
             the module.
   Simon: That doesn't help with dropping prefixes, some properties are shared
          in 2d and 3d.
   Simon: Although might not be so bad in practice to have prefixed 3d functions...
   Simon: Unprefixed property would accept only 2d functions, prefixed property
          would accept 2d and 3d both.
   Simon: Potential breakage, but risk is fairly low.
   Simon: Need input from other implementers.
   Vincent: We can go over 2d issues, and establish at least the status of the
            3d ones. Then make decision in a month.
   Sylvain: I'd rather go through whole list of issues first.
   Vincent: Dirk will categorize issues.

fantasai: We didn't talk about Text. We have an issue on text-transform,
           but are there any others that would prevent a LC?
John: There are a couple on text-transform alone.
Steve: I don't know, I haven't looked yet.

Received on Monday, 13 February 2012 17:37:57 UTC