- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 13 Feb 2012 18:37:29 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Writing Modes
-------------
Discussion of UTR50 status and 'text-orientation' property.
Fragmentation
-------------
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.
Transforms
----------
- 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
behavior.
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
property.
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
vertical.
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
Fragmentation
-------------
<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
explanations.
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
spec.
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:
http://lists.w3.org/Archives/Public/www-archive/2012Feb/0012.html
Tranforms
---------
<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 |
matrix(a,b,c,d,e,f)
translate(5px, 10px)
matrix(1,0,1,1,5,10)
^ ^^ ~ 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
'transform'?
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
maintained?
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.
ADJOURNED.
Received on Monday, 13 February 2012 17:37:57 UTC