IRC log of CSS on 2010-11-02

Timestamps are in UTC.

08:03:11 [RRSAgent]
RRSAgent has joined #CSS
08:03:11 [RRSAgent]
logging to
08:03:19 [glazou]
ScribeNick: jdaggett
08:03:29 [glazou]
Meeting: CSS fatf @ TPAC
08:03:33 [komasshu]
komasshu has joined #css
08:03:36 [Bert]
zakim, call Rhone_1
08:03:36 [Zakim]
ok, Bert; the call is being made
08:03:37 [Zakim]
Team_(css)08:01Z has now started
08:03:38 [glazou]
Meeting: CSS ftf @TPAC
08:03:38 [Zakim]
08:03:43 [Zakim]
08:03:48 [plinss_]
rrsagent, make logs public
08:03:49 [hidetaka]
hidetaka has joined #css
08:04:37 [jdaggett]
topic: grids
08:04:43 [szilles]
szilles has joined #css
08:05:31 [jdaggett]
phil cupp on the phone from ms
08:05:40 [MoZ]
MoZ has joined #css
08:05:53 [alexmog]
alexmog has joined #css
08:06:00 [dbaron]
dbaron has joined #css
08:06:02 [anne]
anne has joined #css
08:06:12 [mmielke]
08:06:24 [Zakim]
08:07:37 [jdaggett]
alex: need some good 2d layout mechanism in css
08:07:52 [jdaggett]
alex: need for ui apps not just free-flowing text
08:08:05 [Zakim]
08:08:20 [jdaggett]
alex: several proposals for grids/table like layout
08:08:55 [jdaggett]
alex: looked at requirements first
08:08:57 [Zakim]
08:09:44 [Bert]
zakim, call Rhone_1
08:09:44 [Zakim]
ok, Bert; the call is being made
08:09:46 [Zakim]
08:10:14 [dbaron]
dbaron has joined #css
08:10:25 [Zakim]
08:11:13 [Bert]
zakim, call Rhone_1
08:11:13 [Zakim]
ok, Bert; the call is being made
08:11:15 [Zakim]
08:11:39 [johnjan]
08:12:11 [jdaggett]
alex: now back to the show
08:12:19 [jdaggett]
alex: we like our proposal
08:12:42 [jdaggett]
alex: how does this relate to previous proposals?
08:12:56 [freedom]
freedom has joined #css
08:13:39 [jdaggett]
alex: this proposal is based on xul, wpf-grid, probably closest to wpf-grid
08:14:06 [jdaggett]
alex: but uses flex box like elements (?)
08:14:19 [jdaggett]
alex: make sense?
08:14:33 [jdaggett]
alex: let's go over the spec
08:15:07 [TabAtkinsTPAC]
TabAtkinsTPAC has joined #css
08:15:16 [jdaggett]
alex: grid works by defining grid lines
08:15:37 [jdaggett]
alex: layout using row, column coords and how many columns it overlaps
08:15:42 [fsasaki]
fsasaki has joined #css
08:15:57 [jdaggett]
alex: grid sizes to content
08:16:18 [jun]
jun has joined #css
08:16:32 [jdaggett]
alex: works for both fixed/float cases
08:16:59 [jdaggett]
alex: define using
08:17:12 [jdaggett]
alex: display: grid | inline-grid
08:17:44 [kennyluck]
kennyluck has joined #CSS
08:18:32 [cslye]
cslye has joined #CSS
08:18:39 [r12a-nb]
r12a-nb has joined #CSS
08:18:45 [jdaggett]
alex: grid-column, grid-row with value to define grid
08:19:04 [jdaggett]
alex: (looking at ex 2)
08:19:40 [jdaggett]
dbaron: what are the values of grid-columns, grid-rows?
08:20:11 [jdaggett]
alex explains syntax
08:22:42 [jdaggett]
present currently: elika, bert, håkon, peter, markus, tab, beth dakin, richard ishida, steve z, daniel, ms john, sylvain, koji, dbaron
08:23:02 [jdaggett]
markus: values are from template spec
08:23:54 [jdaggett]
alex: columns, rows can overlap
08:24:05 [jdaggett]
alex: lots of interesting overlap cases
08:24:45 [jdaggett]
alex: for example, equivalent of xul stack layout with single slot w/ multiple items stretching to largest
08:25:47 [jdaggett]
jdaggett: does this have features that template doesn't support?
08:25:53 [jdaggett]
alex: overlapping elements
08:26:29 [jdaggett]
bert: also, this allows you to automatically grows grid with content
08:26:49 [fantasai]
bert: I explicitly left that out of Template to keep it simple
08:26:55 [jdaggett]
sylvain: yeah, if you add content at 5,5 to a 3,3 grid it grows automatically
08:27:31 [jdaggett]
alex: useful for sparse grids, or grids where order can change
08:27:41 [jdaggett]
markus: no-brainer if know tables
08:27:47 [jdaggett]
alex: no ascii art
08:27:54 [jdaggett]
jdaggett mourns this
08:28:32 [jdaggett]
bert: syntax question, many ways to express concept
08:28:40 [jdaggett]
fantasai: snap to grid functionality?
08:28:58 [jdaggett]
alex: not yet, every item is explicitly placed
08:29:50 [jdaggett]
fantasai: not a fan of positioning aspect
08:30:06 [jdaggett]
fantasai: but a flex box layout aligned to grid woud be groovy
08:30:36 [glazou]
glazou 'grid-cell: 'selector'' can be added afterwards
08:30:46 [jdaggett]
fantasai: using flexbox or template to align would not break with reflow
08:31:11 [jdaggett]
peter: typically grids are defined by lines not cells
08:31:44 [jdaggett]
peter: and align to line, not cell
08:32:04 [fantasai]
mollydotcom, exacty. I think flexbox or template + snap-to-grid would be great
08:32:22 [jdaggett]
jdaggett: didn't you propose grid positioning with grid lines?
08:32:31 [jdaggett]
alex: no real contradiction between the two
08:32:34 [fantasai]
mollydotcom, It seems to me easier to lose, and less likely to break with reflow effects (window resizing, font resizing, changing content, etc.)
08:33:11 [jdaggett]
alex: we didn't want to combine the two
08:33:13 [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
08:33:29 [jdaggett]
alex: could have circular dependencies
08:33:58 [jdaggett]
alex: i would to see both
08:34:17 [jdaggett]
alex: but don't want to spend the whole time resolving dependencies
08:34:44 [jdaggett]
alex: can do the same with this as with gridlines
08:35:28 [fantasai]
jdaggett: Graphic design books that talk about grids, was more along what Peter was saying
08:35:38 [fantasai]
jdaggett: This model you're going to have to do extra work to define that
08:35:54 [jdaggett]
markus: two core use cases
08:36:06 [jdaggett]
markus: 1. print design layouts
08:36:21 [jdaggett]
markus: 2. app layouts
08:36:28 [jdaggett]
markus: this is more for (2)
08:37:01 [jdaggett]
alex: grids in print don't deal with resizing issues
08:37:36 [jdaggett]
alex: much better to have some that are fixed, some that flex
08:38:24 [jdaggett]
alex: when grid is sized by content is actually more useful but doesn't cover all scenarios
08:38:37 [jdaggett]
stevez: symbolic identification
08:38:44 [Peter`]
Peter` has joined #css
08:38:45 [jdaggett]
stevez: names to cells?
08:38:54 [jdaggett]
fantasai: that's what template does
08:39:08 [jdaggett]
alex: we have started with minimal feature set
08:39:26 [jdaggett]
peter: i don't want to name cell, i want to name lines
08:39:51 [jdaggett]
peter: if a grid row/line is added in the middle, the grid shrinks
08:40:10 [jdaggett]
peter: i want to span from one gridline to another
08:40:22 [jdaggett]
peter: even if lines are added in between
08:40:43 [jdaggett]
peter: could be dynamic or for additive layout
08:40:58 [jdaggett]
peter: like in the case when you just want to add a logo to a layout
08:41:17 [anne]
Bert, files are in but not in ?
08:42:00 [jdaggett]
pcupp: we thought about a pseudo-element that spans cells (?)
08:42:23 [jdaggett]
pcupp: the cell defines a region for content to be laid out
08:42:29 [Bert]
(Maybe Peter is thinking of something like: 'grid-columns: a=0%, b=75%, c=50%' and then 'grid-column: c'?)
08:42:41 [jdaggett]
pcupp: maybe it's aligned, maybe it stretches
08:43:26 [jdaggett]
pcupp talking about an example...
08:43:39 [jdaggett]
markus: just a slightly different use case
08:44:02 [jdaggett]
alex: can it be used as gridlines? no, not just with this
08:44:18 [jdaggett]
alex: but we want to have some form of gridline like capability
08:44:32 [fsasaki]
fsasaki has joined #css
08:44:38 [jdaggett]
sylvain: i think we need to capture peter's use case
08:44:48 [jdaggett]
sylvain: of inserting new gridlines
08:45:23 [jdaggett]
peter: this defines cells but i don't think we need another way of defining cells
08:45:45 [jdaggett]
alex: this is about grid alignment of cells
08:45:59 [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
08:46:05 [jdaggett]
alex: obviously we can take it further
08:46:25 [jdaggett]
peter: give me the ability to name a gridline
08:47:05 [jdaggett]
peter: so that i can say "this thing goes in a box that goes between these things"
08:47:23 [fantasai]
08:47:27 [jdaggett]
peter: this way i can define my cells arbitrarily
08:48:15 [jdaggett]
peter: rows/columns we already have, i want new toys
08:49:08 [jdaggett]
daniel: peter's proposal is not far away from my proposal to define layout with respect to other elements
08:49:21 [jdaggett]
murmurs of disagreement
08:49:49 [dbaron]
I think this is pretty different, since this contains things properly so things won't overlap.
08:50:26 [jdaggett]
continuing through spec
08:50:33 [glazou]
dbaron: : no verlap ?
08:51:17 [jdaggett]
alex: there is a property that controls the order of rendering
08:51:19 [joonho]
joonho has joined #css
08:51:27 [jdaggett]
alex: to deal with overlapping elements
08:51:32 [jdaggett]
alex: not super important
08:51:52 [jdaggett]
(section 8 of spec)
08:52:07 [jdaggett]
peter: what if you just use z-index?
08:52:12 [jdaggett]
alex: we can discuss that
08:52:19 [jdaggett]
peter: i don't see the difference
08:52:33 [jdaggett]
alex mumbles...
08:52:39 [jdaggett]
and smiles
08:53:07 [jdaggett]
daniel: i'm considering working on peter's proposals
08:53:21 [jdaggett]
daniel: i have a few ideas about this
08:53:34 [jdaggett]
howcome: use cases would be interesting
08:53:40 [jdaggett]
howcome: for comparison
08:54:01 [jdaggett]
daniel: i'll work on the ideas, then the use cases if i have time
08:54:14 [jdaggett]
stevez: there were previous proposals for...
08:55:01 [jdaggett]
stevez: a two-column layout with a figure in the middle
08:55:15 [jdaggett]
stevez: there's an issue with how to overlay
08:55:31 [jdaggett]
howcome: that's in gcpm!!
08:55:49 [jdaggett]
howcome: but this is app centric, not document centric
08:56:07 [jdaggett]
peter: lots of use cases for document centric uses
08:56:22 [jdaggett]
daniel: this is really about app centric use
08:56:30 [jdaggett]
alex: concurs
08:56:37 [jdaggett]
stevez: i'm dazed and confused
08:56:56 [fantasai]
I believe template + flex coudl do most of these layouts, aside from the overlapping ones
08:57:17 [jdaggett]
stevez: i thought you were tailoring the syntax for one use
08:57:40 [exr]
exr has joined #css
08:57:50 [jdaggett]
markus: there's an aspect....
08:58:12 [jdaggett]
pcupp: we think it's the common case where controls are composed using this
08:58:31 [jdaggett]
section 2.4, figure 6
08:58:44 [jdaggett]
picture of a slider
08:58:56 [jdaggett]
because the world needs more sliders...
08:59:12 [jdaggett]
alex: what can we do with this? new module? merge with another?
08:59:34 [jdaggett]
bert: seems close to flex box
08:59:46 [jdaggett]
tab mumbles
09:00:01 [jdaggett]
bert: i have a number of comments
09:00:36 [jdaggett]
bert: when you put two elements in the grid they overlap, they don't add
09:00:43 [jdaggett]
bert: might be good or bad
09:00:57 [jdaggett]
markus: you need it as in the slider example
09:01:12 [jdaggett]
tab: this example is also nice for being able to overlap
09:01:23 [szilles]
+1 for tab's comment
09:01:24 [jdaggett]
bert: what's the intrinsic size in this case?
09:01:34 [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> ?
09:02:07 [jdaggett]
alex: multiple items in cell all affect sizing
09:02:14 [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.
09:02:19 [jdaggett]
bert: don't like three props, why not one
09:02:43 [jdaggett]
alex: yeah but that would be a long line
09:03:27 [jdaggett]
alex: well you don't need to specify predefined size
09:03:38 [jdaggett]
bert: wondering float and position
09:03:46 [jdaggett]
alex: works just like flex box
09:03:50 [dbaron]
I'd prefer not to put complicated syntax inside values of 'display'.
09:04:07 [jdaggett]
alex: float ignored, position with regards to nearest positioned element
09:04:23 [jdaggett]
tab says something i don't understand
09:05:01 [jdaggett]
alex: position might also work the same way but not affect sizing
09:05:37 [jdaggett]
tab: in my position layout proposal, i came up with a good model for positioning in new layout proposals
09:06:12 [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.
09:06:14 [jdaggett]
argh, not following tab again...
09:06:42 [jdaggett]
alex: the way to think about absolute positioning
09:07:08 [jdaggett]
alex: with a grid it's obvious where it's positioned
09:07:10 [yuma_1985]
yuma_1985 has joined #css
09:07:11 [TabAtkinsTPAC]
TabAtkinsTPAC: In my Positioned Layout proposal I specified a consistent and easy way to make positioning interact with other layout modes.
09:07:12 [jdaggett]
alex and bert discuss this
09:07:28 [TabAtkinsTPAC]
TabAtkinsTPAC: The positioned element leaves behind a placeholder element.
09:07:58 [jdaggett]
bert: difference between grid-row and grid-rows is just one letter
09:08:06 [jdaggett]
same for columns
09:08:32 [jdaggett]
syntax discussion
09:08:56 [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.)
09:09:01 [jdaggett]
bert: for flex box the content is in a given order
09:09:21 [jdaggett]
bert: with this proposal the source order doesn't affect the order in the grid
09:09:34 [jdaggett]
alex: one possible extension is auto-incrementing rows/columns
09:09:40 [jdaggett]
alex: this is closer to xul grid
09:10:03 [jdaggett]
dbaron: also auto-incrementing row-groups/column-groups
09:10:45 [dbaron]
and you could allow them to take grid-row/grid-column (or lines) and not start at the top-left
09:11:10 [jdaggett]
bert: the idea that you auto-create the table based on a single cell
09:11:26 [jdaggett]
bert: but you can't catch errors in your design
09:12:19 [jdaggett]
bert: because it's not based on explicitly named entities
09:12:36 [jdaggett]
alex: either way you need to define a protocol here
09:12:51 [jdaggett]
bert: i'm not sure plus/minus but it does mask errors
09:13:03 [jdaggett]
bert: you don't allow % in cell size
09:13:25 [jdaggett]
alex: could be added
09:13:41 [jdaggett]
tab: what exactly do you want to base the % on
09:14:05 [jdaggett]
tab: you need to explain which the % is based one
09:14:23 [komasshu]
komasshu has left #css
09:15:03 [komasshu]
komasshu has joined #css
09:15:23 [jdaggett]
dbaron: i was thinking of someone designing a page
09:15:39 [jdaggett]
with embedded grids with constraints between elements
09:15:58 [jdaggett]
dbaron: with this proposal you would use nested grids
09:16:35 [Kai]
+1 to David's proposal
09:16:55 [jdaggett]
dbaron: are there cases where nested grids need to line up with ...
09:17:06 [jdaggett]
peter: this is why gridlines are handy
09:17:09 [Ibrahima_]
Ibrahima_ has joined #css
09:17:16 [fantasai]
s/why/why named/
09:17:36 [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...)
09:17:58 [jdaggett]
pcupp: so you're talking about how to line up nested grids with outer grid
09:18:27 [jdaggett]
pcupp: with unioned gridlines, spanning behavior becomes hard to predict
09:18:39 [jdaggett]
pcupp: things tend to grow in unpredictable ways
09:19:19 [fantasai]
dbaron's drawing:
09:19:24 [fantasai]
09:19:25 [fantasai]
| |
09:19:25 [fantasai]
| +--+--+
09:19:25 [fantasai]
| | | |
09:19:25 [fantasai]
09:19:27 [fantasai]
| | | | |
09:19:30 [fantasai]
+--+--+--+ |
09:19:30 [jdaggett]
bert: also, you can't put something in your cousin grids, only grids within single tree
09:19:32 [fantasai]
| |
09:19:35 [fantasai]
09:19:58 [jdaggett]
ah, we do so need ascii art
09:20:05 [jdaggett]
bert: just a remark
09:20:11 [jdaggett]
bert: this is hard
09:20:29 [jdaggett]
bert: cesar found examples where this might be handy
09:20:44 [jdaggett]
stevez: why is that a good thing?
09:21:15 [jdaggett]
bert and steve discuss trees and kissing cousins
09:22:09 [jdaggett]
stevez: similar to separating template from content
09:22:24 [jdaggett]
bert: you can select different grids from screen size
09:22:46 [jdaggett]
bert: you can use the body element to hook your grid on
09:23:26 [jdaggett]
bert: those are my comments
09:23:37 [jdaggett]
fantasai: you might also want named grids
09:23:44 [jdaggett]
fantasai: main and secondary
09:24:09 [jdaggett]
fantasai: but maybe i don't totally understand
09:24:20 [jdaggett]
alex: we would like to make this an editor's draft
09:24:23 [Bert]
(Something like: 'grid-column: a.1' for column 1 in grid a?)
09:24:29 [jdaggett]
alex: what else do we need to get there?
09:25:03 [jdaggett]
alex: we can make changes to deal with use cases and functionality discussed
09:25:17 [jdaggett]
stevez: how many table-like layout mechanisms do we need
09:25:19 [jdaggett]
09:25:26 [jdaggett]
markus: you need a variety
09:25:50 [jdaggett]
markus: you need abosolute positioning, flex box, grid
09:26:02 [jdaggett]
markus: each solves a different use case
09:26:20 [howcome]
howcome has joined #css
09:26:27 [jdaggett]
pcupp: overlap in grid / flexbox use
09:26:49 [jdaggett]
pcupp: they're complimentary
09:26:55 [jdaggett]
peter: this is a 2d flexbox
09:27:05 [jdaggett]
stevez: there are comonalities
09:27:12 [jdaggett]
stevez: declaring size
09:27:21 [jdaggett]
stevez: concerned about complexity
09:27:27 [jdaggett]
markus: in the end it all makes sense
09:27:36 [jdaggett]
markus: app vs. doc roles
09:27:50 [fantasai]
s/size/size constraints/
09:27:57 [jdaggett]
tab: steve, your concern is that we get too much complexity?
09:28:12 [jdaggett]
stevez: it's that we have a lot of ways of defining cellsize
09:28:26 [jdaggett]
stevez: are the pieces the same across all three sizes?
09:28:44 [jdaggett]
tab: you can express everything in one master model
09:28:59 [jdaggett]
tab: different uses require different layout models
09:29:19 [jdaggett]
tab: layout models interact in orthogonal ways
09:29:30 [jdaggett]
tab: make each as easy as possible
09:30:29 [jdaggett]
stevez: i'm ok with that but i want to make sure that concepts carry across the models
09:30:40 [jdaggett]
stevez: the base primitives need to be consistent
09:31:15 [jdaggett]
tab: yes, you want primitives to work across layout models (?)
09:31:34 [jdaggett]
howcome: healthy competition across modules is good
09:31:50 [jdaggett]
howcome: this model and template don't make sense together
09:32:30 [jdaggett]
stevez: is there an action item for bert/alex to combine these ideas
09:33:05 [jdaggett]
bert: future ideas, non-rectangular cells, chained cells
09:33:10 [jdaggett]
howcome: and across pages
09:33:25 [jdaggett]
bert: so the question is how these concepts fit with that
09:33:44 [jdaggett]
peter: grids that flow across pages or grids that repeat
09:33:57 [jdaggett]
peter: can we use the same syntax for both
09:34:09 [jdaggett]
markus: need to be careful about use cases
09:34:24 [jdaggett]
markus: if combination is complex, life sucks for everyone
09:34:41 [jdaggett]
peter: one problem is that you're calling this a grid
09:35:01 [jdaggett]
peter: it's not really a grid
09:35:15 [jdaggett]
stevez talking about the beauty of xsl
09:35:39 [jdaggett]
markus: need to solve both print-like and app use cases
09:36:07 [jdaggett]
markus: two action items, alex/bert to kibbitz
09:36:26 [jdaggett]
markus: and talk with daniel about his ideas
09:36:36 [jdaggett]
peter: may end up with 90% overlap
09:36:57 [jdaggett]
stevez: could be true, punchout or overlay, small set of props captures both
09:37:11 [jdaggett]
stevez: a model for both is important
09:37:25 [jdaggett]
stevez: no problem if app is favored, since docs are harder
09:37:34 [jdaggett]
peter: i just want us to be thinking about this
09:37:58 [jdaggett]
markus: yeah, maybe grid is not the best name here
09:38:23 [jdaggett]
fantasai: grid-columns and grid-rows are common to both grid specs?
09:38:36 [jdaggett]
alex: yeah, we have to merge or redefine
09:38:51 [jdaggett]
discussion of what to do with the document
09:39:25 [jdaggett]
daniel: grids are already in the charter
09:39:47 [jdaggett]
stevez: not sure this is FPWD ready
09:40:01 [jdaggett]
stevez: we should do some vetting
09:40:22 [jdaggett]
daniel: don't need to name it now
09:40:32 [jdaggett]
markus: first agree on what's in these specs
09:40:48 [Zakim]
09:40:50 [timeless_mbp]
timeless_mbp has joined #css
09:40:56 [jdaggett]
break for coffee and champagne
09:41:17 [myakura]
RRSAgent, make minutes
09:41:17 [RRSAgent]
I have made the request to generate myakura
09:43:02 [kennyluck]
kennyluck has joined #CSS
09:43:50 [Zakim]
09:43:51 [Zakim]
Team_(css)08:01Z has ended
09:43:53 [Zakim]
Attendees were Rhone_1, [Microsoft], unl
09:44:51 [komasshu]
komasshu has joined #css
09:47:06 [glazou]
glazou has joined #css
09:48:57 [yuma_1986]
yuma_1986 has joined #css
09:49:28 [mjs]
mjs has joined #css
09:52:43 [cslye]
cslye has joined #CSS
09:58:43 [shan]
shan has joined #css
10:06:17 [dethbakin]
dethbakin has joined #css
10:07:25 [jun]
jun has joined #css
10:08:39 [homata]
homata has joined #CSS
10:08:46 [shepazu]
shepazu has joined #css
10:09:28 [hidetaka]
hidetaka has joined #css
10:09:36 [dethbakin]
dethbakin has joined #css
10:11:06 [glazou]
glazou has joined #css
10:11:16 [TabAtkinsTPAC]
ScribeNick: TabAtkinsTPAC
10:11:23 [sylvaing]
10:11:38 [fantasai]
10:12:29 [TabAtkinsTPAC]
fantasai: In the draft, I define some terms and drew some pictures.
10:12:35 [fsasaki]
fsasaki has joined #css
10:13:00 [MikeSmith]
MikeSmith has joined #css
10:13:15 [TabAtkinsTPAC]
howcome: I suggest simplifying the terms to 'inline direction' and 'block direction', not '* flow directionality'.
10:13:35 [TabAtkinsTPAC]
szilles: I think "directionality" is a hard word for non-English speakers.
10:13:41 [TabAtkinsTPAC]
fantasai: Okay, don't have an opinion much.
10:13:43 [timeless_mbp]
timeless_mbp has joined #css
10:13:57 [TabAtkinsTPAC]
fantasai: Most of the bidi text here is just copied from css 2.1.
10:14:22 [sylvaing]
section 3.2. title typo: 'uncode-bidi'
10:14:52 [TabAtkinsTPAC]
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?
10:15:14 [TabAtkinsTPAC]
fantasai: 'isolate' is a new unicode-bidi value, proposed by the bidi for html group.
10:15:29 [TabAtkinsTPAC]
fantasai: That prevents strings that have a different directionality from having an effect on the text around them.
10:15:30 [Kai]
Kai has joined #css
10:15:52 [TabAtkinsTPAC]
fantasai: There's also a plaintext value, which is intended to use the unicode bidi algorithm to determine the bidi direction of each paragraph.
10:16:03 [r12a-nb]
r12a-nb has joined #css
10:16:05 [TabAtkinsTPAC]
fantasai: This does *not* affect the direction property, it just affects bidi resolution.
10:16:20 [TabAtkinsTPAC]
aharon: Should I give use-cases for 'isolate' and 'plaintext'?
10:16:24 [TabAtkinsTPAC]
szilles: Would be helpful.
10:16:42 [TabAtkinsTPAC]
aharon: 'isolate' is useful in the context of a webapp that is inserting data into a page.
10:16:56 [dbaron] has some use cases for these new features, no?
10:16:59 [MoZ]
MoZ has joined #css
10:17:04 [shepazu]
shepazu has joined #css
10:17:05 [TabAtkinsTPAC]
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.
10:17:34 [TabAtkinsTPAC]
aharon: If you don't isolate the titles, it quite often interacts with the stuff around it, such as numbers and other neutral characters.
10:18:23 [TabAtkinsTPAC]
aharon: Outside of an app, it's useful for quotes and links - I can't imagine why you'd want a link to be broken up into two parts due to its directionality interacting oddly with the surrounding content.
10:18:33 [TabAtkinsTPAC]
fantasai: It drastically reduces the number of LRM/RLM you have to use.
10:19:04 [TabAtkinsTPAC]
aharon: Side thought - I think instead of "inline direction", use "inline base direction".
10:19:15 [TabAtkinsTPAC]
aharon: The base direction is controlled by the 'direction' property.
10:19:19 [dbaron]
aharon: Might be good to use the term "inline base direction" instead of "inline directionality"
10:19:30 [dbaron]
(given the previous discussion about avoiding the term "inline directionality")
10:19:34 [TabAtkinsTPAC]
aharon: There are a couple of problems. You might not know what the direction is - it could be outside data.
10:19:53 [TabAtkinsTPAC]
aharon: It is very useful to let the UA guess what the direction is using standard algos based on the characters in the data.
10:20:13 [TabAtkinsTPAC]
aharon: There is a separate proposal in HTML for @dir=auto to do this.
10:20:21 [TabAtkinsTPAC]
s/to do this//
10:20:35 [TabAtkinsTPAC]
aharon: That's not precisely what we have here in 'plaintext'.
10:20:57 [TabAtkinsTPAC]
aharon: The UA, in HTML, sees dir=auto, looks at the content, decides whether the direction is rtl or ltr, then sets the CSS 'direction' appropriately.
10:21:12 [TabAtkinsTPAC]
aharon: That's good, but doesn't go quite far enough.
10:21:26 [TabAtkinsTPAC]
aharon: Let's say I have a textarea - plaintext - that the user is typing into.
10:21:53 [TabAtkinsTPAC]
aharon: Is it fairly useful to have some paragraphs in one language and some paragraphs in another language. Frex, I'm typing in a restaurant review in Hebrew.
10:22:25 [TabAtkinsTPAC]
aharon: I give the review in Hebrew, then say "the address is:..." and give it in French because the restaurant is in Lyon. If I don't switch the direction of the paragraph, the number at the start of the address will go on the wrong side.
10:22:38 [TabAtkinsTPAC]
aharon: So you want the ability to have paragraphs that go in different directions.
10:22:48 [TabAtkinsTPAC]
aharon: If you're doing markup, that's great - you can just make separate paragraphs.
10:22:58 [TabAtkinsTPAC]
aharon: If you're just typing into a textarea, though, you cant' do that.
10:23:20 [TabAtkinsTPAC]
aharon: The unicode bidi algorithm defines a simple way to define the directionality of each paragraph (where "paragraph" is defined by the bidi algorithm).
10:23:40 [TabAtkinsTPAC]
aharon: So 'plaintext' would say that the textarea isn't necessarily ltr or rtl, it's plaintext where each paragraph can go either way.
10:23:59 [TabAtkinsTPAC]
aharon: It's still not limited to textarea, of course - often after taking the data from a textarea you want to then display it.
10:24:20 [TabAtkinsTPAC]
aharon: So you want to still be able to apply this same directionality algorithm to the results outside of a textarea.
10:24:55 [TabAtkinsTPAC]
aharon: You can't hide the directionality determination from CSS with dir=auto here, because the different paragraphs aren't marked up as explicit elements.
10:25:12 [dsinger]
dsinger has joined #css
10:25:12 [TabAtkinsTPAC]
dbaron: [question about which characters serve as paragraph separators]
10:25:50 [TabAtkinsTPAC]
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.
10:26:02 [TabAtkinsTPAC]
Bert: What's the difference between 'embed' and 'isolate'?
10:26:26 [TabAtkinsTPAC]
aharon: 'embed' says "this element has a base direction", but that doesn't prevent the element from affecting stuff outside of it.
10:27:01 [TabAtkinsTPAC]
aharon: So, if I have an english paragraph, but in the middle is an arabic word and then an embed of a separate element which is explicitly rtl.
10:27:16 [TabAtkinsTPAC]
aharon: The unicode algorithm says that the arabic and the rtl are merged together and will both flow rtl together.
10:27:34 [TabAtkinsTPAC]
aharon: You don't want this - logically, the arabic and the embed are separate, and shouldn't stick together.
10:27:58 [TabAtkinsTPAC]
Bert: So inside, 'embed' and 'isolate' are the same. They're different outside?
10:28:00 [TabAtkinsTPAC]
aharon: Yes.
10:28:16 [TabAtkinsTPAC]
howcome: It seems that you need to explicitly set all block-level elements to 'isolate'?
10:28:23 [TabAtkinsTPAC]
dbaron: That should be in the default stylesheet.
10:29:02 [TabAtkinsTPAC]
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.
10:29:28 [TabAtkinsTPAC]
aharon: Right now HTML5 effectively says that all block-level elements should be 'embed'; we just changed it to 'isolate', which is closer to the intenet.
10:29:57 [TabAtkinsTPAC]
aharon: As to making a block inline, one example is an inline list. If some of those values are opposite direction, it's important to have isolation apply to them.
10:30:17 [TabAtkinsTPAC]
howcome: So, can we in any way hinge this behavior on the existing CSS display?
10:30:30 [TabAtkinsTPAC]
fantasai: If the display is anything other than inline, you already *effectively* have the isolate value.
10:30:53 [TabAtkinsTPAC]
fantasai: The problem is just that when you change the display value to inline, there's no CSS distinction to tell us that this *used* to be a block-level, so you need 'isolate' there.
10:32:30 [TabAtkinsTPAC]
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.
10:32:40 [TabAtkinsTPAC]
howcome: But you have to remember to set 'isolate' in new XML languages.
10:32:42 [MikeSmith]
RRSAgent, make minutes
10:32:42 [RRSAgent]
I have made the request to generate MikeSmith
10:32:44 [TabAtkinsTPAC]
TabAtkins: Yes.
10:33:07 [TabAtkinsTPAC]
Bert: Does this cover all known cases?
10:33:19 [TabAtkinsTPAC]
fantasai: This covers all of CSS2.1 + all of the proposals from the bidi subgroup for i18n.
10:33:44 [TabAtkinsTPAC]
fantasai: Now, 'writing-mode'.
10:33:58 [TabAtkinsTPAC]
fantasai: The previous writing-mode property was a shorthand for block-flow-direction and 'direction'.
10:34:17 [TabAtkinsTPAC]
fantasai: One of the things I was tasked with was to sync with SVG, which is very explicit that the writing-mode and direction property don't interact.
10:34:31 [TabAtkinsTPAC]
fantasai: The SVG spec has these valuees (lr, lr-tb, rl, tb, tb-rl)
10:34:56 [TabAtkinsTPAC]
fantasai: I could figure out what the 'rl' value was and how it differs from 'lr'.
10:35:13 [TabAtkinsTPAC]
fantasai: The SVG spec says you do bidi reordering, then use writing-mode to change the inline progression direction.
10:35:30 [MikeSmith]
i/css3-writing-modes/Topic: Writing modes
10:35:34 [MikeSmith]
RRSAgent, make minutes
10:35:34 [RRSAgent]
I have made the request to generate MikeSmith
10:35:38 [TabAtkinsTPAC]
fantasai: Which is left to right in 'lr' - this is *after* bidi reordering, in visual ordere.
10:36:09 [TabAtkinsTPAC]
fantasai: As far as I can tell, 'rl' should maybe just mean reverse the text, but I only found one impl that does that.
10:36:23 [TabAtkinsTPAC]
fantasai: So, I just mapped both of them to the same thing - 'horizontal-tb'.
10:36:58 [TabAtkinsTPAC]
fantasai: So now, in CSS, the 'direction' and 'writing-mode' are distinct. You first do bidi reordering, then 'writing-mode' just defines the axis to use.
10:37:22 [Hixie]
Hixie has joined #css
10:37:25 [TabAtkinsTPAC]
fantasai: I thought that saying 'lr' was confusing, since it doesn't have anything to do with ltr text, so I called the value "horizontal-tb".
10:37:44 [TabAtkinsTPAC]
shepazu: The hreason SVG does it the way it does, is because XSL did it that way.
10:38:18 [TabAtkinsTPAC]
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.
10:38:36 [TabAtkinsTPAC]
sylvaing: Is there content out there using 'writing-mode:lr-tb'?
10:38:45 [TabAtkinsTPAC]
fantasai: Yes, but it's not relying on the direction-reset stuff.
10:39:23 [TabAtkinsTPAC]
fantasai: I think the number of people who are mixing rtl with vertical text right now is basically ignorable, though I suspect it will increase as we support this.
10:39:41 [TabAtkinsTPAC]
shepazu: Let's say I have a table in HTML, and I want a header going down the side, with english vertical text...
10:39:48 [TabAtkinsTPAC]
fantasai: That's addressed by other stuff in the draft.
10:40:23 [TabAtkinsTPAC]
fantasai: So, with 'writing-mode', the first value gives you the line axis, the second gives you the block-flow. "horizontal-tb", and "vertical-lr".
10:40:52 [TabAtkinsTPAC]
fantasai: [I missed the line about mongolian]
10:41:08 [TabAtkinsTPAC]
jdaggett: I don't understand why we need horizontal-bt.
10:41:14 [TabAtkinsTPAC]
fantasai: I did it because MS implemented it.
10:41:21 [TabAtkinsTPAC]
alexmog: Mainly for completeness.
10:41:28 [TabAtkinsTPAC]
jdaggett: I don't understand completeness.
10:41:58 [TabAtkinsTPAC]
alexmog: It's simple and obvious what it means. There aren't large use-cases, but it takes a very minimal impl cost.
10:42:18 [TabAtkinsTPAC]
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.
10:42:34 [TabAtkinsTPAC]
jdaggett: Frex, this can affect what PgUp/PgDn mean, which means manual testing.
10:42:44 [TabAtkinsTPAC]
fantasai: I completely abstain from this.
10:43:05 [TabAtkinsTPAC]
shepazu: Are there any scripts that have used it?
10:43:14 [TabAtkinsTPAC]
[maybe some archaic scripts, but not commonly]
10:43:30 [TabAtkinsTPAC]
howcome: I don't think we need to try for complete here.
10:44:22 [TabAtkinsTPAC]
howcome: What does it mean in a paged medium?
10:44:36 [TabAtkinsTPAC]
[chatter about pagination]
10:44:41 [TabAtkinsTPAC]
fantasai: You paginate up.
10:45:17 [TabAtkinsTPAC]
shepazu: Small but serious use-case.
10:45:44 [TabAtkinsTPAC]
shepazu: There are efforts now to go back to ancient texts and transcribe them in some format. There are people who want to represent dead languages.
10:46:01 [TabAtkinsTPAC]
jdaggett: I think we can remove it for now, and then put it back if someone has a language that needs it.
10:46:49 [TabAtkinsTPAC]
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.
10:47:22 [TabAtkinsTPAC]
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?
10:47:48 [TabAtkinsTPAC]
plinss: Can we mark it as optional?
10:48:00 [TabAtkinsTPAC]
jdaggett: It's either in the test suite or not.
10:48:51 [TabAtkinsTPAC]
plinss: We can spend as much time debating it as it would take to implement it.
10:49:39 [TabAtkinsTPAC]
fantasai: I don't care what we do. I just want to resolve.
10:50:18 [TabAtkinsTPAC]
RESOLVED: remove the horizontal-bt property.
10:50:44 [TabAtkinsTPAC]
Bert: The name is fine, but I think that 'writing-mode' in XSL does influence the direction, so there's a difference there.
10:51:41 [TabAtkinsTPAC]
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.
10:52:30 [TabAtkinsTPAC]
jdaggett: I don't know why XSL compat is an issue.
10:53:35 [TabAtkinsTPAC]
szilles: SVG needs to work in both XSL and CSS.
10:53:54 [TabAtkinsTPAC]
fantasai: SVG is already incompatible with XSL.
10:55:04 [TabAtkinsTPAC]
Bert: I thought that SVG copied from XSL.
10:55:22 [mjs]
mjs has joined #css
10:55:26 [TabAtkinsTPAC]
fantasai: They must have copied badly here, then.
10:56:16 [TabAtkinsTPAC]
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.
10:56:38 [TabAtkinsTPAC]
Bert: I'd like to be able to use CSS and XSL together.
10:57:31 [TabAtkinsTPAC]
shepazu: There is a japanese SVG interest group, so they'll look at the issue.
10:58:11 [TabAtkinsTPAC]
fantasai: Next interesting bit is text-orientation.
10:58:20 [TabAtkinsTPAC]
fantasai: szilles and XXX and I worked out these values a long time ago.
10:58:54 [TabAtkinsTPAC]
fantasai: The default is "vertical-right", because that's the natural orientation for vertical scripts.
10:59:20 [TabAtkinsTPAC]
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.
10:59:25 [TabAtkinsTPAC]
fantasai: The spec actually specifies that.
11:00:07 [TabAtkinsTPAC]
jdaggett: We probably want to be explicit about the interaction with opentype, or refer to the spec.
11:00:15 [TabAtkinsTPAC]
fantasai: I'll need help with that, because I have no clue.
11:00:42 [MikeSmith]
RRSAgent, make minute
11:00:42 [RRSAgent]
I'm logging. I don't understand 'make minute', MikeSmith. Try /msg RRSAgent help
11:00:46 [TabAtkinsTPAC]
jdaggett: You use the term "grapheme clusters", which I think won't be underestood by most people.
11:00:46 [MikeSmith]
RRSAgent, make minutes
11:00:46 [RRSAgent]
I have made the request to generate MikeSmith
11:01:10 [TabAtkinsTPAC]
ishida: Sometimes grapheme clusters aren't sufficient in indic scripts.
11:01:21 [TabAtkinsTPAC]
fantasai: Is that captured in the "extended grapheme cluster" definition?
11:01:36 [TabAtkinsTPAC]
ishida: No. You either need a new definition, or need to punt it to the UAs.
11:01:53 [TabAtkinsTPAC]
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.
11:02:29 [TabAtkinsTPAC]
Bert: Could we call the default 'normal' or 'auto'?
11:03:03 [TabAtkinsTPAC]
howcome: I don't understand what you mean by "not native writing mode".
11:03:16 [TabAtkinsTPAC]
fantasai: horizontal script in a vertical orientation is "non-native", and vice versa.
11:03:58 [TabAtkinsTPAC]
Bert: The default value is the normal way that english is embedded in japanese, so it should have a simple name.
11:04:12 [TabAtkinsTPAC]
ishida: Not always normal - acronyms are often not rotated.
11:04:25 [TabAtkinsTPAC]
fantasai: Those are usually done with fullwidth glyphs, which do their rotation correctly.
11:04:38 [TabAtkinsTPAC]
fantasai: Compat with SVG; we're not using glyph-orientation.
11:04:57 [TabAtkinsTPAC]
fantasai: It doesn't well handle a lot of corner cases. I recommend we not going into the precise details.
11:05:27 [TabAtkinsTPAC]
fantasai: The interaction between text-orientation and glyph-orientation is well-defined, though - text-orientation will by default defer to glyph-orientation in a UA that implements both.
11:06:10 [fantasai]
Make auto value default value for everyone -- maps to vertical-right for impl that don't support glyph-orientation
11:07:24 [TabAtkinsTPAC]
fantasai: Now, text-combine.
11:07:59 [TabAtkinsTPAC]
fantasai: It can be used for an effect called "tate-chu-yoko". It's different from just doing an inline-block, because the combination is treated like a single glyph.
11:08:20 [TabAtkinsTPAC]
jdaggett: I think that since this is a vertical-only property, maybe the name should reflect that.
11:08:30 [TabAtkinsTPAC]
jdaggett: Also we can probably drop the 'cluster' property.
11:09:14 [mjs]
mjs has joined #css
11:09:15 [TabAtkinsTPAC]
ishida: You can have kumimoji (sp?) in horizontal text too.
11:09:40 [TabAtkinsTPAC]
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.
11:10:01 [TabAtkinsTPAC]
jdaggett: I just don't think we want the UAs to synthesize these. A font will have something that looks nice with the text surrounding it.
11:10:24 [TabAtkinsTPAC]
ishida: Then there's warichu (sp?). Are you discounting that?
11:10:33 [TabAtkinsTPAC]
jdaggett: That's a known hard problem. Not currently addressed by this draft.
11:10:47 [dbaron] has pictures of kumimoji and warichu
11:11:07 [TabAtkinsTPAC]
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.
11:11:27 [TabAtkinsTPAC]
jdaggett: Also, some people from the japanese TF came back and said that it's not really good typography to do this.
11:11:41 [TabAtkinsTPAC]
ishida: It makes some sense to me to not bundle it with the tate-chu-yoko.
11:12:13 [TabAtkinsTPAC]
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).
11:12:34 [TabAtkinsTPAC]
jdaggett: It would be nice to say "I want tate-chu-yoko for 2-character runs, but not 3 or more". So maybe a number in the property.
11:13:14 [TabAtkinsTPAC]
jdaggett: Fallback behavior - I think I said behavior that quarter-width falls back to third-width, falls back to half-width, falls back to full-width. I think instead if one doesn't exist it should scale.
11:13:18 [TabAtkinsTPAC]
fantasai: Or just have it overflow.
11:13:39 [TabAtkinsTPAC]
szilles: I think if you had a year that was expeected to be a single line, splitting it into two segments would be confusing.
11:13:41 [TabAtkinsTPAC]
jdaggett: Right.
11:14:56 [TabAtkinsTPAC]
szilles: Also, tate-chu-yoko is sometimes done with letters, for acronyms like "IBM".
11:14:59 [mjs]
mjs has joined #css
11:15:25 [TabAtkinsTPAC]
jdaggett: Unfortunately, fonts have quarter-width numbers much more commonly than letters.
11:15:36 [exr2]
exr2 has joined #css
11:16:01 [TabAtkinsTPAC]
ishida: Perhaps we should ask the Japanese here in our group what they think.
11:16:18 [TabAtkinsTPAC]
dbaron: Also, is falling back to scaling bettere than falling back to no tate-chu-yoko at all?
11:21:08 [mjs]
mjs has joined #css
11:24:37 [seungjae]
seungjae has joined #CSS
11:25:52 [seungjae]
seungjae has joined #CSS
11:27:43 [seungjae]
seungjae has joined #css
11:28:20 [yuma_1986]
yuma_1986 has joined #css
11:30:12 [timeless_mbp]
timeless_mbp has joined #css
11:32:02 [TabAtkinsTPAC]
TabAtkinsTPAC has joined #css
11:39:40 [Zakim]
Zakim has left #CSS
11:52:29 [glazou]
glazou has joined #css
11:54:18 [MikeSmith]
RRSAgent, make minutes
11:54:18 [RRSAgent]
I have made the request to generate MikeSmith
12:08:48 [mollydotcom]
mollydotcom has left #css
12:11:01 [murakami]
murakami has joined #css
12:14:55 [jdaggett]
jdaggett has joined #css
12:22:08 [plinss_]
plinss_ has joined #css
12:25:24 [dsinger]
dsinger has joined #css
12:28:04 [glazou]
glazou has joined #css
12:29:30 [dethbakin]
dethbakin has joined #css
12:29:45 [yuma_1987]
yuma_1987 has joined #css
12:31:12 [timeless_mbp]
timeless_mbp has joined #css
12:31:17 [myakura]
myakura has joined #css
12:32:12 [DavidClarke]
DavidClarke has joined #css
12:32:39 [anthony]
anthony has joined #css
12:32:55 [anthony]
anthony has left #css
12:32:56 [r12a-nb]
r12a-nb has joined #css
12:33:02 [anthony]
anthony has joined #css
12:33:33 [dbaron]
dbaron has joined #css
12:33:40 [joonho]
joonho has joined #css
12:34:07 [shan]
shan has joined #css
12:34:26 [anne]
anne has joined #css
12:35:18 [jun]
jun has joined #css
12:35:50 [mjs]
mjs has joined #css
12:36:05 [freedom]
freedom has joined #css
12:36:32 [shepazu]
shepazu has joined #css
12:37:38 [johnjan]
johnjan has joined #css
12:38:39 [sylvaing]
sylvaing has joined #css
12:38:43 [sylvaing]
scribenick: sylvaing
12:39:48 [timeless]
RRSAgent, make minutes
12:39:48 [RRSAgent]
I have made the request to generate timeless
12:40:07 [sylvaing]
fantasai starts reviewing section 7 of
12:40:11 [dbaron]
12:40:13 [sylvaing]
12:40:40 [sylvaing]
fantasai: i could not come up with a use-case for making overflow-x and overflow-y absolute
12:40:44 [alexmog]
alexmog has joined #css
12:40:51 [sylvaing]
dbaron: people could have an expectation of what x and y map to ?
12:41:05 [sylvaing]
fantasai: so y is the block direction and x is the line direction
12:41:32 [dbaron]
transforms has translateX(), translateY(), skewX(), skewY()
12:41:35 [sylvaing]
jdaggett, dbaron: x and y are used for transforms and map to a physical concept
12:42:24 [homata]
homata has joined #CSS
12:42:30 [Kai]
Kai has joined #css
12:42:40 [sylvaing]
jdaggett: this is a really large change. the use-case is not clear to me.
12:42:53 [szilles]
szilles has joined #css
12:43:10 [sylvaing]
jdaggett: we are talking about transforming coordinate systems within the page
12:44:01 [sylvaing]
plinss: it doesn't mean a true coordinate transform. this is attempting to solve a specific problem.
12:44:31 [fsasaki]
fsasaki has joined #css
12:44:41 [sylvaing]
plinss: it's just keeping overflow-x instead of having overflow-line-progression-direction
12:44:55 [hidetaka]
hidetaka has joined #css
12:45:10 [sylvaing]
dbaron: i think overflow-x and overflow-y horizontal and vertical (respectively)
12:45:32 [dbaron]
... and the spec should use the terms block-axis and inline-axis rather than redefining x-axis and y-axis
12:45:58 [sylvaing]
jdaggett: why does vertical text require these changes ?
12:46:45 [glazou_]
glazou_ has joined #css
12:47:43 [timeless]
12:47:54 [komasshu]
komasshu has joined #css
12:48:01 [sylvaing]
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.
12:48:15 [sylvaing]
jdaggett: if you author content in both modes, yes
12:48:26 [sylvaing]
jdaggett: this is still not related to vertical text
12:48:44 [sylvaing]
aharon: logical properties are not just related to vertical text, they also matter for bidi
12:49:04 [sylvaing]
aharon: the use-case for logical properties - start, end - in bidi is not theoretical
12:49:35 [sylvaing]
aharon: an application that needs to support UI in different languages currently needs to provide different stylesheets.
12:49:49 [sylvaing]
aharon: they're the same stylesheets, one effectively generate from the other
12:49:50 [timeless]
12:49:52 [timeless]
12:50:38 [sylvaing]
aharon: e.g. margin-left in this stylesheet becomes margin-right in the other
12:51:29 [sylvaing]
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
12:51:52 [sylvaing]
jdaggett: authors want to be able to describe what they'll do for this writing-mode vs. that other one.
12:52:44 [sylvaing]
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
12:53:04 [sylvaing]
fantasai: but this should get you 90%+ of what you need. for instance, for a book.
12:53:39 [sylvaing]
howcome: you do want to set different values. duplicating properties does not address the problem
12:54:12 [sylvaing]
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
12:54:51 [sylvaing]
fantasai: is sharing the stylesheet between ltr and rtl a valid use-case ?
12:55:07 [Zakim]
Zakim has joined #CSS
12:55:17 [r12a-nb]
12:55:28 [sylvaing]
fantasai: but if I want to do the same thing for my Japanese translation, it will not work ?
12:56:07 [sylvaing]
jdaggett: this is not at all the same typography. Japanese layout is not rotated english
12:58:27 [sylvaing]
jdaggett: in the webkit UA stylesheet, the default margin for paragraphs is 1em 0px. that's not a valid default for vertical Japanese paragraphs
12:59:23 [fantasai]
koji: Whether paragraphs are separated by 1em margin or no margin + indentation is not a vertical vs. horizontal cas
12:59:26 [fantasai]
12:59:48 [timeless]
ack r12a-nb
12:59:55 [parkjy]
parkjy has joined #css
13:00:36 [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
13:01:31 [r12a-nb]
13:02:47 [sylvaing]
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
13:03:03 [sylvaing]
jdaggett: a default for Latin text cannot be used as a default for Japanese text
13:03:22 [timeless]
ack r12a-nb
13:03:28 [szilles]
13:03:43 [johnjan]
present: koji; dbaron; alexmog; jdaggett; sylvaing; johnjan; szilles; fantasai; plinss; howcome; shan
13:03:43 [timeless]
q+ to ask what percentage of the problem needs to be solved
13:03:53 [timeless]
present+ timeless
13:03:55 [sylvaing]
r12a-nb: I thought the goal was to have the ability to move horizontal japanese to vertical japanese
13:04:03 [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
13:04:22 [fantasai]
fantasai: but for horizontal layout it doesn't matter
13:04:34 [sylvaing]
r12a-nb: I find logical properties much easier to use in practice
13:04:45 [mgylling]
mgylling has joined #css
13:05:17 [sylvaing]
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
13:06:02 [sylvaing]
jdaggett: retrofitting virtual properties in CSS is a large change.
13:06:32 [sylvaing]
jdaggett: this doesn't address all the properties that may need to be affected
13:06:43 [sylvaing]
fantasai: it covers all the properties in CSS2.1
13:06:48 [howcome]
howcome has joined #css
13:07:09 [sylvaing]
jdaggett: but what about CSS3 properties such as border-radius ? what about 2d transforms and their coordinate spaces ?
13:07:30 [sylvaing]
jdaggett: I don't think any of this is required to support vertical text.
13:08:22 [sylvaing]
kojiishi: but what if Japanese users want to be able to change margin and padding logically ?
13:08:41 [sylvaing]
jdaggett: then let's see what we can do for margin and padding
13:11:25 [sylvaing]
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.
13:12:06 [timeless]
13:12:10 [timeless]
ack szilles
13:13:22 [jaeyeollim]
jaeyeollim has joined #CSS
13:13:37 [fantasai]
jdaggett: I don't think we should do this in one fell swoop
13:13:47 [fantasai]
jdaggett: I think we should add start and end keywords where needed e.g. in text-align
13:14:02 [fantasai]
jdaggett: And then for margins and padding, we just add 'logical' keyword to the shorthands
13:14:11 [fantasai]
jdaggett: and not deal with, e.g. border properties
13:14:45 [sylvaing]
kojiishi: so you're questioning the number of properties that should be logical ?
13:14:57 [fantasai]
koji: So you are not against logical properties, you don't agree on the amount
13:15:01 [sylvaing]
jdaggett: I think having a logical keyword in a small set of relevant shorthands is enough
13:15:28 [sylvaing]
kojiishi: so you're not saying all margins should be physical
13:15:42 [sylvaing]
jdaggett: I don't have a problem with retrofitting logical into the margin shorthand
13:15:44 [fantasai]
jdaggett: I think a logical keyword on the margin shorthand is sufficient
13:16:07 [timeless]
RRSAgent, make minutes
13:16:07 [RRSAgent]
I have made the request to generate timeless
13:16:10 [sylvaing]
jdaggett: but we shouldn't try to make everything logical at once
13:16:30 [r12a-nb]
13:16:47 [sylvaing]
discussion of Zakim's feelings follows
13:17:44 [cslye]
cslye has joined #CSS
13:18:20 [sylvaing]
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
13:18:44 [fantasai]
szilles refers to messages on the mailing list that discuss the perf impact
13:18:51 [sylvaing]
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
13:19:05 [sylvaing]
howcome: adding a keyword to a shorthand, otoh, is reasonable
13:19:42 [sylvaing]
howcome: likewise, we could have keywords for inside/outside for printing
13:20:10 [sylvaing]
szilles: so you are OK with the ability to specify certain values in a logical coordinate system
13:20:17 [sylvaing]
howcome: yes
13:20:42 [Aharon]
Aharon has joined #css
13:20:50 [Aharon]
13:21:00 [sylvaing]
r12n-ab asks for an example of the logical keyword
13:21:16 [johnjan]
fantasai fights the flip chart
13:21:37 [myakura]
margin: logical? <length>{1, 4}
13:21:37 [sylvaing]
the physical coordinate of the flip chart rotates in mid-air
13:21:54 [howcome]
margin: script 1em 0px;
13:22:01 [howcome]
margin: writing-mode 1em 0px;
13:22:07 [howcome]
margin: beas 1em 0px; /* before-end-after-start */
13:22:10 [sylvaing]
flip chart now stands in vertical-rl
13:23:03 [howcome]
margin: tobi 1em 0px; /* top-outside-bottom-inside */
13:23:08 [sylvaing]
jdaggett: so the logical keyword means that the shorthand values are slotted to top/right/bottom/left based on the writing-mode
13:23:15 [Bert]
13:23:33 [sylvaing]
jdaggett: this proposal is not what is in the spec
13:23:52 [sylvaing]
szilles: the principal of logical direction has been accept
13:23:59 [timeless]
13:24:00 [sylvaing]
(howls of protest)
13:24:50 [sylvaing]
jdaggett: not by doing this for so many properties
13:24:59 [sylvaing]
(more Mozilla people standing up to make their point)
13:25:23 [timeless]
(references to Dave Hyatt and Webkit)
13:25:28 [fantasai]
dbaron: hyatt implemented it quickly because webkit's architecture makes logical properties easy
13:25:37 [fantasai]
s/architecture/style system architecture/
13:25:49 [timeless]
s/easy/easy based on an assumption which is not required by any specification/
13:25:57 [dbaron]
s/style system architecture/data structure for storage of declarations within declaration blocks/
13:26:27 [fantasai]
koji: But what you're saying is that you accept the idea of logical space, just not of scoping it so widely
13:26:45 [sylvaing]
jdaggett agrees this is about scoping logical
13:27:12 [timeless]
ack Aharon
13:28:11 [sylvaing]
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 ?
13:28:18 [sylvaing]
jdaggett: I don't think we can remove properties
13:28:43 [sylvaing]
aharon: but we may be able to deprecate properties that are harmful to i18n.
13:29:15 [sylvaing]
aharon: it's much easier to add logical than turning left to top etc
13:31:26 [sylvaing]
aharon: 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
13:31:55 [sylvaing]
aharon: we use start/end or absolute-left/absolute-right. 99% of the time, people mean start/end
13:32:07 [fantasai]
13:34:00 [Bert]
13:34:23 [fantasai]
koji agrees with aharon's assessment of physical vs. logical usage; same applies in horizontal vs. vertical
13:35:35 [sylvaing]
aharon: most of the time when authoring a document that needs to be used both ways, logical is very useful
13:37:14 [sylvaing]
fantasai: section 7 is split in multiple sections. 7.1. maps various parts of CSS21. No new values are introduced.
13:37:39 [sylvaing]
fantasai: the only section that introduces new values is for caption-side
13:38:15 [sylvaing]
fantasai: 7.3 is about HTML attributes; for replaced elements they're treated as absolute; on table elements these attributes are logical
13:38:52 [dbaron]
I don't think we should make width and height attributes behave differently for different elements.
13:38:57 [sylvaing]
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
13:39:02 [sylvaing]
fantasai: yes
13:39:44 [sylvaing]
(now addressing dbaron's point)
13:39:59 [sylvaing]
dbaron: I think it's going to be very confusing
13:40:42 [sylvaing]
szilles: the proposal is that for those elements the width and height attribute are interpreted per the writing mode of the element
13:40:54 [sylvaing]
fantasai: yes. the alternative is to ignore them
13:41:34 [sylvaing]
dbaron: I'd rather add new HTML attributes
13:41:39 [sylvaing]
szilles: see the other room
13:42:37 [sylvaing]
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
13:43:02 [sylvaing]
fantasai: section 8.1
13:43:14 [sylvaing]
defines properties that do before/after/start/end
13:44:33 [sylvaing]
dbaron: note that caption-side already has 6 keywords
13:45:27 [sylvaing]
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
13:45:35 [sylvaing]
jdaggett: vertical-align:auto ?
13:45:55 [sylvaing]
howcome: I think adding new values is easier than adding properties
13:47:12 [sylvaing]
13:47:13 [toto]
toto has joined #CSS
13:48:07 [timeless]
13:48:07 [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. ...
13:48:07 [timeless]
13:49:07 [sylvaing]
fantasai: these have always been logical.
13:49:40 [sylvaing]
fantasai: the original proposal was even and odd but if you change the page countering and things get confusing.
13:51:39 [sylvaing]
howcome: I'm not sure we want to use the same stylesheet for an ltr book and an rtl book
13:52:05 [sylvaing]
(arronei agrees with howcome)
13:52:13 [timeless]
13:52:22 [johnjan]
13:53:28 [sylvaing]
aharon: what about front and back ?
13:53:45 [sylvaing]
fantasai: that is usually interpreted as the first and last page
13:53:46 [johnjan]
timeless: arronei pinged me
13:54:54 [johnjan]
13:55:08 [glazou]
s/linen/lanin ?
13:55:23 [toto_]
toto_ has joined #CSS
13:56:08 [sylvaing]
howcome: I think it's too early to spec the printing part of this.
13:56:36 [glazou]
g'luck arron ;-)
13:57:50 [timeless]
[ a discussion of why 8.2 exists ]
13:57:53 [sylvaing]
fantasai: the goal for these sections was to cover all of CSS2.1
13:58:24 [sylvaing]
howcome: I don't think we should proceed until we understand spread layout
13:58:30 [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 ]
13:59:37 [timeless]
[ people explain how the binding side changes based on being LTR or TTB ]
14:00:27 [timeless]
[ moving to 8.3 ]
14:01:24 [dbaron]
14:01:28 [timeless]
[ howcome is asked if he objects to logical-height ]
14:01:34 [timeless]
[ howcome objects to adding anything ]
14:02:10 [timeless]
s/anything/any new properties/
14:02:21 [dbaron]
ack dbaron
14:02:35 [timeless]
q+ dbaron
14:02:37 [dbaron]
ack timeless
14:02:37 [Zakim]
timeless, you wanted to ask what percentage of the problem needs to be solved
14:03:25 [dbaron]
ack dbaron
14:04:46 [fsasaki]
fsasaki has joined #css
14:05:33 [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 ]
14:05:48 [sylvaing]
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
14:06:20 [dbaron]
not really cascade, but store until you cascade
14:07:49 [sylvaing]
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.
14:08:16 [sylvaing]
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
14:09:34 [hidetaka]
hidetaka has joined #css
14:10:39 [sylvaing]
fantasai walks through an explanation of margin shorthand cascade and associated storage required...
14:11:02 [sylvaing]
margin: logical 1em 2em 3em 4em;
14:11:17 [sylvaing]
b e a s
14:11:35 [timeless]
[ fantasai draws a paragraph ]
14:11:36 [jun]
jun has joined #css
14:13:25 [timeless]
margin-top: 5em;
14:13:47 [sylvaing]
p { margin: logical 1em 2em 3em 4em; margin-top: 5em; }
14:14:09 [sylvaing]
fantasai: if you don't store 8 values, margin-top would affect the physical right margin
14:14:31 [TabAtkinsTPAC]
TabAtkinsTPAC has joined #css
14:15:19 [sylvaing]
discussion of how inside/outside is even more fun to implement
14:17:14 [fantasai]
argument was that you only need to store 4 values plus a flag if you only implement the shorthand
14:17:22 [fantasai]
dbaron pointed out that 8 values is necessary
14:17:24 [fantasai]
to store
14:17:32 [fantasai]
fantasai walked through an example so people would understand
14:17:32 [timeless]
14:17:35 [fantasai]
p { b e a s
14:17:35 [fantasai]
margin: logical 1em 2em 3em 4em;
14:17:35 [fantasai]
margin-top: 5em;
14:17:35 [fantasai]
14:17:35 [fantasai]
14:17:37 [fantasai]
14:17:40 [fantasai]
3em | LR ||||||| <del>1em</del> <ins>5em</ins>
14:17:42 [fantasai]
14:17:45 [fantasai]
14:18:42 [sylvaing]
jdaggett: i think just having a shorthand is intuitive for authors.
14:18:58 [sylvaing]
plinss: but you use functionality. you can't just specify the start
14:19:28 [sylvaing]
fantasai: I'm ok with just doing margin and padding for now. but i don't think the shorthands are sufficient
14:19:36 [sylvaing]
plinss: wouldn't you need to do border as well ?
14:19:51 [sylvaing]
fantasai: UA stylesheets only need margin and padding
14:20:08 [plinss_]
14:20:24 [timeless]
[ howcome suggests media queries ]
14:21:00 [hidetaka]
hidetaka has joined #css
14:21:20 [timeless]
scribe has noted that it's time for a break.
14:21:30 [timeless]
the fact that people are talking locally instead of to the group supports this.
14:27:29 [myakura]
RSSAgent, make minutes
14:27:52 [myakura]
RRSAgent, make minutes
14:27:52 [RRSAgent]
I have made the request to generate myakura
14:28:55 [shan]
shan has joined #css
14:30:30 [nimbupani]
nimbupani has joined #css
14:30:47 [nimbupani]
nimbupani has left #css
14:34:10 [arron]
3From what I have gathered over IRC we have talked about these few options for logical properties:
14:34:28 [arron]
3a. leave everything as it is (all physical)
14:34:38 [arron]
3b. create actual logical properties for all relevant cases
14:34:48 [arron]
3c. alter only the shorthand properties to take additional keyword(s)
14:34:58 [arron]
3d. create a small set of logical properties covering only a small set of cases
14:35:08 [arron]
3    d.1. create only margin/padding-(start, end, before, after)
14:35:18 [arron]
3    d.2. create only properties that do not take <length> as a value (e.g. border-*-color)
14:35:27 [arron]
3There might be a few others that I missed from the conversation but I think this covers the scenarios that have been discussed.
14:35:44 [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.
14:39:33 [mgylling]
mgylling has joined #css
14:39:58 [glazou]
glazou has joined #css
14:40:31 [jun]
jun has joined #css
14:43:10 [komasshu]
komasshu has joined #css
14:47:42 [dbaron]
dbaron has joined #css
14:54:16 [szilles]
szilles has joined #css
14:56:47 [freedom]
freedom has joined #css
14:58:03 [mjs]
mjs has joined #css
15:02:51 [TabAtkinsTPAC]
ScribeNick: TabAtkinsTPAC
15:05:05 [johnjan]
johnjan has joined #css
15:05:10 [jdaggett]
15:05:17 [jdaggett]
topic: css3 fonts
15:05:49 [TabAtkinsTPAC]
jdaggett: We've looked at this property before - opentype fonts have the capability to have alternate glyphs.
15:05:59 [TabAtkinsTPAC]
jdaggett: There are many features that let you pick one of severeal alternates.
15:06:20 [TabAtkinsTPAC]
jdaggett: In the past I specified this as just putting in a number to select a glyph. A lot of people objected to this.
15:06:22 [joonho]
joonho has joined #css
15:06:32 [TabAtkinsTPAC]
jdaggett: It doesn't look nice, it doesn't play nice with fallback, etc.
15:07:01 [cslye]
cslye has joined #CSS
15:07:04 [TabAtkinsTPAC]
jdaggett: 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.
15:07:14 [TabAtkinsTPAC]
jdaggett: If the font has that named value defined for it, it's used, otherwise it's ignored.
15:07:27 [TabAtkinsTPAC]
jdaggett: The syntax is a new @-rule, @font-feature-values.
15:07:46 [TabAtkinsTPAC]
jdaggett: Syntax is slightly different than what I had on the list originally.
15:07:55 [TabAtkinsTPAC]
jdaggett: It takes severeal font variant definitions.
15:08:00 [dethbakin]
dethbakin has joined #css
15:08:19 [TabAtkinsTPAC]
jdaggett: Like @font-feature-values Jupiter Sans { swash: delicate 1, flowing 2; }
15:08:51 [TabAtkinsTPAC]
jdaggett: And then "h2 { font-family: Jupiter Sans; } h2::first-letter { font-variant-alternates: swash(delicate); }"
15:09:03 [TabAtkinsTPAC]
jdaggett: There are some features tha tonly take one value, but some take multiple values.
15:09:08 [jdaggett]
15:09:33 [TabAtkinsTPAC]
jdaggett: [shows a font-variant page]
15:09:46 [TabAtkinsTPAC]
jdaggett: This page goes through and defines all the selectors for different font features.
15:09:55 [TabAtkinsTPAC]
jdaggett: So somebody using this font can enable these independently from each other.
15:10:42 [TabAtkinsTPAC]
jdaggett: 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.
15:12:33 [TabAtkinsTPAC]
jdaggett: 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".
15:13:19 [TabAtkinsTPAC]
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.
15:13:40 [TabAtkinsTPAC]
fantasai: Maybe you could swap the name and the feature, so like "{ code: styleset 4 5; }"
15:15:12 [TabAtkinsTPAC]
plinss: And what if you have another @font-feature later that defines another swash variant, frex?
15:15:19 [freedom]
freedom has joined #css
15:15:46 [TabAtkinsTPAC]
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.
15:17:15 [TabAtkinsTPAC]
fantasai: [Here] you have a different things for styleset and character-variant.
15:17:51 [TabAtkinsTPAC]
jdaggett: Right. character variants are just somewhat different than anything else.
15:19:22 [TabAtkinsTPAC]
jdaggett: character-variant is the only feature that takes two values. Everything else takes one value.
15:21:22 [TabAtkinsTPAC]
plinss: Suggestion for fixing the syntax implication - make @styleset, @swash, etc. sub-@rules underneath the @font-variant.
15:21:50 [TabAtkinsTPAC]
[discussion of syntax variants]
15:22:58 [mjs]
mjs has joined #css
15:24:35 [TabAtkinsTPAC]
[appears to be consensus that later definitions for the same property/name should override]
15:26:40 [TabAtkinsTPAC]
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.
15:26:54 [TabAtkinsTPAC]
jdaggett: Are you okay with the syntax difference between character-variant and the other properties?
15:27:14 [TabAtkinsTPAC]
fantasai: It's unfortunate, but not bad enough to overly object to.
15:27:49 [smfr]
smfr has joined #css
15:28:56 [smfr]
RRSAgent: pointer
15:28:56 [RRSAgent]
15:28:59 [fantasai]
15:29:04 [fantasai]
@font-feature-values Jupiter Sans {
15:29:04 [fantasai]
@styleset code 5 6;
15:29:04 [fantasai]
@styleset swishy 5;
15:29:04 [fantasai]
15:29:06 [fantasai]
@font-feature-values Jupiter Sans {
15:29:09 [fantasai]
swash: delicate 1, /* not apply */
15:29:11 [fantasai]
flowing 2,
15:29:14 [fantasai]
delicate 7;
15:29:16 [fantasai]
15:29:19 [fantasai]
@font-feature-values Jupiter Sans {
15:29:21 [fantasai]
swash: delicate 1; /* not apply */
15:29:24 [fantasai]
swash: flowing 2;
15:29:26 [fantasai]
swash: delicate 7;
15:29:29 [fantasai]
15:29:31 [fantasai]
@font-feature-values Jupiter Sans {
15:29:34 [fantasai]
code: styleset 5 6; /* not apply */
15:29:36 [fantasai]
code: styleset 8;
15:29:39 [fantasai]
swishy: styleset 5;
15:29:41 [fantasai]
15:29:42 [yuma_1985]
yuma_1985 has joined #css
15:29:44 [fantasai]
@font-feature-values Jupiter Sans {
15:29:46 [fantasai]
styleset {
15:29:49 [fantasai]
code: 5, 6; /* not apply */
15:29:51 [fantasai]
code: 8;
15:29:54 [fantasai]
swishy: 5, 7, 9;
15:29:56 [fantasai]
15:29:59 [fantasai]
character-variant {
15:30:01 [fantasai]
zeta: 20 3; /* cv20 = 3 */
15:30:04 [fantasai]
15:30:06 [fantasai]
15:31:48 [mjs]
mjs has joined #css
15:35:15 [Aharon]
Aharon has joined #css
15:35:56 [fantasai]
@font-feature-values Jupiter Sans {
15:35:56 [fantasai]
styleset {
15:35:56 [fantasai]
code: 5, 6; /* not apply */
15:35:56 [fantasai]
code: 8;
15:35:56 [fantasai]
swishy: 5, 7, 9;
15:35:58 [fantasai]
15:36:01 [fantasai]
character-variant {
15:36:03 [fantasai]
zeta: 20 3; /* cv20 = 3 */
15:36:06 [fantasai]
gamma: 12 5; /* cv12 = 5 */
15:36:08 [fantasai]
15:36:11 [fantasai]
15:36:13 [fantasai]
@font-feature-values Jupiter Sans {
15:36:16 [fantasai]
@styleset code 5, 6; /* not apply */
15:36:18 [fantasai]
@styleset code 8;
15:36:21 [fantasai]
@styleset swishy 5, 7, 9;
15:36:23 [fantasai]
@character-variant zeta 20 3; /* cv20 = 3 */
15:36:26 [fantasai]
@character-variant gamma 12 5; /* cv12 = 5 */
15:36:28 [fantasai]
15:36:31 [fantasai]
@font-feature-values Jupiter Sans {
15:36:33 [fantasai]
styleset: code 5 6, code 8, swishy 5 7 9;
15:36:36 [fantasai]
character-variant: zeta 20 3, gamma 12 5;
15:36:38 [fantasai]
15:36:41 [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
15:36:57 [mjs]
mjs has joined #css
15:37:40 [fantasai]
fantasai: I think it's better to allow an additive syntax, so either the @styleset syntax or the selector-like one
15:38:06 [fantasai]
fantasai: The selector-like one has additive and overriding behavior that is is very closely analogous to existing CSS syntax
15:38:36 [yongil_jang]
yongil_jang has joined #CSS
15:38:46 [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
15:39:08 [fantasai]
jdaggett: in which case an additive behavior would be better than having a new feature declaration erase the old one
15:45:17 [TabAtkinsTPAC]
Bert: This all seems very complicated for something that is already complex.
15:47:21 [TabAtkinsTPAC]
cslye: Yes, but this isn't a feature that a normal author is going to use anyway. This is basically just for opentype junkies.
15:47:38 [TabAtkinsTPAC]
Bert: I also don't like the fact that the value names are author-created, not standardized.
15:48:56 [TabAtkinsTPAC]
Bert: 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.
15:49:26 [cslye]
cslye has left #CSS
15:49:28 [TabAtkinsTPAC]
jdaggett: That option is also there.
15:49:45 [cslye]
cslye has joined #CSS
15:51:40 [timeless]
[ Digression to talk about Corporate Style Sheets]
15:52:15 [Peter`]
Peter` has joined #css
15:52:24 [fantasai]
Bert argues that this is complicated and people will have to learn it which is bad
15:52:48 [fantasai]
Timeless and Bert discuss corporate style sheets and how this will require them to deal with syntax they don't want to learn
15:53:12 [fantasai]
Peter turns this around and shows that this syntax allows better cascading behavior between corporate global and local style sheets
15:53:29 [fantasai]
Peter: Say I have a corporate style sheet that defines an @font-face rule and that turns on various features
15:53:38 [fantasai]
Peter: I want to turn on an additional two new features.
15:53:58 [fantasai]
Peter: You're saying I have to copy the corporate @font-face rule into my local style sheet and tweak it.
15:54:27 [fantasai]
Peter: A week later, corporate style sheet is updated, tweaking its features to be slightly differen
15:54:30 [fantasai]
15:54:41 [fantasai]
Peter: I don't pick up those changes because my @font-face rule overrides theirs
15:55:27 [fantasai]
Peter: Whereas if I use this syntax, I can pick up those changes because it's additive rather than overriding
15:56:46 [TabAtkinsTPAC]
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.
15:58:55 [timeless]
15:59:29 [bradk]
bradk has joined #css
15:59:46 [mjs]
mjs has joined #css
16:00:40 [fantasai]
dbaron: ping css3-values?
16:01:12 [dbaron]
fantasai, probably should stay here for another half hour
16:01:48 [DavidClarke]
DavidClarke has joined #css
16:02:59 [arron]
I am here
16:04:08 [bradk_]
bradk_ has joined #css
16:10:01 [johnjan]
ah, hi arron.
16:10:22 [johnjan]
we're waiting for the AC meeting to end, I believe.
16:10:27 [johnjan]
15 minutes.
16:10:42 [arron]
ok, that gives me a few minutes to do email.
16:11:37 [glazou]
johnjan: yes official end 17h30
16:13:16 [freedom]
freedom has joined #css
16:13:22 [bradk]
16:14:34 [murakami]
murakami has joined #css
16:19:00 [fantasai]
Topic: MultiCol
16:20:12 [fantasai]
Alex: Why aren't percentages are valid in column-width?
16:20:20 [fantasai]
fantasai: Because it makes more sense to use column-number
16:20:39 [fantasai]
howcome: And doesn't have the problem of what to do with 33% vs 34%
16:20:48 [fantasai]
Alex: Other issue was column rules in overflow columns
16:21:24 [fantasai]
Alex: Are rules drawn between overflow columns?
16:21:27 [fantasai]
howcome: yes
16:21:35 [fantasai]
discussion of column rules between empty columns
16:21:38 [fantasai]
howcome: both of them have to be empty
16:21:49 [fantasai]
Topic: position layout
16:22:07 [TabAtkinsTPAC]
16:22:44 [fantasai]
Tab: Position-layout extends the positioning power by letting you position edges of boxes relative to other arbitrary boxes
16:22:48 [fantasai]
Tab: Some use cases...
16:23:05 [fantasai]
Tab: In Google Docs, for example, when you're doing annotations, you'll attach annotations to particular spans of text
16:23:29 [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
16:23:46 [fantasai]
Tab: Also want to measure this edge from this other edge
16:24:21 [fantasai]
Tab: Our layout for our experimental newsreader app is good, but can only be done with a ton of fragile CSS hacks
16:24:43 [fantasai]
Tab: There are three columns in importance of news
16:24:53 [fantasai]
Tab: and then the rows represent timezones
16:25:37 [fantasai]
Tab: Stories are titles, or title and picture and blurb
16:25:44 [fantasai]
Tab: Want to expand the story to take up the whole width
16:25:53 [fantasai]
Tab: Wound up using a JS constraint solver to do this switching
16:26:18 [fantasai]
Tab: Another issue is resize handles
16:27:23 [fantasai]
Tab: Want to position them relative to whatever image you want to resize
16:27:32 [fantasai]
fantasai: I'm a little concerned about prioritizing work
16:27:54 [fantasai]
fantasai: and you're editing a lot of drafts
16:28:02 [fantasai]
Tab: I want to work on this in the context of the CSSWG
16:28:17 [fantasai]
Tab: Want to have it in the charter
16:28:46 [fantasai]
several concerned about prioritization of work and amount of work items
16:29:02 [fantasai]
Tab: This is somewhat inspired by Daniel's proposals
16:29:03 [fantasai]
Tab: ...
16:29:15 [fantasai]
Tab talks about cycles and breaking cycles in the constraint solver
16:30:34 [fantasai]
Tab talks about expanding functionality of fixed and absolute positioning
16:30:42 [fantasai]
Tab: This is a superset of Daniel's proposal
16:30:56 [shan]
shan has joined #css
16:31:10 [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
16:31:35 [fantasai]
Tab: Don't want to expand beyond positioning. If it gets to complicated, it gets very very tangled
16:31:45 [yongil_jang]
yongil_jang has joined #CSS
16:31:53 [fantasai]
Alex ... Instead of positioning, could be a special layout type
16:32:14 [fantasai]
Alex: Instead of applying positioning anywhere, applies only within a particular element
16:32:26 [fantasai]
Alex: a special kind of contianer
16:32:32 [fantasai]
16:33:14 [fantasai]
Tab: Interesting, but for now, I think I'd want to keep it as extension of positioning.
16:33:29 [fantasai]
Tab: But let's talk and see if we can satisfies the use cases along the lines you're talking about
16:34:06 [fantasai]
No one here objects to putting in charter as low priority
16:34:38 [fantasai]
RESOLVED: add to charter as low priority
16:34:46 [fantasai]
Topic: Transforms
16:35:10 [fantasai]
Tab: Had a question of transforms applied to inlines
16:35:12 [fantasai]
from Simon
16:35:24 [fantasai]
Tab draws some text and a span
16:35:27 [fantasai]
16:35:44 [fantasai]
.... <span>bla bla bla RTL RTL RTL bla</span> ...</p>
16:36:04 [fantasai]
Span breaks across multiple lines
16:36:15 [fantasai]
Tab: When you rotate, how do you rotate?
16:36:22 [fantasai]
Tab: First option is transforms don't apply to inlines
16:36:35 [fantasai]
Tab: Second option is to make a bounding box. Transform the bounding box.
16:37:40 [fantasai]
Tab: Third option is to transform each box of the element independently.
16:38:12 [fantasai]
Tab: Sub-issue: are bidi boxes transformed independently
16:39:36 [fantasai]
fantasai: I would go with the bounding box option
16:40:07 [fantasai]
Tab: what do you do with page breaks/column breaks?
16:40:20 [fantasai]
fantasai: use same bounding box def as for backgrounds
16:41:16 [fantasai]
discussion of relpos
16:41:18 [fantasai]
and how that works
16:41:47 [fantasai]
Anthony: Browsers: Opera and FF, do not rotate text if you put in the span
16:41:52 [fantasai]
Anthony: Mobile solutions do rotate
16:42:01 [freedom]
freedom has left #css
16:42:05 [Zakim]
Zakim has left #CSS
16:42:10 [fantasai]
Anthony: I haven't tried multiline in SVG
16:43:24 [kennyluck]
kennyluck has joined #CSS
16:44:19 [fantasai]
fantasai: I would just use the bounding box definition from the old css3-background drafts. Seems the simplest
16:44:45 [mjs]
mjs has joined #css
16:44:46 [arron]
the simplest would be to not apply transforms to inlines.
16:45:11 [fantasai]
well, true
16:45:50 [RRSAgent]
I have made the request to generate kennyluck
16:45:53 [fantasai]
fantasai: define 2 and mark it at risk (fall back to 1)
16:46:52 [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.)
16:46:57 [fantasai]
Topic: css3-values
16:47:01 [johnjan]
here we go
16:48:04 [fantasai]
dbaron: I don't have anything to say...
16:48:12 [fantasai]
arron, ping
16:48:29 [arron]
I don't see the removal of min/max
16:48:36 [fantasai]
wasn't it marked at-risk?
16:48:39 [arron]
I thought we said we were going to remove those
16:48:46 [fantasai]
no, we were going to mark them at-risk
16:49:18 [fantasai]
16:49:48 [dbaron]
dbaron has joined #css
16:50:39 [arron]
Have all the updates been made? I am not seeing it in the Aug draft. Am I looking at the wrong version?
16:50:54 [glazou]
glazou has joined #css
16:51:31 [fantasai]
?: Haptics proposal sent to www-style a couple months ago
16:51:40 [arron]
Well If the updates have been made I have nothing more on this and we should just publish a new version
16:51:42 [ilkka]
16:52:02 [dbaron]
s/?:/Ilkka Oksanen:/
16:52:24 [fantasai]
Ilkka: Names in proposal not important
16:53:13 [fantasai]
Ilkka: The use case we're trying to fulfill here is devices that have a touchscreen
16:53:30 [fantasai]
Ilkka: can then have tactile feedback that's linked to the user interactions
16:53:56 [fantasai]
Ilkka: Properties are style and strength
16:54:28 [fantasai]
Alex: I know nothing about the area. Looks like different kind of feedback.
16:54:34 [fantasai]
Alex: Seems like analogue of colors or sounds
16:54:57 [fantasai]
Alex: Kind of properties I would expect are ... vibrate ...
16:55:17 [fantasai]
Alex: I would expect that there are selectors that select when to feedback
16:55:25 [dbaron]
Aren't the descriptions of 'unchecked-checkbox' and 'checked-checkbox' backwards?
16:55:26 [fantasai]
Alex: and then style the items
16:55:44 [fantasai]
Tab: Use case is mobile phone applications
16:56:14 [fantasai]
Tab: Using names rather than specifying effects is to match OS conventions
16:56:46 [fantasai]
Alex: Buttons etc. UI elements are in the system. Why doesn't it just launch the appropriate haptics?
16:57:04 [fantasai]
Peter: Use case is for adding button feel to things that arent' actually buttons
16:57:12 [fantasai]
jdaggett: So it's like the system colors?
16:57:45 [timeless]
16:58:10 [dbaron]
and the input[type="radio"] style also seems backwards (shouldn't it be -down rather than -up?)
16:58:13 [fantasai]
Peter: Have an issue where starting activation, ending activation might need separate effects
16:58:19 [fantasai]
Peter: Have same issue with transitions
16:58:56 [fantasai]
Discussion of conferring semantics
16:59:24 [fantasai]
Discussion of triggers
16:59:40 [fantasai]
Alex: Are there hidden triggers that are not available for any other feedback, like color?
16:59:57 [fantasai]
Alex: If a browser implementing this has to implement internal triggers
17:00:10 [fantasai]
Alex: Why not make triggers available to other effects?
17:00:47 [fantasai]
Peter: We had related discussion at Apple wrt transitions -- we don't have ability to trigger transitions in and transitions out
17:01:07 [fantasai]
dbaron: Doesn't seem to be related to :active
17:01:14 [fantasai]
dbaron: Just what happens when you touch the element
17:01:32 [fantasai]
Ilkka: The feedback is not related to how long you touch the element
17:01:51 [fantasai]
Ilkka: When I touch an element on touchscreen, the vibrator is activated
17:02:32 [fantasai]
dbaron: The spec is defining this as an inherited property, which seems reasonable.
17:02:45 [fantasai]
dbaron: Don't see a problem with this applying to things that cannot be :active
17:03:13 [fantasai]
Peter: Does this apply to everything? Or only if I have something that has buttonlike behavior?
17:03:24 [fantasai]
Peter: What happens if I apply unlatch to a <span>?
17:03:25 [hidetaka]
hidetaka has joined #css
17:03:28 [fantasai]
dbaron: Not a good idea to do that?
17:03:37 [cslye]
cslye has left #CSS
17:03:45 [fantasai]
dbaron: I think the default of the type being none is needed
17:03:51 [fantasai]
dbaron: given the strength default is none
17:05:14 [fantasai]
Peter: If I style a <span> like a button and add haptics, will it behave like a button?
17:05:27 [fantasai]
dbaron: No, it just feels like a button when you touch it.
17:05:39 [fantasai]
fantasai: This is like a property to make a sound when you click the mouse on an element.
17:05:45 [fantasai]
fantasai: except it's not a sound
17:05:55 [dbaron]
And the default style sheet shouldn't use '-webkit-'
17:06:12 [jgraham]
jgraham has joined #css
17:08:00 [fantasai]
Peter: There are issues here similar to 'appearance', transitions, etc.
17:08:17 [fantasai]
jdaggett: How common is it for phones to implement all the types you list?
17:08:58 [fantasai]
jdaggett: Or rather, are all UAs on all phones capable of matching those types to something reasonable?
17:09:12 [fantasai]
jdaggett: We have this problem with system colors, where it only maps reasonably in Windows 3
17:10:06 [fantasai]
Peter: So should we scope this into the UI module?
17:10:44 [fantasai]
jdaggett: Also, would you want to do this to other types of feedback? e.g. iphone uses sound
17:11:41 [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
17:11:56 [fantasai]
Meeting closed.
17:12:34 [hidetaka_]
hidetaka_ has joined #css
17:13:50 [myakura]
RRSAgent, make minutes
17:13:50 [RRSAgent]
I have made the request to generate myakura
17:17:22 [homata]
homata has joined #CSS
17:21:30 [myakura]
myakura has joined #css
17:29:06 [plinss_]
plinss_ has joined #css
17:34:02 [arron]
arron has left #css
17:34:18 [arron]
arron has joined #css
18:07:08 [Hixie]
Hixie has joined #css
19:04:56 [dsinger]
dsinger has joined #css
19:38:43 [dsinger]
dsinger has joined #css
19:41:35 [Ms2ger]
Ms2ger has joined #css
19:43:59 [anne]
anne has joined #css
19:44:32 [dsinger]
dsinger has joined #css
20:40:27 [Martijnc]
Martijnc has joined #css
20:41:59 [plinss_]
plinss_ has joined #css
21:16:41 [nimbupani]
nimbupani has joined #css
21:23:55 [hidetaka]
hidetaka has joined #css
22:02:13 [jdaggett]
jdaggett has joined #css
22:31:39 [plinss_]
plinss_ has joined #css
22:37:53 [arronei]
arronei has joined #CSS
22:43:11 [plinss__]
plinss__ has joined #css
23:14:50 [Peter-]
Peter- has joined #css