See also: IRC log
<glazou> ScribeNick: jdaggett
<glazou> Meeting: CSS ftf @TPAC
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> | | | | |
<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/
<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> 3em | LR ||||||| <del>1em</del> <ins>5em</ins>
<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
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> }
<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> }
<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
<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
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
<fantasai> Tab: Had a question of transforms applied to inlines
<fantasai> from Simon
<fantasai> Tab draws some text and a span
<fantasai> <p>
<fantasai> .... <span>bla bla bla RTL RTL RTL bla</span> ...</p>
<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.)
<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 <span>?
<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 <span> 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.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/things/gridlines/ Succeeded: s/why/why named/ Succeeded: s/size/size constraints/ Succeeded: s/to do this// Succeeded: i/css3-writing-modes/Topic: Writing modes Succeeded: s/start/(padding,*)-start/ Succeeded: s/end/(padding,*)-end/ FAILED: s/accept/accepted/ FAILED: s/architecture/style system architecture/ FAILED: s/easy/easy based on an assumption which is not required by any specification/ FAILED: s/style system architecture/data structure for storage of declarations within declaration blocks/ FAILED: s/99/95/ FAILED: s/arronei/aharon/ Succeeded: s/aharon/arronei/ FAILED: s/linen/lanin ?/ Succeeded: s/anything/any new properties/ Succeeded: s/is/are/ Succeeded: s/use/lose/ FAILED: s/albe/able/ FAILED: s/tian/tain/ FAILED: s/?:/Ilkka Oksanen:/ FAILED: s/arent'/aren't/ Found ScribeNick: jdaggett Found ScribeNick: TabAtkinsTPAC Found ScribeNick: sylvaing Found ScribeNick: TabAtkinsTPAC Inferring Scribes: jdaggett, TabAtkinsTPAC, sylvaing Scribes: jdaggett, TabAtkinsTPAC, sylvaing ScribeNicks: jdaggett, TabAtkinsTPAC, sylvaing Default Present: Rhone_1, [Microsoft], unl Present: koji; dbaron; alexmog; jdaggett; sylvaing; johnjan; szilles; fantasai; plinss; howcome; shan timeless WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 02 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/02-CSS-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]