CSS fatf @ TPAC -- 02 Nov 2010

<glazou> ScribeNick: jdaggett

<glazou> Meeting: CSS ftf @TPAC

grids

phil cupp on the phone from ms

<mmielke> http://www.interoperabilitybridges.com/css3-grid-align/

alex: need some good 2d layout mechanism in css
... need for ui apps not just free-flowing text
... several proposals for grids/table like layout
... looked at requirements first

<johnjan> eureka

alex: now back to the show
... we like our proposal
... how does this relate to previous proposals?
... this proposal is based on xul, wpf-grid, probably closest to wpf-grid
... but uses flex box like elements (?)
... make sense?
... let's go over the spec
... grid works by defining grid lines
... layout using row, column coords and how many columns it overlaps
... grid sizes to content
... works for both fixed/float cases
... define using
... display: grid | inline-grid
... grid-column, grid-row with value to define grid
... (looking at ex 2)

dbaron: what are the values of grid-columns, grid-rows?

alex explains syntax

present currently: elika, bert, håkon, peter, markus, tab, beth dakin, richard ishida, steve z, daniel, ms john, sylvain, koji, dbaron

markus: values are from template spec

alex: columns, rows can overlap
... lots of interesting overlap cases
... 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

<fantasai> 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

bert: syntax question, many ways to express concept

fantasai: snap to grid functionality?

alex: not yet, every item is explicitly placed

fantasai: not a fan of positioning aspect
... but a flex box layout aligned to grid woud be groovy

<glazou> glazou 'grid-cell: 'selector'' can be added afterwards

fantasai: using flexbox or template to align would not break with reflow

peter: typically grids are defined by lines not cells
... and align to line, not cell

<fantasai> mollydotcom, exacty. I think flexbox or template + snap-to-grid would be great

jdaggett: didn't you propose grid positioning with grid lines?

alex: no real contradiction between the two

<fantasai> mollydotcom, It seems to me easier to lose, and less likely to break with reflow effects (window resizing, font resizing, changing content, etc.)

alex: we didn't want to combine the two

<fantasai> peter: I want to align to a gridline. And I'd probably want to align to a named gridline, so I can insert arbitrary grid lines later and not have it move

alex: could have circular dependencies
... i would to see both
... but don't want to spend the whole time resolving dependencies
... can do the same with this as with gridlines

<fantasai> jdaggett: Graphic design books that talk about grids, was more along what Peter was saying

<fantasai> jdaggett: This model you're going to have to do extra work to define that

markus: two core use cases
... 1. print design layouts
... 2. app layouts
... this is more for (2)

alex: grids in print don't deal with resizing issues
... much better to have some that are fixed, some that flex
... when grid is sized by content is actually more useful but doesn't cover all scenarios

stevez: symbolic identification
... 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
... if a grid row/line is added in the middle, the grid shrinks
... i want to span from one gridline to another
... even if lines are added in between
... could be dynamic or for additive layout
... like in the case when you just want to add a logo to a layout

<anne> Bert, files are in http://dev.w3.org/cvsweb/csswg/css-device-adapt/ but not in http://dev.w3.org/csswg/css-device-adapt/ ?

pcupp: we thought about a pseudo-element that spans cells (?)
... 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
... but we want to have some form of gridline like capability

sylvain: i think we need to capture peter's use case
... 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

<fantasai> 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

alex: obviously we can take it further

peter: give me the ability to name a gridline
... so that i can say "this thing goes in a box that goes between these gridlines"
... this way i can define my cells arbitrarily
... rows/columns we already have, i want new toys

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.

continuing through spec

<glazou> dbaron: : no verlap ?

alex: there is a property that controls the order of rendering
... to deal with overlapping elements
... 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
... i have a few ideas about this

howcome: use cases would be interesting
... for comparison

daniel: i'll work on the ideas, then the use cases if i have time

stevez: there were previous proposals for...
... a two-column layout with a figure in the middle
... there's an issue with how to overlay

howcome: that's in gcpm!!
... 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> I believe template + flex coudl 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....

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
... when you put two elements in the grid they overlap, they don't add
... 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

<TabAtkinsTPAC> 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
... 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'.

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.

argh, not following tab again...

alex: the way to think about absolute positioning
... with a grid it's obvious where it's positioned

<TabAtkinsTPAC> TabAtkinsTPAC: In my Positioned Layout proposal I specified a consistent and easy way to make positioning interact with other layout modes.

alex and bert discuss this

<TabAtkinsTPAC> TabAtkinsTPAC: The positioned element leaves behind a placeholder element.

bert: difference between grid-row and grid-rows is just one letter

same for columns

syntax discussion

<TabAtkinsTPAC> TabAtkinsTPAC: 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.)

bert: for flex box the content is in a given order
... with this proposal the source order doesn't affect the order in the grid

alex: one possible extension is auto-incrementing rows/columns
... 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
... but you can't catch errors in your design
... 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
... you don't allow % in cell size

alex: could be added

tab: what exactly do you want to base the % on
... you need to explain which the % is based one

