- 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