- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Nov 2010 15:43:59 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Grids
-----
Microsoft presented another layout proposal that deals with grids.
There is a lot of overlap with Template.
CSS3 Writing Modes
------------------
- Aharon and fantasai explained the new 'isolate' and 'plaintext' values
for 'unicode-bidi', what use cases they solve, and how they interact
with HTML5's bidi features.
- fantasai explained the new 'writing-mode' property and its relationship
to SVG; why it does not set the 'direction' property, and why the value
names were changed
- RESOLVED: remove the horizontal-bt value of 'writing-mode'
- Briefly reviewed 'text-orientation' property.
- Discussed tate-chu-yoko feature requirements.
====== Full minutes below =====
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett
Beth Dakin
Elika J. Etemad
Sylvain Galineau
Daniel Glazman
John Jansen
Richard Ishida
Koji Ishii
Håkon Wium Lie
Peter Linss
Markus Mielke
Alex Mogilevsky
Ilkka Oksanen
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/11/02-CSS-irc
<RRSAgent> http://www.w3.org/2010/11/02-CSS-minutes.html
Scribe: jdaggett
Grids
-----
+Phil Cupp on the phone from MSFT
<mmielke> http://www.interoperabilitybridges.com/css3-grid-align/
alex: need some good 2d layout mechanism in css
alex: need for ui apps not just free-flowing text
alex: several proposals for grids/table like layout
alex: looked at requirements first
alex: we like our proposal
alex: how does this relate to previous proposals?
alex: this proposal is based on xul, wpf-grid, probably closest to wpf-grid
alex: but uses flex box like elements (?)
alex: make sense?
alex: let's go over the spec
alex: grid works by defining grid lines
alex: layout using row, column coords and how many columns it overlaps
alex: grid sizes to content
alex: works for both fixed/float cases
alex: define using
alex: display: grid | inline-grid
alex: grid-column, grid-row with value to define grid
alex: (looking at ex 2)
dbaron: what are the values of grid-columns, grid-rows?
alex explains syntax
* fantasai is having a hard time understanding why this is better than
Template
markus: values are from template spec
alex: columns, rows can overlap
alex: lots of interesting overlap cases
alex: for example, equivalent of xul stack layout with single slot w/
multiple items stretching to largest
jdaggett: does this have features that template doesn't support?
alex: overlapping elements
bert: also, this allows you to automatically grows grid with content
bert: I explicitly left that out of Template to keep it simple
sylvain: yeah, if you add content at 5,5 to a 3,3 grid it grows automatically
alex: useful for sparse grids, or grids where order can change
markus: no-brainer if know tables
alex: no ascii art
jdaggett mourns this
* mollydotcom mourns no ascii art too
* TabAtkins too!
bert: syntax question, many ways to express concept
* TabAtkins suggested a way to still mix-in ascii layouts that mesh well
with the rest of Grid.
fantasai: snap to grid functionality?
alex: not yet, every item is explicitly placed
fantasai: not a fan of positioning aspect
fantasai: but a flex box layout aligned to grid would be powerful
fantasai: using flexbox or template to align would not break with reflow
<glazou> glazou 'grid-cell: 'selector'' can be added afterwards
* mollydotcom agrees with fantasai - the positioning isn't design-intuitive
but a flexbox aligned to grid would make designers drool
with happiness. Snap to grid would do so as well.
<fantasai> mollydotcom, exacty. I think flexbox or template + snap-to-grid
would be great
<fantasai> It seems to me easier to use, and less likely to break with
reflow effects (window resizing, font resizing, changing
content, etc.)
peter: typically grids are defined by lines not cells
peter: and align to line, not cell
jdaggett: didn't you propose grid positioning with grid lines?
alex: no real contradiction between the two
alex: we didn't want to combine the two
peter: I want to align to a gridline. And I'd probably want to align
to a named gridline, so I can insert other grid lines later
and not have it move
alex: could have circular dependencies
alex: i would to see both
alex: but don't want to spend the whole time resolving dependencies
alex: can do the same with this as with gridlines
jdaggett: Graphic design books that talk about grids, was more along
what Peter was saying
jdaggett: This model you're going to have to do extra work to define that
markus: two core use cases
markus: 1. print design layouts
markus: 2. app layouts
markus: this is more for (2)
alex: grids in print don't deal with resizing issues
alex: much better to have some that are fixed, some that flex
alex: when grid is sized by content is actually more useful but doesn't
cover all scenarios
stevez: symbolic identification
stevez: names to cells?
fantasai: that's what template does
alex: we have started with minimal feature set
peter: i don't want to name cell, i want to name lines
peter: if a grid row/line is added in the middle, the grid shrinks
peter: i want to span from one gridline to another
peter: even if lines are added in between
peter: could be dynamic or for additive layout
peter: like in the case when you just want to add a logo to a layout
pcupp: we thought about a pseudo-element that spans cells (?)
pcupp: the cell defines a region for content to be laid out
<Bert> (Maybe Peter is thinking of something like: 'grid-columns: a=0%,
b=75%, c=50%' and then 'grid-column: c'?)
pcupp: maybe it's aligned, maybe it stretches
pcupp talking about an example...
markus: just a slightly different use case
alex: can it be used as gridlines? no, not just with this
alex: but we want to have some form of gridline like capability
sylvain: i think we need to capture peter's use case
sylvain: of inserting new gridlines
peter: this defines cells but i don't think we need another way of
defining cells
alex: this is about grid alignment of cells
alex: obviously we can take it further
peter: I understand this gives some more capabilities that template
doesn't have, but let's improve template and use this module
to do something different
peter: give me the ability to name a gridline
peter: so that i can say "this thing goes in a box that goes between
these gridlines"
peter: this way i can define my cells arbitrarily
peter: rows/columns we already have, if we're adding something, let's
add something new
daniel: peter's proposal is not far away from my proposal to define
layout with respect to other elements
murmurs of disagreement
<dbaron> I think this is pretty different, since this contains things
properly so things won't overlap.
<glazou> dbaron: : no overlap ?
continuing through spec
* mollydotcom it is something that must be worked out. Grids/lines is
a very familiar paradigm in design. And as Peter points
out, we have rows and columns already
* Bert thinks the problem is that layout may be the missing piece, but
everybody defines layout differently...
* mollydotcom adds that the medium often defines layout limitations too,
screen v. handheld, etc.
alex: there is a property that controls the order of rendering
alex: to deal with overlapping elements
alex: not super important
(section 8 of spec)
peter: what if you just use z-index?
alex: we can discuss that
peter: i don't see the difference
alex mumbles...
and smiles
daniel: i'm considering working on peter's proposals
daniel: i have a few ideas about this
howcome: use cases would be interesting
howcome: for comparison
daniel: i'll work on the ideas, then the use cases if i have time
stevez: there were previous proposals for...
stevez: a two-column layout with a figure in the middle
stevez: there's an issue with how to overlay
howcome: that's in gcpm!!
howcome: but this is app centric, not document centric
peter: lots of use cases for document centric uses
daniel: this is really about app centric use
alex: concurs
stevez: i'm dazed and confused
* fantasai notes that flexbox was intended to solve the app-centric
layout model
<fantasai> I believe template + flex could do most of these layouts,
aside from the overlapping ones
stevez: i thought you were tailoring the syntax for one use
markus: there's an aspect....
* glazou said he's accepting an action item to work on a new proposal
more line-centric
pcupp: we think it's the common case where controls are composed using this
section 2.4, figure 6
picture of a slider
because the world needs more sliders...
alex: what can we do with this? new module? merge with another?
bert: seems close to flex box
tab mumbles
bert: i have a number of comments
bert: when you put two elements in the grid they overlap, they don't add
bert: might be good or bad
markus: you need it as in the slider example
tab: this example is also nice for being able to overlap
<szilles> +1 for tab's comment
bert: what's the intrinsic size in this case?
<fantasai> <slider style="display: flexbox">
<lower-fill style="flex: 0.5"/>
<thumb style="position: absolute; width: 2N; left: -N">
<upper-fill style="flex: 0.5"/>
</slider> ?
alex: multiple items in cell all affect sizing
tab: I provided an example in my response to the grid-align thread
where it was useful to be able to position multiple items in
one cell and have them flow together, rather than overlap.
However, overlapping is *also* useful.
bert: don't like three props, why not one
alex: yeah but that would be a long line
alex: well you don't need to specify predefined size
bert: wondering float and position
alex: works just like flex box
<dbaron> I'd prefer not to put complicated syntax inside values of 'display'.
* fantasai too
alex: float ignored, position with regards to nearest positioned element
tab says something i don't understand
alex: position might also work the same way but not affect sizing
tab: in my position layout proposal, i came up with a good model for
positioning in new layout proposals
<dbaron> I think alex said there are two options for position: absolute;
the normal way (placeholder, etc.) or position according to
grid rows/columns but not affect sizes of the grid rows/columns.
Tab: In my Positioned Layout proposal I specified a consistent and easy
way to make positioning interact with other layout modes.
Tab: The positioned element leaves behind a placeholder element.
TabAtkins: You could then use the grid properties to position the
placeholder, which would affect the 'auto' position of the
abspos box (what it means for "top:auto", etc.)
alex: the way to think about absolute positioning
alex: with a grid it's obvious where it's positioned
alex and bert discuss this
bert: difference between grid-row and grid-rows is just one letter
bert: same for columns
syntax discussion
bert: for flex box the content is in a given order
bert: with this proposal the source order doesn't affect the order in
the grid
alex: one possible extension is auto-incrementing rows/columns
alex: this is closer to xul grid
dbaron: also auto-incrementing row-groups/column-groups
<dbaron> and you could allow them to take grid-row/grid-column (or lines)
and not start at the top-left
bert: the idea that you auto-create the table based on a single cell
bert: but you can't catch errors in your design
bert: because it's not based on explicitly named entities
alex: either way you need to define a protocol here
bert: i'm not sure plus/minus but it does mask errors
bert: you don't allow % in cell size
alex: could be added
tab: what exactly do you want to base the % on
tab: you need to explain which the % is based one
dbaron: i was thinking of someone designing a page
dbaron: with embedded grids with constraints between elements
dbaron: with this proposal you would use nested grids
<Kai> +1 to David's proposal
dbaron: are there cases where nested grids need to line up with ...
outer grid lines
peter: this is why named gridlines are handy
<Bert> (DBaron wants something like constraints on the columns widths:
a = b = c, d = e, sum(a.e) = parent, but not relation between
a,b,c on one hand and d,e on other...)
pcupp: so you're talking about how to line up nested grids with outer grid
pcupp: with unioned gridlines, spanning behavior becomes hard to predict
pcupp: things tend to grow in unpredictable ways
<fantasai> dbaron's drawing:
<fantasai> +--------------+
<fantasai> | |
<fantasai> | +--+--+
<fantasai> | | | |
<fantasai> +--+--+--+--+--+
<fantasai> | | | | |
<fantasai> +--+--+--+ |
<fantasai> | |
<fantasai> +--------------+
bert: also, you can't put something in your cousin grids, only grids
within single tree
bert: just a remark
bert: this is hard
bert: cesar found examples where this might be handy
stevez: why is that a good thing?
bert and steve discuss trees and cousins
stevez: similar to separating template from content
bert: you can select different grids from screen size
bert: you can use the body element to hook your grid on
bert: those are my comments
fantasai: you might also want named grids
fantasai: main and secondary
fantasai: but maybe i don't totally understand
<Bert> (Something like: 'grid-column: a.1' for column 1 in grid a?)
alex: we would like to make this an editor's draft
alex: what else do we need to get there?
alex: we can make changes to deal with use cases and functionality discussed
stevez: how many table-like layout mechanisms do we need?
markus: you need a variety
markus: you need abosolute positioning, flex box, grid
* fantasai wonders if xul has abspos
markus: each solves a different use case
pcupp: overlap in grid / flexbox use
pcupp: they're complimentary
peter: this is a 2d flexbox
stevez: there are comonalities
stevez: declaring size constraints
stevez: concerned about complexity
markus: in the end it all makes sense
markus: app vs. doc roles
tab: steve, your concern is that we get too much complexity?
stevez: it's that we have a lot of ways of defining cellsize
stevez: are the pieces the same across all three sizes?
* Bert wonders if we should have not just a CSS Beijing, with the stable
features for typography, but also a CSS Lyon, with the stable
features for GUIs. Maybe few UAs need to do both...
tab: you can express everything in one master model
tab: different uses require different layout models
tab: layout models interact in orthogonal ways
* glazou thinks we spend far too much time on specs that don't provide
new technical stuff and does not want another "snapshot" for
every ftf
tab: make each as easy as possible
stevez: i'm ok with that but i want to make sure that concepts carry
across the models
stevez: the base primitives need to be consistent
tab: yes, you want primitives to work across layout models (?)
howcome: healthy competition across modules is good
howcome: this model and template don't make sense together
* Kai is concerned about authors being able to distinguish between the
various modules and starting to mix and match, perhaps creating
problems down the road
stevez: is there an action item for bert/alex to combine these ideas
bert: future ideas, non-rectangular cells, chained cells
howcome: and across pages
bert: so the question is how these concepts fit with that
peter: grids that flow across pages or grids that repeat
peter: can we use the same syntax for both
markus: need to be careful about use cases
markus: if combination is complex, life sucks for everyone
peter: one problem is that you're calling this a grid
peter: it's not really a grid
stevez talking about the beauty of xsl
markus: need to solve both print-like and app use cases
markus: two action items, alex/bert to kibbitz
markus: and talk with daniel about his ideas
peter: may end up with 90% overlap
stevez: could be true, punchout or overlay, small set of props captures both
stevez: a model for both is important
stevez: no problem if app is favored, since docs are harder
peter: i just want us to be thinking about this
markus: yeah, maybe grid is not the best name here
fantasai: grid-columns and grid-rows are common to both grid specs?
alex: yeah, we have to merge or redefine
discussion of what to do with the document
daniel: grids are already in the charter
stevez: not sure this is FPWD ready
stevez: we should do some vetting
daniel: don't need to name it now
markus: first agree on what's in these specs
<br type="coffee"/>
ScribeNick: TabAtkins
CSS3 Writing Modes
------------------
<sylvaing> http://dev.w3.org/csswg/css3-writing-modes/
fantasai reviews the draft from the top down. See
http://dev.w3.org/cvsweb/~checkout~/csswg/css3-writing-modes/Overview.html?rev=1.37&content-type=text/html;%20charset=iso-8859-1
BIDIRECTIONALITY
fantasai: In the draft, I define some terms and drew some pictures.
howcome: I suggest simplifying the terms to 'inline direction' and
'block direction', not '* flow directionality'.
szilles: I think "directionality" is a hard word for non-English speakers.
fantasai: Okay, don't have an opinion much.
[Aharon later suggests "inline base direction"]
fantasai: Most of the bidi text here is just copied from css 2.1.
<sylvaing> section 3.2. title typo: 'uncode-bidi'
dbaron: Could we have an additional set of parens on the unicode-bidi
property, so we don't have to rely on knowing the relative
strength of the opeerators?
fantasai: yep
fantasai: 'isolate' is a new unicode-bidi value, proposed by the bidi
for html group.
fantasai: That prevents strings that have a different directionality
from having an effect on the text around them.
fantasai: There's also a plaintext value, which is intended to use the
unicode bidi algorithm's plaintext heuristic to determine the
bidi direction of each paragraph.
fantasai: This does *not* affect the direction property, it just affects
bidi resolution.
aharon: Should I give use-cases for 'isolate' and 'plaintext'?
szilles: Would be helpful.
<dbaron> http://www.w3.org/TR/2010/WD-html-bidi-20100304/ has some use
cases for these new features, no?
aharon: 'isolate' is useful in the context of a webapp that is inserting
data into a page.
aharon: Frex, I'm displaying search results, and the title of the results
are outside data and may not be in the same language as the rest
of the UI.
aharon: If you don't isolate the titles, it quite often interacts with
the stuff around it, such as numbers and other neutral characters.
aharon: Outside of an app, it's useful for quotes and links - I can't
imagine why you'd want a link to be broken up into two parts due
to its directionality interacting oddly with the surrounding content.
fantasai: It drastically reduces the number of LRM/RLM you have to use.
aharon: Side thought - I think instead of "inline direction", use
"inline base direction".
aharon: The base direction is controlled by the 'direction' property.
aharon: There are a couple of problems. You might not know what the
direction is - it could be outside data.
aharon: It is very useful to let the UA guess what the direction is using
standard algos based on the characters in the data.
aharon: There is a separate proposal in HTML for @dir=auto
aharon: That's not precisely what we have here in 'plaintext'.
aharon: The UA, in HTML, sees dir=auto, looks at the content, decides
whether the direction is rtl or ltr, then sets the CSS 'direction'
appropriately.
aharon: That's good, but doesn't go quite far enough.
aharon: Let's say I have a textarea - plaintext - that the user is typing
into.
aharon: Is it fairly useful to have some paragraphs in one language and
some paragraphs in another language. Frex, I'm typing in a
restaurant review in Hebrew.
aharon: I give the review in Hebrew, then say "the address is:..." and
give it in French because the restaurant is in Lyon. If I don't
switch the direction of the paragraph, the number at the start
of the address will go on the wrong side.
aharon: So you want the ability to have paragraphs that go in different
directions.
aharon: If you're doing markup, that's great - you can just make separate
paragraphs.
aharon: If you're just typing into a textarea, though, you can't do that.
aharon: The unicode bidi algorithm defines a simple way to define the
directionality of each paragraph (where "paragraph" is defined
by the bidi algorithm).
aharon: So 'plaintext' would say that the textarea isn't necessarily ltr
or rtl, it's plaintext where each paragraph can go either way.
aharon: It's still not limited to textarea, of course - often after
taking the data from a textarea you want to then display it.
aharon: So you want to still be able to apply this same directionality
algorithm to the results outside of a textarea.
aharon: You can't hide the directionality determination from CSS with
dir=auto here, because the different paragraphs aren't marked
up as explicit elements.
dbaron: [question about which characters serve as paragraph separators]
aharon: The unicode algorithm is very precise about which characters are
paragraph separators. In the past, some browsers didn't follow
that exactly, which is basically a bug.
Bert: What's the difference between 'embed' and 'isolate'?
aharon: 'embed' says "this element has a base direction", but that
doesn't prevent the element from affecting stuff outside of it.
aharon: So, if I have an english paragraph, but in the middle is an
arabic word and then an embed of a separate element which is
explicitly rtl.
aharon: The unicode algorithm says that the arabic and the rtl are
merged together and will both flow rtl together.
aharon: You don't want this - logically, the arabic and the embed are
separate, and shouldn't stick together.
Bert: So inside, 'embed' and 'isolate' are the same. They're different
outside?
aharon: Yes.
howcome: It seems that you need to explicitly set all block-level
elements to 'isolate'?
dbaron: That should be in the default stylesheet.
aharon: You don't necessarily need it. It's just that if you have a
block-level element and you use CSS to make it display inline,
you really want it to still be isolated.
aharon: Right now HTML5 effectively says that all block-level elements
should be 'embed'; we just changed it to 'isolate', which is
closer to the intent.
aharon: As to making a block inline, one example is an inline list.
If some of those values are opposite direction, it's important
to have isolation apply to them.
howcome: So, can we in any way hinge this behavior on the existing
CSS display?
fantasai: If the display is anything other than inline, you already
*effectively* have the isolate value.
fantasai: The problem is just that when you change the display value
to inline, there's no CSS distinction to tell us that this
*used* to be a block-level, so you need 'isolate' there.
* kennyluck http://dev.w3.org/csswg/css3-writing-modes/#bidi-html looks relevant
TabAtkins: You can in the UA stylesheet just set all the block elements
to 'isolate', so the author doesn't have to think about it.
howcome: But you have to remember to set 'isolate' in new XML languages.
TabAtkins: Yes.
Bert: Does this cover all known cases?
fantasai: This covers all of CSS2.1 + all of the proposals from the
bidi subgroup for i18n.
VERTICAL TEXT
fantasai: Now, 'writing-mode'.
fantasai: The previous writing-mode property was a shorthand for
block-flow-direction and 'direction'.
fantasai: One of the things I was tasked with was to sync with SVG,
which is very explicit that the writing-mode and direction
property don't interact.
fantasai: The SVG spec has these valuees (lr, lr-tb, rl, tb, tb-rl)
fantasai: I could figure out what the 'rl' value was and how it
differs from 'lr'.
fantasai: The SVG spec says you do bidi reordering, then use
writing-mode to change the inline progression direction.
fantasai: Which is left to right in 'lr' - this is *after* bidi
reordering, in visual order.
fantasai: As far as I can tell, 'rl' should maybe just mean reverse
the text, but I only found one impl that does that.
fantasai: So, I just mapped both of them to the same thing -
'horizontal-tb'.
fantasai: So now, in CSS, the 'direction' and 'writing-mode' are
distinct. You first do bidi reordering, then 'writing-mode'
just defines the axis to use.
fantasai: I thought that saying 'lr' was confusing, since it doesn't
have anything to do with ltr text, so I called the value
"horizontal-tb".
shepazu: The reason SVG does it the way it does, is because XSL did
it that way.
fantasai: I don't have any objection to the way SVG did it. I don't
think it's good for authors to be using a property that
resets all the bidi in the document just to get vertical text.
sylvaing: Is there content out there using 'writing-mode:lr-tb'?
fantasai: Yes, but it's not relying on the direction-reset stuff.
fantasai: I think the number of people who are mixing rtl with
vertical text right now is basically ignorable, though I
suspect it will increase as we support this.
shepazu: Let's say I have a table in HTML, and I want a header going
down the side, with english vertical text...
fantasai: That's addressed by other stuff in the draft.
fantasai: So, with 'writing-mode', the first value gives you the line
axis, the second gives you the block-flow. "horizontal-tb",
and "vertical-lr".
fantasai: [I missed the line about mongolian]
jdaggett: I don't understand why we need horizontal-bt.
fantasai: I did it because MS implemented it.
alexmog: Mainly for completeness.
jdaggett: I don't understand completeness.
alexmog: It's simple and obvious what it means. There aren't large
use-cases, but it takes a very minimal impl cost.
jdaggett: Agreed that it's a minimal cost, but I still don't think
that we should have random property values. Someone still
has to test that.
jdaggett: Frex, this can affect what PgUp/PgDn mean, which means
manual testing.
fantasai: I completely abstain from this.
shepazu: Are there any scripts that have used it?
[maybe some archaic scripts, but not commonly]
howcome: I don't think we need to try for complete here.
howcome: What does it mean in a paged medium?
* dbaron wonders what direction the writing in
http://maps.google.com/?ll=35.663524,139.763601&t=k&z=21 is
[chatter about pagination]
fantasai: You paginate up.
shepazu: Small but serious use-case:
shepazu: There are efforts now to go back to ancient texts and transcribe
them in some format. There are people who want to represent
dead languages.
jdaggett: I think we can remove it for now, and then put it back if
someone has a language that needs it.
dbaron: I don't think it's minimal cost, because dealing with
overflow/scrollable region handling, you'll need to test
initial scroll position being at the bottom, etc.
alexmog: We've already defined 6 of the 8 possible directions, which
already bring up the issues you mention. Is it additional
burden to add the last two?
plinss: Can we mark it as optional?
jdaggett: It's either in the test suite or not.
plinss: We can spend as much time debating it as it would take to
implement it.
fantasai: I don't care what we do. I just want to resolve.
* sylvaing resolved: moved to gcpm!
RESOLVED: remove the horizontal-bt property.
Bert: The name is fine, but I think that 'writing-mode' in XSL does
influence the direction, so there's a difference there.
fantasai: The disconnect between XSL-FO and SVG/CSS has existed since
SVG 1. I don't think bringing up the incompatibility is
useful, since the incompat already exists in SVG, so you'll
have to support it anyway.
jdaggett: I don't know why XSL compat is an issue.
szilles: SVG needs to work in both XSL and CSS.
fantasai: SVG is already incompatible with XSL.
Bert: I thought that SVG copied from XSL.
fantasai: They must have copied badly here, then.
shepazu: I don't know if there's a lot of existing content, but I think
in general the SVGWG is okay with changing behavior to match
the CSS model, as long as it doesn't break existing content.
Bert: I'd like to be able to use CSS and XSL together.
shepazu: There is a japanese SVG interest group, so they'll look at the
issue.
fantasai: Next interesting bit is text-orientation.
fantasai: szilles and Paul Nelson and I worked out these values a long
time ago.
fantasai: The default is "vertical-right", because that's the natural
orientation for vertical scripts, our main use case.
jdaggett: The Latin-1 version of the latin alphabet and the fullwidth
version usually act differently in vertical text, and this
is captured in opentype.
fantasai: The spec should indeed specify that, if it doesn't already.
jdaggett: We probably want to be explicit about the interaction with
opentype, or refer to the spec.
fantasai: I'll need help with that, because I have no clue about OT.
jdaggett: You use the term "grapheme clusters", which I think won't be
underestood by most people.
ishida: Sometimes grapheme clusters aren't sufficient in indic scripts.
fantasai: Is that captured in the "extended grapheme cluster" definition?
ishida: No. You either need a new definition, or need to punt it to the UAs.
fantasai: Let's mark that as an issue. It's the same problem we have
with first-letter, so we need to fix it the same way.
Bert: Could we call the default 'normal' or 'auto'?
howcome: I don't understand what you mean by "not native writing mode".
fantasai: horizontal script in a vertical orientation is "non-native",
and vice versa.
Bert: The default value is the normal way that english is embedded in
japanese, so it should have a simple name.
ishida: Not always normal - acronyms are often not rotated.
fantasai: Those are usually done with fullwidth glyphs, which do their
rotation correctly.
fantasai: Compat with SVG; we're not using glyph-orientation.
fantasai: It doesn't handle anything except the most common cases.
I recommend we not go into the precise details.
fantasai: The interaction between text-orientation and glyph-orientation
is well-defined, though - text-orientation will by default
defer to glyph-orientation in a UA that implements both.
<fantasai> Note to self: make auto value default value for everyone -- maps
to vertical-right for impl that don't support glyph-orientation
fantasai: Now, text-combine.
fantasai: It can be used for an effect called "tate-chu-yoko". It's
different from just doing an inline-block, because the combination
is treated like a single glyph.
jdaggett: I think that since this is a vertical-only property, maybe the
name should reflect that.
jdaggett: Also we can probably drop the 'cluster' property.
ishida: You can have kumimoji (sp?) in horizontal text too.
jdaggett: You can either do that as direct codepoints, or many fonts have
ligatures for those, which are different for vertical vs
horizontal and will do the right thing.
jdaggett: I just don't think we want the UAs to synthesize these. A font
will have something that looks nice with the text surrounding it.
ishida: Then there's warichu (sp?). Are you discounting that?
jdaggett: That's a known hard problem. Not currently addressed by this draft.
<dbaron> http://www.w3.org/International/articles/css3-text/#Slide0190
has pictures of kumimoji and warichu
szilles: I think what's being proposed is that the 'cluster' should be
split out, because it's a different thing from tate-chu-yoko.
jdaggett: Also, some people from the japanese TF came back and said that
it's not really good typography to do this.
ishida: It makes some sense to me to not bundle it with the tate-chu-yoko.
jdaggett: For tate-chu-yoko, some authors may only want to do this style
(2-characters only), but newspapers will sometimes use third-width
or quarter-width glyphs (for things like years).
jdaggett: It would be nice to say "I want tate-chu-yoko for 2-character
runs, but not 3 or more". So maybe a number in the property.
jdaggett: Fallback behavior - I think I said behavior that quarter-width
falls back to third-width, falls back to half-width, falls back
to full-width. I think instead if one doesn't exist it should
scale.
fantasai: Or just have it overflow.
szilles: I think if you had a year that was expeected to be a single line,
splitting it into two segments would be confusing.
jdaggett: Right.
szilles: Also, tate-chu-yoko is sometimes done with letters, for acronyms
like "IBM".
jdaggett: Unfortunately, fonts have quarter-width numbers much more
commonly than letters.
ishida: Perhaps we should ask the Japanese here in our group what they
think.
dbaron: Also, is falling back to scaling better than falling back to no
tate-chu-yoko at all?
<br type="lunch"/>
Received on Tuesday, 16 November 2010 23:44:35 UTC