dbaron: i was thinking of someone designing a page

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 ...

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
... with unioned gridlines, spanning behavior becomes hard to predict
... things tend to grow in unpredictable ways

<fantasai> dbaron's drawing:

<fantasai> +--------------+

<fantasai> | |

<fantasai> | +--+--+

<fantasai> | | | |

<fantasai> +--+--+--+--+--+

<fantasai> +--+--+--+ |

bert: also, you can't put something in your cousin grids, only grids within single tree

<fantasai> | |

<fantasai> +--------------+

ah, we do so need ascii art

bert: just a remark
... this is hard
... cesar found examples where this might be handy

stevez: why is that a good thing?

bert and steve discuss trees and kissing cousins

stevez: similar to separating template from content

bert: you can select different grids from screen size
... you can use the body element to hook your grid on
... those are my comments

fantasai: you might also want named grids
... main and secondary
... but maybe i don't totally understand

alex: we would like to make this an editor's draft

<Bert> (Something like: 'grid-column: a.1' for column 1 in grid a?)

alex: what else do we need to get there?
... 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
... you need abosolute positioning, flex box, grid
... each solves a different use case

pcupp: overlap in grid / flexbox use
... they're complimentary

peter: this is a 2d flexbox

stevez: there are comonalities
... declaring size constraints
... concerned about complexity

markus: in the end it all makes sense
... 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
... are the pieces the same across all three sizes?

tab: you can express everything in one master model
... different uses require different layout models
... layout models interact in orthogonal ways
... make each as easy as possible

stevez: i'm ok with that but i want to make sure that concepts carry across the models
... the base primitives need to be consistent

tab: yes, you want primitives to work across layout models (?)

howcome: healthy competition across modules is good
... this model and template don't make sense together

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
... can we use the same syntax for both

markus: need to be careful about use cases
... if combination is complex, life sucks for everyone

peter: one problem is that you're calling this a grid
... it's not really a grid

stevez talking about the beauty of xsl

markus: need to solve both print-like and app use cases
... two action items, alex/bert to kibbitz
... 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
... a model for both is important
... 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
... we should do some vetting

daniel: don't need to name it now

markus: first agree on what's in these specs

break for coffee and champagne

<TabAtkinsTPAC> ScribeNick: TabAtkinsTPAC

<sylvaing> http://dev.w3.org/csswg/css3-writing-modes/

Writing modes

<fantasai> http://dev.w3.org/csswg/css3-writing-modes/

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.
... 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: 'isolate' is a new unicode-bidi value, proposed by the bidi for html group.
... That prevents strings that have a different directionality from having an effect on the text around them.
... There's also a plaintext value, which is intended to use the unicode bidi algorithm to determine the bidi direction of each paragraph.
... 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.

aharon: 'isolate' is useful in the context of a webapp that is inserting data into a page.

<dbaron> http://www.w3.org/TR/2010/WD-html-bidi-20100304/ has some use cases for these new features, no?

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.
... If you don't isolate the titles, it quite often interacts with the stuff around it, such as numbers and other neutral characters.
... 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".
... The base direction is controlled by the 'direction' property.

<dbaron> aharon: Might be good to use the term "inline base direction" instead of "inline directionality"

<dbaron> (given the previous discussion about avoiding the term "inline directionality")

aharon: There are a couple of problems. You might not know what the direction is - it could be outside data.
... It is very useful to let the UA guess what the direction is using standard algos based on the characters in the data.
... There is a separate proposal in HTML for @dir=auto .
... That's not precisely what we have here in 'plaintext'.
... 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.
... That's good, but doesn't go quite far enough.
... Let's say I have a textarea - plaintext - that the user is typing into.
... 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.
... 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 (padding,*)-start of the address will go on the wrong side.
... So you want the ability to have paragraphs that go in different directions.
... If you're doing markup, that's great - you can just make separate paragraphs.
... If you're just typing into a textarea, though, you cant' do that.
... The unicode bidi algorithm defines a simple way to define the directionality of each paragraph (where "paragraph" is defined by the bidi algorithm).
... So 'plaintext' would say that the textarea isn't necessarily ltr or rtl, it's plaintext where each paragraph can go either way.
... It's still not limited to textarea, of course - often after taking the data from a textarea you want to then display it.
... So you want to still be able to apply this same directionality algorithm to the results outside of a textarea.
... 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.
... 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.
... The unicode algorithm says that the arabic and the rtl are merged together and will both flow rtl together.
... 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.
... Right now HTML5 effectively says that all block-level elements should be 'embed'; we just changed it to 'isolate', which is closer to the intenet.

arronei: 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.
... 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.

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.
... Now, 'writing-mode'.
... The previous writing-mode property was a shorthand for block-flow-direction and 'direction'.
... 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.
... The SVG spec has these valuees (lr, lr-tb, rl, tb, tb-rl)
... I could figure out what the 'rl' value was and how it differs from 'lr'.
... The SVG spec says you do bidi reordering, then use writing-mode to change the inline progression direction.
... Which is left to right in 'lr' - this is *after* bidi reordering, in visual ordere.
... As far as I can tell, 'rl' should maybe just mean reverse the text, but I only found one impl that does that.
... So, I just mapped both of them to the same thing - 'horizontal-tb'.
... 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.
... I thought that saying 'lr' was confusing, since it doesn't have any new properties to do with ltr text, so I called the value "horizontal-tb".

shepazu: The hreason 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.
... 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.
... So, with 'writing-mode', the first value gives you the line axis, the second gives you the block-flow. "horizontal-tb", and "vertical-lr".
... [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.
... 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.
... What does it mean in a paged medium?

[chatter about pagination]

fantasai: You paginate up.

shepazu: Small but serious use-case.
... 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 th 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 sp(padding,*)-end 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.

RESOLUTION: 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 lose CSS and XSL together.

shepazu: There is a japanese SVG interest group, so they'll look at the issue.

fantasai: Next interesting bit are text-orientation.
... szilles and XXX and I worked out these values a long time ago.
... The default is "vertical-right", because that's the natural orientation for vertical scripts.

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 actually specifies that.

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.

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.
... Compat with SVG; we're not using glyph-orientation.
... It doesn't well handle a lot of corner cases. I recommend we not going into the precise details.
... 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> Make auto value default value for everyone -- maps to vertical-right for impl that don't support glyph-orientation

fantasai: Now, text-combine.
... 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.
... 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.
... 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).
... 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.
... 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 bettere than falling back to no tate-chu-yoko at all?

<sylvaing> scribenick: sylvaing

fantasai starts reviewing section 7 of http://dev.w3.org/csswg/css3-writing-modes/

<dbaron> http://dev.w3.org/csswg/css3-writing-modes/

http://dev.w3.org/csswg/css3-writing-modes/#abstract-layout

fantasai: i could not come up with a use-case for making overflow-x and overflow-y absolute

dbaron: people could have an expectation of what x and y map to ?

fantasai: so y is the block direction and x is the line direction

<dbaron> transforms has translateX(), translateY(), skewX(), skewY()

jdaggett, dbaron: x and y are used for transforms and map to a physical concept

jdaggett: this is a really large change. the use-case is not clear to me.
... we are talking about transforming coordinate systems within the page

plinss: it doesn't mean a true coordinate transform. this is attempting to solve a specific problem.
... it's just keeping overflow-x instead of having overflow-line-progression-direction

dbaron: i think overflow-x and overflow-y horizontal and vertical (respectively)

<dbaron> ... and the spec should use the terms block-axis and inline-axis rather than redefining x-axis and y-axis

jdaggett: why does vertical text require these changes ?

szilles: this is similar to asking why we need both flexbox and layout. we think they are valuable because they fit to certain tasks. likewise, these might be useful in some cases for people who use vertical text. Murakami-san's showed that it helped with maintenance.

jdaggett: if you author content in both modes, yes
... this is still not related to vertical text

aharon: logical properties are not just related to vertical text, they also matter for bidi
... the use-case for logical properties - start, end - in bidi is not theoretical
... an application that needs to support UI in different languages currently needs to provide different stylesheets.
... they're the same stylesheets, one effectively generate from the other
... e.g. margin-left in this stylesheet becomes margin-right in the other

jdaggett: but is the stylesheet for vertical text really going to be a rotation of the western ltr stylesheet ? The design is not completely symmetrical e.g. controls may not rotate
... authors want to be able to describe what they'll do for this writing-mode vs. that other one.

fantasai: this is not about making every automatic; there will still be a lot of fine-tuning e.g. drop shadows might have to change side
... but this should get you 90%+ of what you need. for instance, for a book.

howcome: you do want to set different values. duplicating properties does not address the problem

dbaron: I think john is asking whether there is a use-case for having something that is vertical in one context and horizontal and another on the web. this is not about asking whether there is a use-case for vertical

fantasai: is sharing the stylesheet between ltr and rtl a valid use-case ?
... but if I want to do the same thing for my Japanese translation, it will not work ?

jdaggett: this is not at all the same typography. Japanese layout is not rotated english
... in the webkit UA stylesheet, the default margin for paragraphs is 1em 0px. that's not a valid default for vertical Japanese paragraphs

<fantasai> koji: Whether paragraphs are separated by 1em margin or no margin + indentation is not a vertical vs. horizontal cas

<fantasai> e

<fantasai> koji: If you talk about blockquote default stylesheet, you want the left and right margins to 2em in horizontal mode. But in vertical mode you want top and bottom margins

jdaggett: the claim that a UA stylesheet can be made to work as is by using logical properties is not true. that use-case is not addressed by logical properties
... a default for Latin text cannot be used as a default for Japanese text

r12a-nb: I thought the goal was to have the ability to move horizontal japanese to vertical japanese

<fantasai> fantasai: You're arguing that the default UA stylesheet, which specifies suboptimal layout for Japanese text whether in horizontal or vertical, must handle proper japanese layout in vertical

<fantasai> fantasai: but for horizontal layout it doesn't matter

r12a-nb: I find logical properties much easier to use in practice

jdaggett: the issues are: what do we need to support and change to do vertical text intelligently. then there are things that make it more convenient to write stylesheets. these things have been merged together
... retrofitting virtual properties in CSS is a large change.
... this doesn't address all the properties that may need to be affected

fantasai: it covers all the properties in CSS2.1

jdaggett: but what about CSS3 properties such as border-radius ? what about 2d transforms and their coordinate spaces ?
... I don't think any of this is required to support vertical text.

kojiishi: but what if Japanese users want to be able to change margin and padding logically ?

jdaggett: then let's see what we can do for margin and padding

szilles: the top and left are irrelevant to the task of laying out lines in blocks. I want to set properties on the beginning of the line, the end of the line, on the block etc.

<fantasai> jdaggett: I don't think we should do this in one fell swoop

<fantasai> jdaggett: I think we should add start and end keywords where needed e.g. in text-align

<fantasai> jdaggett: And then for margins and padding, we just add 'logical' keyword to the shorthands

<fantasai> jdaggett: and not deal with, e.g. border properties

kojiishi: so you're questioning the number of properties that should be logical ?

<fantasai> koji: So you are not against logical properties, you don't agree on the amount

jdaggett: I think having a logical keyword in a small set of relevant shorthands is enough

kojiishi: so you're not saying all margins should be physical

jdaggett: I don't have a problem with retrofitting logical into the margin shorthand

<fantasai> jdaggett: I think a logical keyword on the margin shorthand is sufficient

jdaggett: but we shouldn't try to make everything logical at once

discussion of Zakim's feelings follows

szilles: it was said that it was an expensive change. for instance, it's expensive in storage. but the alternative involves multiple stylesheets. i think the computational issue is a red herring

<fantasai> szilles refers to messages on the mailing list that discuss the perf impact

howcome: you're right, it's not a blocker. but it's expensive in other ways: for authors who get a lot of new properties
... adding a keyword to a shorthand, otoh, is reasonable
... likewise, we could have keywords for inside/outside for printing

szilles: so you are OK with the ability to specify certain values in a logical coordinate system

howcome: yes

<Aharon> +queue

r12n-ab asks for an example of the logical keyword

<johnjan> fantasai fights the flip chart

<myakura> margin: logical? <length>{1, 4}

the physical coordinate of the flip chart rotates in mid-air

<howcome> margin: script 1em 0px;

<howcome> margin: writing-mode 1em 0px;

<howcome> margin: beas 1em 0px; /* before-end-after-start */

flip chart now stands in vertical-rl

<howcome> margin: tobi 1em 0px; /* top-outside-bottom-inside */

jdaggett: so the logical keyword means that the shorthand values are slotted to top/right/bottom/left based on the writing-mode
... this proposal is not what is in the spec

szilles: the principal of logical direction has been accept

<timeless> s/accept/accepted/

(howls of protest)

jdaggett: not by doing this for so many properties

(more Mozilla people standing up to make their point)

<timeless> (references to Dave Hyatt and Webkit)

<fantasai> dbaron: hyatt implemented it quickly because webkit's architecture makes logical properties easy

<fantasai> s/architecture/style system architecture/

<timeless> s/easy/easy based on an assumption which is not required by any specification/

<dbaron> s/style system architecture/data structure for storage of declarations within declaration blocks/

<fantasai> koji: But what you're saying is that you accept the idea of logical space, just not of scoping it so widely

jdaggett agrees this is about scoping logical

aharon: I think the situation with CSS2.1 with padding-right, padding-left etc. also involves a lot of properties already. why not just have shorthands ?

jdaggett: I don't think we can remove properties

aharon: but we may be able to deprecate properties that are harmful to i18n.
... it's much easier to add logical than turning left to top etc
... in several of our rtl localization projects, we had to introduce a rule in the system to make sure 'left' and 'right' did not appear in our CSS templates
... we use start/end or absolute-left/absolute-right. 99% of the time, people mean start/end

<fantasai> s/99/95

<fantasai> koji agrees with aharon's assessment of physical vs. logical usage; same applies in horizontal vs. vertical

aharon: most of the time when authoring a document that needs to be used both ways, logical is very useful

fantasai: section 7 is split in multiple sections. 7.1. maps various parts of CSS21. No new values are introduced.
... the only section that introduces new values is for caption-side
... 7.3 is about HTML attributes; for replaced elements they're treated as absolute; on table elements these attributes are logical

<dbaron> I don't think we should make width and height attributes behave differently for different elements.

bert: some of the terms used are also defined in the Box Model module. we should look at any overlaps and synch up the two modules

fantasai: yes

(now addressing dbaron's point)

dbaron: I think it's going to be very confusing

szilles: the proposal is that for those elements the width and height attribute are interpreted per the writing mode of the element

fantasai: yes. the alternative is to ignore them

dbaron: I'd rather add new HTML attributes

szilles: see the other room

dbaron: width and height attributes on table should not be logical while physical everywhere else as well as CSS width and height being physical. we should be 100% physical

fantasai: section 8.1 http://dev.w3.org/csswg/css3-writing-modes/#logical-value

defines properties that do before/after/start/end

dbaron: note that caption-side already has 6 keywords

jdaggett: I think vertical-align might need to have different defaults in vertical vs. horizontal. I need to confirm that but it'd need to default to middle in vertical
... vertical-align:auto ?

howcome: I think adding new values is easier than adding properties

fantasai: http://dev.w3.org/csswg/css3-writing-modes/#logical-page

<timeless> http://en.wikipedia.org/wiki/Recto_and_verso

<timeless> The verso is the "back" side and the recto the "front" side of a leaf of paper in a bound item such as a book, broadsheet, or pamphlet. ...

<timeless> en.wikipedia.org/wiki/Recto_and_verso

fantasai: these have always been logical.
... the original proposal was even and odd but if you change the page countering and things get confusing.

howcome: I'm not sure we want to use the same stylesheet for an ltr book and an rtl book

(arronei agrees with howcome)

<timeless> s/arronei/aharon/

aharon: what about front and back ?

fantasai: that is usually interpreted as the first and last page

<johnjan> timeless: arronei pinged me

<johnjan> correct

<glazou> s/linen/lanin ?

howcome: I think it's too early to spec the printing part of this.

<glazou> g'luck arron ;-)

<timeless> [ a discussion of why 8.2 exists ]

fantasai: the goal for these sections was to cover all of CSS2.1

howcome: I don't think we should proceed until we understand spread layout

<timeless> [ the explanation for why 8.2 exists is because page-break-before/page-break-after exist, as clearly indicated in the first indented paragraph of 8.2 ]

<timeless> [ people explain how the binding side changes based on being LTR or TTB ]

<timeless> [ moving to 8.3 ]

<timeless> [ howcome is asked if he objects to logical-height ]

<timeless> [ howcome objects to adding anything ]

<Zakim> timeless, you wanted to ask what percentage of the problem needs to be solved

<timeless> [ i asked my question. jdaggett indicated he felt the proposal by fantasai, et al addressed 150% and he wanted something simpler which could be implemented and then we would later investigate what else needs to be added later ]

dbaron: the challenge of implementing the logical keyword is the number of pieces of information you need to cascade separately. so even though you have the same number of properties for the author , the implementation deals with 8 underlying properties

<dbaron> not really cascade, but store until you cascade

jdaggett: i'm not saying this solves all use-cases. but adding the logical keyword in those two places potentially covers a lot of use-cases.

fantasai: i'm fine with scoping it to margin and padding but if we add the logical keyword we should also add support for before/after/start/end

fantasai walks through an explanation of margin shorthand cascade and associated storage required...

margin: logical 1em 2em 3em 4em;

b e a s

<timeless> [ fantasai draws a paragraph ]

<timeless> margin-top: 5em;

p { margin: logical 1em 2em 3em 4em; margin-top: 5em; }

fantasai: if you don't store 8 values, margin-top would affect the physical right margin

discussion of how inside/outside is even more fun to implement

<fantasai> argument was that you only need to store 4 values plus a flag if you only implement the shorthand

<fantasai> dbaron pointed out that 8 values is necessary

<fantasai> to store

<fantasai> fantasai walked through an example so people would understand

<fantasai> p { b e a s

<fantasai> margin: logical 1em 2em 3em 4em;

<fantasai> margin-top: 5em;

<fantasai> }

<fantasai> 4em

<fantasai> +--------------+

<fantasai> +--------------+

<fantasai> 2em

jdaggett: i think just having a shorthand is intuitive for authors.

plinss: but you use functionality. you can't just specify the start

fantasai: I'm ok with just doing margin and padding for now. but i don't think the shorthands are sufficient

plinss: wouldn't you need to do border as well ?

fantasai: UA stylesheets only need margin and padding

<timeless> [ howcome suggests media queries ]

<timeless> scribe has noted that it's time for a break.

<timeless> the fact that people are talking locally instead of to the group supports this.

<myakura> RSSAgent, make minutes

<arron> 3From what I have gathered over IRC we have talked about these few options for logical properties:

<arron> 3a. leave everything as it is (all physical)

<arron> 3b. create actual logical properties for all relevant cases

<arron> 3c. alter only the shorthand properties to take additional keyword(s)

<arron> 3d. create a small set of logical properties covering only a small set of cases

<arron> 3 d.1. create only margin/padding-(start, end, before, after)

<arron> 3 d.2. create only properties that do not take <length> as a value (e.g. border-*-color)

<arron> 3There might be a few others that I missed from the conversation but I think this covers the scenarios that have been discussed.

<arron> 3I am not saying that we should vote on these but I think we should really look at each one of these further and see the pros/cons of each. I am still not convinced that we all know the design/author side of these type of changes.

<TabAtkinsTPAC> ScribeNick: TabAtkinsTPAC

<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-alternates-prop

css3 fonts

jdaggett: We've looked at this property before - opentype fonts have the capability to have alternate glyphs.
... There are many features that let you pick one of severeal alternates.
... In the past I specified this as just putting in a number to select a glyph. A lot of people objected to this.
... It doesn't look nice, it doesn't play nice with fallback, etc.
... So Elika and I sat down and created a way to establish a name-value mapping that applies to a family or families, so when you select an alternate you use the named value, not a numbeer.
... If the font has that named value defined for it, it's used, otherwise it's ignored.
... The syntax is a new @-rule, @font-feature-values.
... Syntax is slightly different than what I had on the list originally.
... It takes severeal font variant definitions.
... Like @font-feature-values Jupiter Sans { swash: delicate 1, flowing 2; }
... And then "h2 { font-family: Jupiter Sans; } h2::first-letter { font-variant-alternates: swash(delicate); }"
... There are some features tha tonly take one value, but some take multiple values.

<jdaggett> http://www.typography.com/fonts/font_documentation.php?docID=6&productLineID=100026#sets

jdaggett: [shows a font-variant page]
... This page goes through and defines all the selectors for different font features.
... So somebody using this font can enable these independently from each other.
... So in the opentype spec you have 20 of these features available. When you specify them via CSS you're specifying a set of them, so you want multiple values.
... The way I've defined this is that you can define multiple variants, and they all get turns on. Like "@font-feature-values Mars Serif { styleset: code 4 5; }", which turns on two separate features under the single label "code".

plinss: I think it's slightly confusing that you can use multiple declarations of the same type, and it means the same as a single comma-separated decl.

fantasai: Maybe you could swap the name and the feature, so like "{ code: styleset 4 5; }"

plinss: And what if you have another @font-feature later that defines another swash variant, frex?

jdaggett: It continues to be additive. If you use the same name for thee value, it overrides the previous value of the same name, but otherwise different names for the same feature collect together.

fantasai: [Here] you have a different things for styleset and character-variant.

jdaggett: Right. character variants are just somewhat different than anything else.
... character-variant is the only feature that takes two values. Everything else takes one value.

plinss: Suggestion for fixing the syntax implication - make @styleset, @swash, etc. sub-@rules underneath the @font-variant.

[discussion of syntax variants]

[appears to be consensus that later definitions for the same property/name should override]

fantasai: In character-variant, since it only takes 1 or 2 numbers, if you put 3 numbers it should be an invalid rule, not just ignore the 3rd value.

jdaggett: Are you okay with the syntax difference between character-variant and the other properties?

fantasai: It's unfortunate, but not bad enough to overly object to.

<smfr> RRSAgent: pointer

<fantasai> doodles:

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> @styleset code 5 6;

<fantasai> @styleset swishy 5;

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> swash: delicate 1, /* not apply */

<fantasai> flowing 2,

<fantasai> delicate 7;

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> swash: delicate 1; /* not apply */

<fantasai> swash: flowing 2;

<fantasai> swash: delicate 7;

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> code: styleset 5 6; /* not apply */

<fantasai> code: styleset 8;

<fantasai> swishy: styleset 5;

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> styleset {

<fantasai> code: 5, 6; /* not apply */

<fantasai> code: 8;

<fantasai> swishy: 5, 7, 9;

<fantasai> }

<fantasai> character-variant {

<fantasai> zeta: 20 3; /* cv20 = 3 */

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> styleset {

<fantasai> code: 5, 6; /* not apply */

<fantasai> code: 8;

<fantasai> swishy: 5, 7, 9;

<fantasai> }

<fantasai> character-variant {

<fantasai> zeta: 20 3; /* cv20 = 3 */

<fantasai> gamma: 12 5; /* cv12 = 5 */

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> @styleset code 5, 6; /* not apply */

<fantasai> @styleset code 8;

<fantasai> @styleset swishy 5, 7, 9;

<fantasai> @character-variant zeta 20 3; /* cv20 = 3 */

<fantasai> @character-variant gamma 12 5; /* cv12 = 5 */

<fantasai> }

<fantasai> @font-feature-values Jupiter Sans {

<fantasai> styleset: code 5 6, code 8, swishy 5 7 9;

<fantasai> character-variant: zeta 20 3, gamma 12 5;

<fantasai> }

<fantasai> fantasai: Problem with last option, even though it's more compact, is that repeating the declaration of a particular feature, it blows out all previous features

<fantasai> fantasai: I think it's better to allow an additive syntax, so either the @styleset syntax or the selector-like one

<fantasai> fantasai: The selector-like one has additive and overriding behavior that is is very closely analogous to existing CSS syntax

<fantasai> jdaggett: In many cases you'll have a global style sheet that defines a bunch of feature, bu the author might want to tweak a few more in a local style sheet

<fantasai> jdaggett: in which case an additive behavior would be better than having a new feature declaration erase the old one

Bert: This all seems very complicated for something that is already complex.

cslye: Yes, but this isn't a feature that a normal author is going to use anyway. This is basically just for opentype junkies.

Bert: I also don't like the fact that the value names are author-created, not standardized.
... There was another proposal for just turning on variants inside of a @font-face rule, so you could just define several font names with particular variants baked in.

jdaggett: That option is also there.

<timeless> [ Digression to talk about Corporate Style Sheets]

<fantasai> Bert argues that this is complicated and people will have to learn it which is bad

<fantasai> Timeless and Bert discuss corporate style sheets and how this will require them to deal with syntax they don't want to learn

<fantasai> Peter turns this around and shows that this syntax allows better cascading behavior between corporate global and local style sheets

<fantasai> Peter: Say I have a corporate style sheet that defines an @font-face rule and that turns on various features

<fantasai> Peter: I want to turn on an additional two new features.

<fantasai> Peter: You're saying I have to copy the corporate @font-face rule into my local style sheet and tweak it.

<fantasai> Peter: A week later, corporate style sheet is updated, tweaking its features to be slightly differen

<fantasai> t

<fantasai> Peter: I don't pick up those changes because my @font-face rule overrides theirs

<fantasai> Peter: Whereas if I use this syntax, I can pick up those changes because it's additive rather than overriding

howcome: In 4.1, it says "[downloaded fonts] must not be made availalbe to other applications or documents". I think it should be clear that things like caching don't violate this requirement.

<timeless> s/albe/able/

<fantasai> dbaron: ping css3-values?

<dbaron> fantasai, probably should stay here for another half hour

<arron> I am here

<johnjan> ah, hi arron.

<johnjan> we're waiting for the AC meeting to end, I believe.

<johnjan> 15 minutes.

<arron> ok, that gives me a few minutes to do email.

<glazou> johnjan: yes official end 17h30

<bradk> Hello

MultiCol

<fantasai> Alex: Why aren't percentages are valid in column-width?

<fantasai> fantasai: Because it makes more sense to use column-number

<fantasai> howcome: And doesn't have the problem of what to do with 33% vs 34%

<fantasai> Alex: Other issue was column rules in overflow columns

<fantasai> Alex: Are rules drawn between overflow columns?

<fantasai> howcome: yes

<fantasai> discussion of column rules between empty columns

<fantasai> howcome: both of them have to be empty

position layout

http://www.xanthir.com/blog/b48H0

<fantasai> Tab: Position-layout extends the positioning power by letting you position edges of boxes relative to other arbitrary boxes

<fantasai> Tab: Some use cases...

<fantasai> Tab: In Google Docs, for example, when you're doing annotations, you'll attach annotations to particular spans of text

<fantasai> Tab: In that case you would set the top of the annotation to be equal to the text being annotation, and the other side to the doc edge

<fantasai> Tab: Also want to measure this edge from this other edge

<fantasai> Tab: Our layout for our experimental newsreader app is good, but can only be done with a ton of fragile CSS hacks

<fantasai> Tab: There are three columns in importance of news

<fantasai> Tab: and then the rows represent timezones

<fantasai> Tab: Stories are titles, or title and picture and blurb

<fantasai> Tab: Want to expand the story to take up the whole width

<fantasai> Tab: Wound up using a JS constraint solver to do this switching

<fantasai> Tab: Another issue is resize handles

<fantasai> Tab: Want to position them relative to whatever image you want to resize

<fantasai> fantasai: I'm a little concerned about prioritizing work

<fantasai> fantasai: and you're editing a lot of drafts

<fantasai> Tab: I want to work on this in the context of the CSSWG

<fantasai> Tab: Want to have it in the charter

<fantasai> several concerned about prioritization of work and amount of work items

<fantasai> Tab: This is somewhat inspired by Daniel's proposals

<fantasai> Tab: ...

<fantasai> Tab talks about cycles and breaking cycles in the constraint solver

<fantasai> Tab talks about expanding functionality of fixed and absolute positioning

<fantasai> Tab: This is a superset of Daniel's proposal

<fantasai> Alex: Is it specific to positioning, or do you want it to be more general and e.g. make this table row as wide as that table column

<fantasai> Tab: Don't want to expand beyond positioning. If it gets to complicated, it gets very very tangled

<fantasai> Alex ... Instead of positioning, could be a special layout type

<fantasai> Alex: Instead of applying positioning anywhere, applies only within a particular element

<fantasai> Alex: a special kind of contianer

<fantasai> s/tian/tain

<fantasai> Tab: Interesting, but for now, I think I'd want to keep it as extension of positioning.

<fantasai> Tab: But let's talk and see if we can satisfies the use cases along the lines you're talking about

<fantasai> No one here objects to putting in charter as low priority

<fantasai> RESOLVED: add to charter as low priority

Transforms

<fantasai> Tab: Had a question of transforms applied to inlines

<fantasai> from Simon

<fantasai> Tab draws some text and a span

<fantasai> .... bla bla bla RTL RTL RTL bla ...

<fantasai> Span breaks across multiple lines

<fantasai> Tab: When you rotate, how do you rotate?

<fantasai> Tab: First option is transforms don't apply to inlines

<fantasai> Tab: Second option is to make a bounding box. Transform the bounding box.

<fantasai> Tab: Third option is to transform each box of the element independently.

<fantasai> Tab: Sub-issue: are bidi boxes transformed independently

<fantasai> fantasai: I would go with the bounding box option

<fantasai> Tab: what do you do with page breaks/column breaks?

<fantasai> fantasai: use same bounding box def as for backgrounds

<fantasai> discussion of relpos

<fantasai> and how that works

<fantasai> Anthony: Browsers: Opera and FF, do not rotate text if you put in the span

<fantasai> Anthony: Mobile solutions do rotate

<fantasai> Anthony: I haven't tried multiline in SVG

<fantasai> fantasai: I would just use the bounding box definition from the old css3-background drafts. Seems the simplest

<arron> the simplest would be to not apply transforms to inlines.

<fantasai> well, true

<fantasai> fantasai: define 2 and mark it at risk (fall back to 1)

<fantasai> RESOLVED: transforms apply to bounding box of the inline. Mark application of transforms to inlines at-risk. (Grab bounding-box definitions from old css3-background background-break drafts.)

css3-values

<johnjan> here we go

<fantasai> dbaron: I don't have anything to say...

<fantasai> arron, ping

<arron> I don't see the removal of min/max

<fantasai> wasn't it marked at-risk?

<arron> I thought we said we were going to remove those

<fantasai> no, we were going to mark them at-risk

<fantasai> http://www.w3.org/blog/CSS/2010/10/19/resolutions_126

<arron> Have all the updates been made? I am not seeing it in the Aug draft. Am I looking at the wrong version?

<fantasai> ?: Haptics proposal sent to www-style a couple months ago

<arron> Well If the updates have been made I have nothing more on this and we should just publish a new version

<ilkka> http://www.starlight-webkit.org/CSS/css3-haptics.html

<dbaron> s/?:/Ilkka Oksanen:/

<fantasai> Ilkka: Names in proposal not important

<fantasai> Ilkka: The use case we're trying to fulfill here is devices that have a touchscreen

<fantasai> Ilkka: can then have tactile feedback that's linked to the user interactions

<fantasai> Ilkka: Properties are style and strength

<fantasai> Alex: I know nothing about the area. Looks like different kind of feedback.

<fantasai> Alex: Seems like analogue of colors or sounds

<fantasai> Alex: Kind of properties I would expect are ... vibrate ...

<fantasai> Alex: I would expect that there are selectors that select when to feedback

<dbaron> Aren't the descriptions of 'unchecked-checkbox' and 'checked-checkbox' backwards?

<fantasai> Alex: and then style the items

<fantasai> Tab: Use case is mobile phone applications

<fantasai> Tab: Using names rather than specifying effects is to match OS conventions

<fantasai> Alex: Buttons etc. UI elements are in the system. Why doesn't it just launch the appropriate haptics?

<fantasai> Peter: Use case is for adding button feel to things that arent' actually buttons

<fantasai> jdaggett: So it's like the system colors?

<timeless> s/arent'/aren't/

<dbaron> and the input[type="radio"] style also seems backwards (shouldn't it be -down rather than -up?)

<fantasai> Peter: Have an issue where starting activation, ending activation might need separate effects

<fantasai> Peter: Have same issue with transitions

<fantasai> Discussion of conferring semantics

<fantasai> Discussion of triggers

<fantasai> Alex: Are there hidden triggers that are not available for any other feedback, like color?

<fantasai> Alex: If a browser implementing this has to implement internal triggers

<fantasai> Alex: Why not make triggers available to other effects?

<fantasai> Peter: We had related discussion at Apple wrt transitions -- we don't have ability to trigger transitions in and transitions out

<fantasai> dbaron: Doesn't seem to be related to :active

<fantasai> dbaron: Just what happens when you touch the element

<fantasai> Ilkka: The feedback is not related to how long you touch the element

<fantasai> Ilkka: When I touch an element on touchscreen, the vibrator is activated

<fantasai> dbaron: The spec is defining this as an inherited property, which seems reasonable.

<fantasai> dbaron: Don't see a problem with this applying to things that cannot be :active

<fantasai> Peter: Does this apply to everything? Or only if I have something that has buttonlike behavior?

<fantasai> Peter: What happens if I apply unlatch to a ?

<fantasai> dbaron: Not a good idea to do that?

<fantasai> dbaron: I think the default of the type being none is needed

<fantasai> dbaron: given the strength default is none

<fantasai> Peter: If I style a like a button and add haptics, will it behave like a button?

<fantasai> dbaron: No, it just feels like a button when you touch it.

<fantasai> fantasai: This is like a property to make a sound when you click the mouse on an element.

<fantasai> fantasai: except it's not a sound

<dbaron> And the default style sheet shouldn't use '-webkit-'

<fantasai> Peter: There are issues here similar to 'appearance', transitions, etc.

<fantasai> jdaggett: How common is it for phones to implement all the types you list?

<fantasai> jdaggett: Or rather, are all UAs on all phones capable of matching those types to something reasonable?

<fantasai> jdaggett: We have this problem with system colors, where it only maps reasonably in Windows 3

<fantasai> Peter: So should we scope this into the UI module?

<fantasai> jdaggett: Also, would you want to do this to other types of feedback? e.g. iphone uses sound

<fantasai> Peter describes a haptic mouse he had along time ago that gave the feel of running over a button when you cursored over a ubtton

<fantasai> Meeting closed.

- DRAFT -

CSS fatf @ TPAC

02 Nov 2010

Attendees

Contents

grids

Writing modes

css3 fonts

MultiCol

position layout

Transforms

css3-values

Summary of Action Items

Scribe.perl diagnostic output