IRC log of css on 2013-06-07

Timestamps are in UTC.

00:01:21 [MikeSmith]
MikeSmith has joined #css
00:02:13 [MikeSmith]
MikeSmith has left #css
00:03:04 [rhauck]
rhauck has joined #css
00:06:25 [dbaron]
dbaron has joined #css
00:10:12 [zcorpan]
zcorpan has joined #css
00:15:59 [rhauck]
rhauck has left #css
00:16:36 [rhauck]
rhauck has joined #css
00:19:03 [lmclister]
lmclister has joined #css
00:20:21 [SimonSapin]
SimonSapin has joined #css
00:24:03 [leif]
leif has joined #css
00:27:44 [myakura]
myakura has joined #css
00:34:51 [leif1]
leif1 has joined #css
00:40:10 [cabanier]
cabanier has joined #css
00:41:30 [SimonSapin]
SimonSapin has joined #css
00:42:16 [dbaron]
dbaron has joined #css
00:43:19 [dbaron]
trackbot, start meeting
00:43:21 [trackbot]
RRSAgent, make logs member
00:43:21 [Zakim]
Zakim has joined #css
00:43:23 [trackbot]
Zakim, this will be Style_CSS FP
00:43:23 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
00:43:24 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:43:24 [trackbot]
Date: 07 June 2013
00:43:30 [dbaron]
Zakim, remind us in 8 hours to go home
00:43:30 [Zakim]
ok, dbaron
00:43:33 [dbaron]
RRSAgent, make logs public
00:46:04 [leif]
leif has joined #css
00:46:14 [glenn]
glenn has joined #css
00:46:37 [ivan]
ivan has joined #css
00:46:47 [kazutaka]
kazutaka has joined #CSS
00:46:53 [krit]
krit has joined #css
00:47:40 [glazou]
glazou has joined #css
00:47:45 [myakura]
myakura has joined #css
00:47:53 [liam]
liam has joined #css
00:48:17 [plh]
plh has joined #css
00:48:22 [Rossen]
Rossen has joined #css
00:48:24 [glazou]
ScribeNick: Rossen
00:48:36 [Rossen]
topic: Selectors 4
00:50:27 [glazou]
glazou has joined #css
00:54:30 [dbaron]
topic: February-or-so Face-to-Face
00:54:35 [dbaron]
dbaron: want to do a doodle for scheduling
00:55:11 [dbaron]
[discussion of contintents, probably North America's turn]
00:55:17 [dbaron]
[discussion of who can host, and who just hosted]
00:56:16 [Rossen]
Feb is NYC tentative
00:56:35 [dino]
dino has joined #css
00:56:58 [dbaron]
(some were going to look into hosting in California too, I think?)
00:57:08 [liam]
ScribeNick: Liam
00:57:10 [Rossen]
nm last topic... new topic is Grid
00:57:18 [TabAtkins]
00:57:27 [r12a]
r12a has joined #css
00:57:42 [liam]
Tab: section 1...
00:57:54 [liam]
[question of scope from fantasai]
00:58:00 [liam]
question is about snapping items to grid
00:58:12 [liam]
you cn already align things, but this is moer about sizing things
00:58:19 [liam]
00:58:37 [liam]
proposal from Tab is to push snap-to-grid off to a later spec
00:58:44 [liam]
no objections
00:58:52 [liam]
glazou: accepted.
00:59:05 [liam]
tab: section 4.1 issue 3
00:59:21 [liam]
positions of things not explicitly given a grid position
00:59:40 [liam]
01:00:29 [liam]
[Tab goes through the four options in the isue]
01:00:36 [liam]
01:01:17 [liam]
fantasai: [draws on the board]
01:01:26 [liam]
1. always auto-position
01:01:31 [liam]
(by default)
01:01:39 [liam]
2. put unpositioned elements in slot 1 1
01:02:01 [liam]
3. add ability to define a default slot, and then do either 1 or 2
01:02:54 [liam]
bert:first look at area, then look at flow, then look at normal positions just a process
01:03:08 [liam]
tab: this is for the case there's no explicit position
01:03:19 [liam]
Bert: if y udon't have a grid area there's still flow-into that may give you a position
01:03:37 [liam]
fantasai: yuo have a doc, e.g 5 elements in body, and the only style is display:grid on the body
01:04:07 [liam]
so these subelements have no explicit styles at all
01:04:14 [liam]
bert: then they all go into the default slot
01:04:22 [liam]
tab: what happens if yuo don't define a default slot?
01:04:30 [liam]
bert: but 1 1 might be an empty slot
01:04:41 [liam]
Rossen: we currently do 1 1
01:05:02 [liam]
toggling display: grid on/off will have no effect in that case for us
01:05:05 [liam]
if yuo have al lof the in one anyonymous grid item
01:06:02 [liam]
alan: if you had discontiguous elements you might not want to put them all into the same container
01:06:43 [liam]
fantasai: adv. of auto-positioning is that things don't pile on top of each other
01:07:05 [liam]
adv. of everything piling up is tha tyou don't change the size of the grid, but then you can't see the top
01:08:05 [liam]
tab: if you're using grid and not positioning things, you're doing it wrong
01:08:22 [liam]
Rossen, we were strongly considering (4)
01:08:36 [liam]
4. Flow everything together into the default slot.
01:08:59 [liam]
e.g. if there are 3 P elements you get all 3 stacked separately
01:09:24 [liam]
alan: it runs into the complications we had with named flows
01:09:31 [liam]
e.g. margins collapsing
01:09:53 [jet]
jet has joined #css
01:10:19 [jet]
TabAtkins: @door with others
01:11:41 [liam]
tab: floxbox now, all elements get coerced into flex items
01:12:25 [liam]
other option: autoposition everything with autoflow: row
01:12:48 [liam]
margins will no longer collapse when grid is toggled but it'll be more like flexbox
01:13:08 [liam]
fantasai: [agrees]
01:13:08 [liam]
so either autoposition, or do the flow
01:13:16 [liam]
bert: I'd like this to be more compatible with regions
01:13:39 [liam]
tab: wherever we have slot pseudoelements they should be able to accept grid as well
01:13:45 [jdaggett]
jdaggett has joined #css
01:13:52 [liam]
dbaron: I'm concerned about difficulty of implementation
01:13:53 [dbaron]
I'm concerned about the difficulty of doing 4.
01:14:11 [liam]
fantasai: I'm inclined to go with 1
01:14:24 [liam]
alan: 4 isn't quite regions, still in same parent
01:14:32 [dbaron]
fantasai: ... consistent with the way flexbox works, so you switch from flexbox to grid
01:14:36 [liam]
tab: but taking discontiguous flow elements together
01:15:08 [Koji]
Koji has joined #css
01:15:09 [liam]
tab: doing 4 is basically equiv. to taking all the flow items out and then taking what is left
01:15:29 [liam]
and putting it into one big anonymous grid item in the default slot
01:15:48 [jet]
jet has joined #css
01:15:53 [liam]
dbaron: presumably you can't have absolute positioning on grid items
01:15:58 [liam]
tab: right, then it's not a grid item
01:16:09 [liam]
alan: default slot is * or 1 1 if there isn't a * ?
01:16:13 [liam]
tab: [agrees]
01:16:20 [liam]
tab: template draft uses @ for it
01:16:35 [jdovey]
jdovey has joined #css
01:16:41 [liam]
tab: we'll add properties for specifyingit
01:16:56 [liam]
alan: if yo uhave more than one cell marked with a * ?
01:17:02 [liam]
bet: an error if disjoint
01:17:08 [liam]
01:17:52 [liam]
fantasai: [elimination game for other alternatives]
01:18:12 [liam]
1 stacking everything on top of each other, i.e. auto position by default
01:18:20 [liam]
Rossen: that's what we do today
01:18:53 [liam]
4: flow everything together into the default slot.
01:19:24 [liam]
bert: 11 might be empty, "."
01:19:57 [liam]
tab: so, if there's no eplicit default slot define, use a row-major seacrh to find the first non-empty slot and use that.
01:20:03 [liam]
01:21:18 [liam]
alan: if you want to avoid overlap, sometimes you'll have to create a new row.
01:21:56 [liam]
tab: sometimes you'll need to specify a default position
01:22:01 [liam]
bert: ok
01:22:08 [liam]
this is fallback behaviour anyway
01:23:08 [liam]
decision: accept proposal 4 for issue 3 in section 4 of css-grid, flow everything not explicitly grid-positioned together into a single item which is then auto-positioned, into the default slot or the first available slot
01:25:33 [liam]
issue 4, non-children grid items
01:26:02 [liam]
[[ This is a proposal to create the ability to have descendants of a grid item participate in a grid layout, similar to the behavior defined by the Template Layout module. ]]
01:26:31 [liam]
position: grid makes a non-grid item an item in the nearest enclosing grid; if there's no such ancestor the item remains in the flow.
01:26:40 [liam]
dbaron: what if it gives no position?
01:26:53 [liam]
alan: it becomes a grid item
01:27:02 [liam]
tab: so it must be autopostioned
01:27:49 [liam]
tab: how about if we only do this if the item has both position: grid and an explicit position?
01:28:13 [dbaron]
peterl: what about using the fact that it's positioned in a grid instead of using position:grid?
01:28:38 [liam]
tab: we do need an explicit flag, "I want to be a grid item"
01:28:58 [liam]
I'd be fine amending this to say you must also provide explicit positioning in addition to grid: position
01:29:14 [isra]
isra has joined #css
01:29:24 [liam]
If you're positioning to a named area/gridline, and the nearest grid doesn't have that, the spec says keep moving up the tre until yuo find a grid with that line
01:29:30 [liam]
or we could say, you failed
01:29:33 [liam]
s/tre /tree /
01:29:45 [liam]
benefis - you can refer to the page grid anywhere in the document
01:30:21 [liam]
plinss, is that true if you're asking for a line ot in yur grid?
01:30:35 [liam]
fantasai: if you wanted to make that work yuo could just say position:grid on taht item
01:30:42 [liam]
01:31:06 [liam]
tab: a normal line item referencing a line not in its grid just pops up?
01:31:43 [liam]
fantasai: what if you speciy two grid lines and they come from different grids?
01:31:46 [liam]
tab: goes in the first grid it can find
01:32:01 [liam]
bert: so we'reusing the position property to turn this on?
01:32:09 [liam]
tab: yes, if you're not a direct child of a grid
01:32:26 [liam]
we have otehr ways we want to use the position properties so we want to make it an explicit switch
01:32:51 [liam]
bert: you only do that for elements that are themselves of grid items?
01:33:10 [liam]
fantasai: any descendent of a grid can take position: grid and become a participant in that grid
01:33:24 [liam]
tab: what if yuo can't find something with tha tname?
01:33:34 [liam]
maybe they should be autopositioned in the nearest grid?
01:33:51 [projector]
projector has joined #css
01:34:33 [liam]
if you're a grandchild of a grid you need to opt in explicitly, if you're a child it's automatic
01:35:11 [liam]
bert: default, you're inside your parent, that's always the case, so yuo want to become a grid item to be positioned differently, ok
01:35:33 [liam]
Rossen: but if yuo have a name line that doesn't match you'll have a silent fail, Peter was saying, and that's not [good
01:35:34 [liam]
01:35:57 [liam]
if you don't find any lines you should still be positioned in the closest grid you find
01:36:06 [liam]
alan: be good to spearate the fallback from the sub-grid that works
01:36:11 [liam]
tab: [agreed]
01:36:36 [liam]
alan: on the subgrid that works I agree with Peter, display:gri isn't needed, using the grid properties should make you a grid item
01:36:45 [liam]
plinss: nok because there are other uses for the properties
01:36:55 [liam]
tab: section 4.2 has the abspos case
01:37:17 [liam]
[4.2. Absolutely-positioned Grid Children]
01:37:30 [liam]
fantasai: [draws a diagram]
01:37:34 [myakura]
myakura has joined #css
01:38:33 [liam]
fantasai: everything is like abs-pos except that if the containing block is a grid you can position yourself with respect to the grid lines
01:39:09 [liam]
tab, peter [discuss possible changes to abs pos]
01:39:16 [liam]
tab: we don't want to change abs-pos too much
01:39:51 [liam]
plinss: but the abs-pos'd items don't affect the grid layout
01:40:28 [liam]
plinss, what if fixed position?
01:40:40 [liam]
dbaron: with transforms, fixed works like abspos
01:41:02 [liam]
tab: assuming fixed-pos can find a containing grid it should work just like abs
01:41:17 [liam]
tab: example: {
01:41:27 [liam]
grid-row-start: 2, auto
01:41:42 [liam]
grid-col-end: auto
01:41:46 [liam]
01:41:47 [liam]
01:42:21 [liam]
tab: wondering about this only for abs-pos'd items
01:42:33 [liam]
fantasai: if it's all auto you use the outer edge
01:43:05 [liam]
plinss: a little bothered it's different for abspos and grid items
01:43:43 [liam]
plinss: need to make sure auto gets you a regular abs-pos behaviour
01:44:14 [liam]
tabL you can use the grid-col properties to change your containing block, for abs-pos
01:44:45 [glazou]
01:45:30 [liam]
plinss: normal abs positioning of the column edge, [scribe missed]
01:45:33 [r12a]
r12a has joined #css
01:45:50 [myakura]
01:46:05 [liam]
fantasai: if you have a grid ... [draws] that's 1 x 1 , autosized ...
01:47:25 [liam]
my vertical gridlines will be, content edge, and sized out
01:48:09 [liam]
so e.g. align: centre should centre that box (the grid) in the containing block
01:48:26 [liam]
so the abs pos first and last grid line, you'll align to those, wherever they end up being
01:48:33 [liam]
may or may not correspond to the content of th box
01:49:09 [liam]
abspos auto means the normal containing block edge
01:49:27 [liam]
plinss: but if it's a grid item it means something slightly different
01:49:34 [liam]
fantasai, tab: [agree]
01:50:13 [liam]
resolved: abspos for grid items accepted as described in the spec, with auto meaning use padding edge of containing box
01:50:35 [dbaron]
plinss: to clarify, display:grid isn't always an abs pos containing block?
01:50:39 [dbaron]
fantasai, Tab: correct
01:50:48 [liam]
plinss, can we add "containing-block: always"?
01:51:16 [liam]
back to issue 5, non-children grid items
01:51:43 [liam]
plinss: these items only behave oddly if yuo positioni them absolutely
01:52:06 [dbaron]
(plinss arguing that you shouldn't need position:grid, you can just apply the stuff in section 4.1 when not position:absolute)
01:52:07 [liam]
tab: we still want an explicit indicator [for grid-item-ness] so yuo can opt into autoflow
01:52:37 [liam]
plinss, so you can have a position: grid, but only necessary if you don't want auto?
01:52:40 [liam]
tab: yes
01:53:33 [liam]
tab: now have an additional problem, if you have position: grid, a named line, and can't find it
01:53:38 [liam]
so we don't know what grid to put you in
01:53:42 [liam]
we coud say you reman in flow
01:53:52 [liam]
If you're a real grid item
01:53:58 [liam]
your parent is a grid container
01:53:59 [liam]
and we can't find your lines
01:54:02 [liam]
we default you to auto
01:54:07 [liam]
so auto-positioning or default slot
01:54:16 [liam]
if you'er grid descendent we don't want tha tbehaviour
01:54:31 [liam]
so are we OK with saying no, you're not a grid item, if w can't find the line
01:54:37 [liam]
bert: first step is going up the tree
01:54:46 [liam]
maybe all the way up to the page
01:55:02 [liam]
tab: assuming w did that and can't find the grid
01:55:25 [liam]
don't want to put grid items into the default slot
01:55:33 [liam]
so it stays in flow in normal positioning
01:55:48 [liam]
plinns: if autopositioning is turned on there's not reason why we couldn't autoposition it ...
01:56:01 [liam]
so maybe "we do nothing" is the fallback, i.e. ignore the position: grid
01:56:09 [liam]
tab: seems reasonable
01:56:10 [liam]
01:56:58 [liam]
01:57:10 [liam]
alan: so if you have a grid container, one of its direct children, but you put display: grid on it
01:57:25 [liam]
tab: it goes into the default slot, normal flow, position: idd will act like position: static in that case
01:57:33 [stearns]
s/display: grid/position:grid/
01:57:42 [liam]
plinns: it seems to me all direct children of a grid will compute to position: grid
01:57:55 [liam]
bert: that depends on the position property
01:58:05 [liam]
position: static means they arein the normal flow
01:58:22 [r12a]
rrsagent, minutes?
01:58:22 [RRSAgent]
I'm logging. Sorry, nothing found for 'minutes'
01:58:29 [liam]
fantasai: [disagrees]
01:58:39 [r12a]
rrsagent, draft minutes
01:58:39 [RRSAgent]
I have made the request to generate r12a
01:58:50 [liam]
tab: sometimes we do want to put things with position: grid in the default slot, if they are grid items
01:59:05 [liam]
I'd be OK with position computing to grid
01:59:14 [liam]
we don't do it to flexbox but we don't have children there
01:59:24 [liam]
Rossen: how do you break out of your grid in that case?
01:59:39 [liam]
plinss: same as before, you'd use a name of a higher grid line
01:59:47 [liam]
bert: you'd put a div element wrapper in there
02:00:26 [Bert]
(which, of course, is not desirable)
02:00:40 [liam]
fantasai: I don't like that if you're a child of a grid you can suddenly jump around
02:00:52 [liam]
plinns: but aren't immediate children grid items anyway?
02:00:56 [dbaron]
I'm not crazy about all the use of the 'position' property (and 'display:grid' vs. 'position:grid' is especially confusing)
02:01:04 [liam]
fantasai: yes, but nothing makes them jump about out f the grid
02:02:01 [dbaron]
liam: is there a way to prevent content? e.g., third party content: don't want advertiser to position outside of their third-party content?
02:02:07 [dbaron]
tab: use a seamless iframe
02:02:09 [stearns]
+1 dbaron, particularly in that position:grid really means something like supra-grid or jump-into-an-ancestor's-grid
02:02:48 [liam]
dbaron: I'm generally unhappy about adding more uses of the display property
02:03:05 [dbaron]
02:03:13 [dbaron]
(explains IRC comment above)
02:03:35 [liam]
bert: we can reduce by one based on presence of template
02:03:51 [liam]
tab: we wanted an explicit flag
02:04:14 [liam]
you can set none of the properties and you'll be autopositioned
02:04:18 [liam]
bert: which is more common?
02:04:29 [dbaron]
dbaron^: ... since the 'position' property is mostly a list of things that should have been values of 'display' instead
02:04:33 [liam]
fantasai: depends what you're doing, e.g. a catalogue where yuo want items in a grid
02:04:51 [liam]
tab: we can do display: grid-item
02:05:02 [liam]
plinss: but then you lose display: auto
02:05:14 [liam]
tab: current values of position should have been position
02:05:32 [liam]
dbaron: position fixed is really a display value, position relative is an unrelated feature
02:05:50 [liam]
tab: could add display: outside-grid-item
02:05:58 [dbaron]
tab: could add display-outside: grid-item instead of position:grid
02:06:14 [liam]
fantasai: it's getting complicated
02:06:22 [liam]
I like how flex-box is very straight-forward
02:06:44 [liam]
whereas here, when you turn on display: grid, shouldn't soemthing happen?
02:06:44 [dbaron]
s/I like/fantasai: I like/
02:07:06 [liam]
tab: are you saying we should default grid properties to more than a 1x1 grid?
02:07:21 [liam]
fantasai: we don't generally have things jumping around reparenting themselves
02:07:40 [liam]
it should be self-contained, you turn on grid and everything looks like a grid
02:07:47 [liam]
plinss: that _is_ what's going to happen
02:08:22 [liam]
[discussion about reparenting]
02:09:01 [liam]
fantasai: I want the jumping to be opt-out on the jumpee item
02:09:18 [liam]
tab: that only happens if you're using useless grid item properties
02:09:38 [liam]
fantasai: I don't want setting something on a parent to trigger the ability of a child to jump out
02:09:53 [liam]
plinss: the child is already opting into some grid behaviour
02:10:02 [liam]
Rossen: do we need al lthis for level 1?
02:10:05 [liam]
bert: yes!
02:10:19 [liam]
Rossen: I mean the jumping out
02:10:40 [liam]
alan: if we don't do it now, we'd have to invent entirely new properties to get this in the future
02:10:48 [liam]
tab: can possibly do it more simply and interated way right now
02:11:45 [liam]
plinss: if you're explicitly opting in to some grid line, why should you have to turn on another property to make that work?
02:11:59 [liam]
fantasai: [scribe couldn't hear]
02:12:09 [liam]
tab: probably opting in will be needed
02:12:16 [liam]
plinss: position: snap, or something
02:12:32 [liam]
plinss: what if everyone had to say position: grid?
02:12:37 [liam]
and no magical behaviour
02:12:47 [liam]
because now just being a child of a grid makes you magic
02:13:08 [liam]
Bert: this should be like columns, not flexbox
02:13:21 [liam]
tab: but flexbox isn't used in the same case, and neither is columns
02:13:41 [liam]
bert: if you position yourself in the grid you get a position in the grid, doesn't matter if it's your parent
02:13:52 [liam]
tab: opting in to autoposition would have to be explicit
02:14:03 [liam]
couldn't just turnon grid and have everything positioned into row
02:14:04 [liam]
02:15:02 [liam]
fantasai: wants turning display:grid on to make a grid that's one column (if you don't do anything else)
02:15:24 [liam]
tab: skipping
02:15:29 [liam]
4.3 issue 8 visibility
02:15:30 [dbaron]
peterl: better to do other issues for next 15 minutes and come back to this
02:15:44 [liam]
" Or should the track size be set to 0 regardless of its sizing function? "
02:16:07 [liam]
tab: make visibility collapse, remove it from the grid, but still affect on sizing
02:16:22 [liam]
collapse becomes visibility: hidden, except,
02:16:34 [liam]
if everything in a track collapses the track size drops to zero
02:16:42 [liam]
a. is this reasonable?
02:16:56 [liam]
b. should this be intrinsic size ofthe track?
02:17:13 [liam]
dbaron: if you set some of the items to visibility: collpased, no change on track size?
02:17:15 [liam]
tab: yes
02:17:25 [liam]
dbaron: that's not the same as tables
02:17:31 [liam]
bert: you set it on the table row or col
02:17:38 [liam]
dbaron: the intermediate state seems weird
02:17:57 [liam]
if the featre is useful enough to exist, I'd be OK to change for each collapse change
02:18:04 [liam]
tab: then it's same as display: none
02:18:24 [liam]
dbaron: OK, I see why you did what you did
02:18:37 [dbaron]
... but it's still annoying
02:18:49 [liam]
tab: there's a case for table-like behaviour where you can collapse away a col or row, but sounds like it might not be a popular way to do it
02:19:23 [liam]
dbaron: for reference we still haven't defined how the table thing works!
02:19:43 [liam]
tab: probably should kill this section and think about it some more
02:19:55 [liam]
decision: change issue 8 into a more general issue about the feature
02:20:09 [liam]
issue 9
02:20:17 [liam]
[[ ince all three properties define the explicit grid, would it make sense to give them all a common prefix (and possibly a shorthand unifying them, as in Bert's ‘grid’ shorthand)? Current thoughts: ‘grid-template’ as the shorthand, with ‘grid-template-rows/columns/slots’ as the longhands, or ‘grid-definition’ as the shorthand, with ‘grid-definition-rows/columns/template’ as the longhands. Other suggestions welcome.
02:20:18 [liam]
02:20:25 [liam]
s/ ince/ Since/
02:20:46 [liam]
tab: right now you have:
02:20:50 [liam]
02:20:55 [liam]
02:20:58 [liam]
02:20:59 [liam]
02:21:28 [liam]
tab: [suggests some alternate names for the properties]
02:21:59 [liam]
A. grid-template-[rows|columns|slots]
02:22:20 [liam]
B. grid-definition-[rows|columns|slots]
02:22:36 [liam]
dbaron: so the rows and cols properties are really giving the sizes of each column/row
02:22:49 [dbaron]
?: and the number (as does slots)
02:22:50 [liam]
tab: rows and columns also name lines and give the numbers of rows/columns
02:23:25 [dbaron]
02:24:03 [liam]
bert: I used the shorter name for defining grids
02:24:27 [liam]
tab: you'll more likely be using the positioning properties, defs are once per container not once per item
02:24:50 [liam]
bert: I want to use grids more as regions, so I don't need all these row and column properties, just naming the "region" is enough
02:24:52 [shans__]
shans__ has joined #css
02:25:13 [liam]
TabAtkins: tehre are strong use cases for [explicit definition properties]
02:25:28 [liam]
bert: don't like the word definition, maybe "size"?
02:25:43 [liam]
tab: we want a common prefix
02:25:49 [liam]
bert: "grid" is the common prefix
02:26:08 [liam]
fantasai: it's not just sizes, also names
02:26:22 [dbaron]
I'm happy with A or B, probably slightly prefer A.
02:26:42 [jerenkrantz]
prefer A
02:28:04 [dbaron]
tab: I'd love to be able to say grid-rows and grid-columns, but I want grid-row and grid-column more, and don't want both at the same time.
02:28:12 [liam]
tab: maybe we can say "area"?
02:28:40 [dbaron]
tab: replaces A with grid-template-[rows|cols|areas]
02:28:45 [liam]
so, grid-template-[rows|columns|areas]
02:28:51 [liam]
and grid-template is a short-hand using Bert's draft
02:29:52 [Phil_Cupp_]
Phil_Cupp_ has joined #css
02:30:30 [liam]
[discussion of Bert's syntax for shorthand, plinss and tab agree it might need work
02:30:30 [liam]
02:31:09 [liam]
tab: could say it's a slightly odd shorthand, can't omit the template from the shorthand, but this is weird
02:31:12 [liam]
bert: it's not weird!
02:31:59 [liam]
[discussion, do you need to mention the template in the shorthand property?]
02:32:20 [liam]
tab: given a 3x3 you have to do ". . ." ". . ." ".. . ."
02:32:23 [liam]
03:28:41 [sgalineau]
sgalineau has joined #css
03:34:15 [lmclister]
lmclister has joined #css
03:34:44 [rhauck]
rhauck has joined #css
03:39:00 [leif]
leif has joined #css
03:44:37 [sgalineau]
sgalineau has joined #css
03:56:21 [rhauck1]
rhauck1 has joined #css
04:03:01 [rhauck]
rhauck has joined #css
04:04:40 [lmclister]
lmclister has joined #css
04:06:07 [rhauck1]
rhauck1 has joined #css
04:06:33 [myakura]
myakura has joined #css
04:09:43 [kawabata]
kawabata has joined #css
04:10:41 [lmclister]
lmclister has joined #css
04:11:16 [glazou]
ScribeNick: dino
04:11:37 [dino]
tab: we deferred a couple of issues
04:11:44 [shans__]
shans__ has joined #css
04:12:01 [dino]
tab: 1. Position: grid stuff. Peter, Elika and I decided on something.
04:13:05 [dino]
tab: position:grid on anything makes it a grid item, and makes it jump up the tree looking for lines.
04:13:07 [dino]
tab: this leads to interesting auto-placement....
04:13:21 [dino]
dbaron: [interrupts]
04:13:30 [stearns]
normal grid children do not jump up the grid
04:13:39 [dino]
tab: ok, cool.
04:14:33 [dino]
tab: we propose eliminate auto-flow:none, switch initial value to rows (grid-overflow), and have that as the overflow behaviour
04:14:45 [dbaron]
s/overflow/autoflow/ ?
04:15:38 [dino]
tab: this has the benefit that it is close in apparent behaviour to the default cell.
04:15:48 [dino]
(with display: grid)
04:16:01 [dino]
tab: and acts grid-like when you apply more of the grid properties
04:16:09 [dino]
TabAtkins: and matches flexbox more closely
04:17:11 [dino]
TabAtkins: -> unambiguous behaviour when pos:grid items that can't find lines (or are auto). they act the same as a grid child.
04:17:23 [dino]
-> find nearest grid, and become autoflow item there
04:17:40 [dino]
alan: soyou can no longer have pos:grid and have it remain in the flow
04:17:43 [dino]
TabAtkins: correct
04:17:56 [dino]
bert: means i can't use the same grid for templates.
04:18:11 [dino]
TabAtkins: the region behaviour should be addressed separately.
04:18:31 [dino]
TabAtkins: this is simpler overall.
04:18:37 [dino]
Bert: but less useful
04:18:46 [dino]
Bert: everything has to be parent child
04:18:54 [dino]
TabAtkins: no, use position: grid
04:19:06 [dino]
Bert: I want to use props starting with grid. they are useful.
04:19:17 [dino]
Bert: they work like regions. content flows into the grid.
04:19:58 [dino]
Bert: this is reversed. when i set the grid properties on an element, i need to duplicate the properties on children.
04:20:08 [dino]
TabAtkins: (disagrees)
04:20:17 [dino]
TabAtkins: a. regions lets you do everything right now
04:20:25 [dino]
TabAtkins: b. if we want to do this later, it's easy
04:21:06 [dino]
[ Bert requests maintaining existing behaviour. Tab explains that this is like flexbox ]
04:21:27 [dino]
Bert: it is easier if you have markup designed to behave that way. this is not normally the case.
04:21:49 [dino]
Bert: my approach is easier. if you want something floated, you put a property on it. that's what removes it from the normal flow.
04:22:06 [dino]
TabAtkins: i understand there are strong reasons for your way, but my way is much more simple.
04:22:14 [dino]
Bert: they were simple before too
04:22:57 [dino]
elika: the point of having everything become a grid is that display:grid makes things appear like a grid.
04:23:22 [dino]
elika: set rows, you get that number of rows, etc
04:23:45 [dino]
elika: we wanted this for flexbox, and we're following here.
04:24:39 [dino]
TabAtkins: we're proposing to start with this simple model, and add your case later.
04:25:06 [dino]
Bert: both behaviours are useful. the nice thing was that you could use the same properties to set up for both.
04:25:13 [dino]
TabAtkins: you can still do this.
04:25:15 [Rossen]
Rossen has joined #css
04:25:54 [dino]
[ discussion about how many properties each case needs to set ]
04:26:02 [dino]
04:26:28 [dino]
Bert: i've tried many different examples...
04:26:34 [dino]
TabAtkins: all document-centric
04:26:49 [dino]
TabAtkins: app-centric gravitate towards my model
04:27:04 [dino]
Bert: yeah, it is very common to have flowing text. I don't want to have to set two properties.
04:27:19 [dino]
elika: when you have flowing text you normally have a parent/child relationship
04:27:29 [dino]
Bert: disagree.
04:28:13 [dino]
TabAtkins: do that by changing grid:auto-flow into a new value
04:28:32 [dino]
alan: i don't understand how this addresses bert's case
04:28:43 [dino]
TabAtkins: once we add it, it is simple to turn on
04:29:13 [Phil_Cupp]
Phil_Cupp has joined #css
04:29:23 [dino]
Bert: why not have it as part of the shorthand? it could say either the template or a keyword positioning v flowing
04:29:35 [r12a]
r12a has joined #css
04:29:39 [dino]
TabAtkins: right now grid:autoflow is not part of the shorthand. we could add that.
04:30:33 [dino]
TabAtkins: this is not necessarily new stuff, we'd just changing what the auto value does.
04:30:43 [dino]
Bert: you could also use the display property as the switch.
04:31:39 [dino]
TabAtkins: it is simple to add this later. are we happy to change our default behaviour over to this?
04:31:53 [dino]
Bert: flexbox is the wrong model to follow. multicolumn is a better example.
04:32:06 [dino]
TabAtkins: i'm not trying to justify flexbox.
04:32:21 [dino]
TabAtkins: can you live with the change I suggested?
04:32:53 [jdovey]
jdovey has joined #css
04:32:54 [dino]
Bert: it's a radical change
04:32:54 [dino]
TabAtkins: no, it's just the initial value of one property
04:33:01 [dino]
Bert: syntax wise yes. but requires a new template layout model.
04:33:14 [dino]
TabAtkins: [disagrees]
04:33:32 [dino]
Bert: what does the default slot become?
04:33:56 [dino]
TabAtkins: when you use the flowing behaviour you define what the slot is. We don't have to worry about this in default.
04:34:31 [dino]
Bert: [explains a complicated example in a manner that would be difficult to minute, using hand gestures]
04:34:58 [dino]
TabAtkins: [answers the example :]
04:35:46 [dino]
TabAtkins: the two things you can't mix are the two types of auto-positioning. use regions for that.
04:36:29 [dino]
Bert: i have a grid element, with a template, it isn't auto positioned, with some child that I do want positioned
04:36:56 [dino]
Bert: do i then have to use pos:grid
04:36:56 [dino]
04:36:56 [dino]
TabAtkins: no, use grid area
04:36:58 [dino]
TabAtkins: the rest are auto-flowed
04:37:49 [dino]
TabAtkins: look at grid: auto-flow and do what that says
04:38:05 [Rossen]
#grid { grid-auto-flow: rows; display: grid; } #grid > * { grid-area: auto }
04:38:31 [dino]
Rossen: is that enough to get all of the auto positioned in a row?
04:38:44 [Rossen]
#grid { grid-auto-flow: columns; display: grid; } #grid > * { grid-area: auto }
04:39:14 [dino]
TabAtkins: not even that much. just set display:grid.
04:39:41 [dino]
TabAtkins: we're just saying the default value should be grid-auto-flow: rows
04:40:10 [dino]
Bert: you still have to set two properties together
04:40:24 [dino]
TabAtkins: one of them has to be privileged
04:40:54 [dino]
Bert: what is interaction btw flow into and grid area?
04:41:02 [dino]
TabAtkins: i have no idea and don't want to think about it now
04:41:13 [dino]
Bert: we will have to prepare for it
04:41:27 [dino]
TabAtkins: in the regions draft, sure.
04:41:34 [dino]
Bert: flow-into is used, and grid-area is auto....
04:41:38 [dino]
TabAtkins: YES
04:41:40 [dino]
Bert: NO
04:41:43 [dino]
TabAtkins: NO
04:41:45 [dino]
Bert: YES
04:42:27 [dino]
Peter: suggest accepting tab's proposal, bert's objection noted, we will discuss it again.
04:42:52 [dino]
alan: the proposal said you'd change the default and defer auto? could we leave it in the draft for now?
04:42:54 [dino]
TabAtkins: yes.
04:43:11 [dino]
s/defer auto/defer none/
04:43:22 [dbaron]
(grid-autoflow: none)
04:44:39 [dino]
RESOLUTION: accept tab's proposal, bert's objection noted, we will discuss it again (issue marked in spec)
04:44:49 [dino]
TabAtkins: shorthand.
04:45:00 [dino]
TabAtkins: accept bert's shorthand with tiny changes (separators)
04:45:09 [dino]
peter: do this later
04:45:41 [jerenkrantz]
RRSAgent: make minutes
04:45:41 [RRSAgent]
I have made the request to generate jerenkrantz
04:45:50 [dino]
Topic: Font Load Events
04:46:13 [stearns]
04:47:40 [TabAtkins]
04:47:45 [liam]
[tab shows a picture of an earwig]
04:48:05 [jerenkrantz]
Ok all - I need to leave. Those who will be here at AC meeting, I'll see you on Monday. Others, I'll see you on-list! Thanks.
04:48:43 [dino]
JD: there is a problem when loading @font-face. they are lazily loaded. if you never reference the font... no font would be loaded. The flip side is that because it was never loaded, you can't use it.
04:49:48 [dino]
eg. canvas
04:49:48 [dino]
e.g. show a menu of available fonts
04:49:48 [dino]
- you don't know metrics, etc
04:49:48 [dino]
JD: been an issue, many people want a solution.
04:49:48 [dino]
JD: I sketched out a proposal for a FontLoader that hangs off document.
04:49:59 [dino]
JD: gives a way to trigger some loads... just tell me when I'm done.
04:50:10 [dino]
JD: most authors don't need to know specifics
04:50:30 [dino]
JD: there is a more complex use case where they want to know exactly when every font is available
04:50:36 [TabAtkins]
04:50:51 [dino]
JD: two handlers, and a bunch of methods
04:51:12 [dino]
JD: loadFont ( font, text, successCallback, errorCallback )
04:51:39 [dino]
JD: it's the same as the font property
04:52:21 [dino]
JD: text is provided to help selection
04:52:25 [dino]
krit: ???
04:52:35 [dino]
krit: so font is a list of fonts?
04:52:37 [dino]
JD: yes
04:53:53 [dino]
glenn: what are semantics of the text parameter?
04:54:11 [dino]
JD: you go through the characters to see if you need fonts.
04:54:23 [dino]
glenn: Please rename this parameter to something more descriptive.
04:54:48 [dino]
JD: successcallback just tells you when things went ok
04:55:15 [dino]
[ignore that last line]
04:55:18 [glenn]
s/text parameter/text member of LoadFontParameters/
04:55:36 [dino]
JD: explains checkFont and notifyWhenFontReady
04:55:52 [dino]
[ they were obvious so I didn't minute ]
04:56:43 [dino]
TabAtkins: [ explains futures ]
04:57:26 [dino]
TabAtkins: most of the API is "do something and tell me when it completes"
04:57:53 [dino]
TabAtkins: All of John's API is reproduced in my proposal.
04:58:04 [dino]
TabAtkins: e.g. - tell we when everything is ready to draw
04:58:53 [dino]
TabAtkins: ... is ready().. returns a Future
04:59:10 [dino]
TabAtkins: you then register callbacks on the Future...
05:00:00 [dino]
glenn: Is this the first place in the Web ecosystems that is using Futures?
05:00:13 [dino]
TabAtkins: No. e.g. JSON Linked Data.
05:00:35 [dino]
Rossen: How are they different from Promises?
05:00:44 [dino]
TabAtkins: the name has changed, but the same.
05:01:14 [dino]
TabAtkins: The new TAG likes Futures and will be pushing it.
05:01:25 [dino]
Peter: The TAG has consensus that this is a good approach.
05:01:51 [myakura]
myakura has joined #css
05:02:15 [dino]
glenn: I object because this seems like a one-off case and we shouldn't invent new things for this.
05:02:39 [dino]
glenn: if there is a concerted effort to change existing APIs towards this, then i accept it.
05:02:48 [dino]
peter: that is the plan.
05:03:14 [SimonSapin]
05:03:31 [dino]
JD: Microsoft/Rossen and Apple/Dean, have you heard about Promises? Are you using them?
05:03:48 [dino]
Rossen: we shipped them already. they are the way you write apps in Win8.
05:04:44 [dino]
Dean: I have been paying no attention.
05:05:03 [glenn]
s/I object because this seems like a one-off case and we shouldn't invent new things for this./I object unless there is a concerted effort to convert to Futures across the board./
05:05:23 [dino]
Peter: there were two people from mozilla that support this.
05:05:42 [dino]
JD: just concerned about time lag if we have to depend on the feature
05:05:47 [dino]
Glenn: my concern too
05:06:25 [dino]
TabAtkins: there is an answer that avoids time lag. segment the API so that there is part of it that doesn't use Futures. Not as convenient.
05:07:22 [dino]
Dean: It's new features like this that will drive the use of futures, so I support it.
05:08:35 [dino]
TabAtkins describes how JD's proposal merges into his. Basically callbacks become futures.
05:09:34 [nvdbleek]
nvdbleek has joined #css
05:09:47 [dbaron]
onloading is any transition from 0 fonts loading to 1 font loading
05:09:48 [dino]
JD: in my proposal onloading is fired when a font starts loading. onloadingdone fires when all fonts are loaded.
05:09:57 [dbaron]
onloadingdone is any transition from 1 font loading to 0 fonts loading
05:09:58 [dino]
JD: onloadstart fires on each font
05:10:45 [dino]
JD: the difference is that if you want to know when fonts load you have to create a future for each of the fonts
05:10:57 [dino]
TabAtkins: you just want to be notified when fonts load
05:11:59 [dino]
dbaron: Tab, I think you've removed the low-level api that allows people to listen for each font load.
05:12:09 [dino]
TabAtkins: no...
05:12:46 [dino]
JD: e.g. i have an app with a lot of fonts. I want to know when any font loads. I don't want to have to set up a future for each load.
05:13:01 [dino]
TabAtkins: that's a small use case. I suggest waiting for the all loaded event.
05:13:42 [dino]
TabAtkins: it takes a little longer.
05:14:03 [dino]
dbaron: that makes the basic api more complex
05:14:18 [dino]
TabAtkins: no, the basic API is just knowing when all fonts are loaded
05:14:18 [dino]
Krit: ???
05:14:32 [dino]
Liam: Does the spec handle the case when the font failed.
05:14:45 [dino]
05:15:12 [liam]
[answer: yes, I don't have to wait until all fonts have loaded before finding that one failed]
05:15:20 [dino]
dbaron: in tab's proposal, what happens if one loads and one fails?
05:16:55 [dino]
TabAtkins: loading done will fire when they are both finished. the event will have info on which ones worked and which ones didn't/
05:16:59 [dino]
krit: ???
05:17:42 [dino]
JD: it is weird to have a mix of futures and events
05:17:52 [dino]
TabAtkins: it's not too weird
05:18:07 [dino]
Peter: there is a promises-like thing for streaming situations
05:18:22 [ivan]
(A blog of Tab on futures, for those (like me) who do not really know what those are:
05:19:06 [dino]
krit: ???
05:19:19 [dino]
krit: is this API necessary?
05:19:23 [dino]
everyone: YES!!
05:19:39 [dino]
JD: e.g. webkit does not include font loads in the "load" event
05:20:50 [dino]
TabAtkins: Google Docs slaps me every day about this
05:21:15 [dino]
JD: We have a direction.... i'm not completely comfortable, but that's just details.
05:21:43 [dino]
JD: issues - canvas web workers want fonts, but they have no DOM
05:21:58 [dino]
JD: e.g. pdf.js wants to do work on a different thread.
05:23:13 [dino]
JD: But Fonts are tied to a document
05:23:38 [dino]
JD: It seems that the group wants to go in the direction of Futures...
05:23:51 [dino]
glenn: Should we ask for a straw poll.
05:24:20 [dino]
Straw poll: 11 people want a futures-based API. 1 against (for the record, it was Glenn)
05:25:32 [dino]
JD: Next topic - Glenn wanted the ability to turn off all font settings. e.g. font-feature-settings: none.
05:26:08 [dino]
JD: With Open Type, there are a set of features that are required (arabic ligatures), and there are some that are not required but are on by default.
05:26:48 [dino]
JD: I don't see the need.
05:27:14 [dino]
GA: It's a shorthand, so it isn't functionality. In the case where you don't know what features are present in the font, you can't necessarily enumerate all the ones you want turned off.
05:27:38 [dino]
GA: Very useful for testing.
05:27:45 [dino]
GA: You can already turn all these off. it's just a shorthand.
05:28:14 [dino]
GA: If there was a way to enumerate the properties of a font... you could do that.
05:28:29 [dino]
Elika: this is not a shorthand in the typical sense.
05:28:38 [dino]
Dean: "shortcut" not "shorthand"
05:29:21 [dino]
Alan: Glen is saying if there was a way to enumerate all the available features, he might be able to avoid this.
05:29:30 [dino]
fantasai: just list them all
05:29:39 [dino]
GA: there are some custom/private ones
05:29:59 [dino]
glazou: how can I know that ligatures are enabled?
05:29:59 [dino]
GA: you can't
05:30:08 [dino]
JD: you'd turn it off and on and see if there was a difference
05:30:20 [dino]
JD: there is no computed value to check
05:30:35 [dino]
dbaron: this is a low level control property
05:30:59 [jdovey]
jdovey has joined #css
05:31:14 [dino]
JD: I have had this situation as a developer. I don't know what is enabled. I have to iterate through and see what's there.
05:31:34 [dino]
GA: My example is that I get a font from a customer with strange results. I don't have any way to know why.
05:31:43 [dino]
JD: this is a pretty edge use case
05:32:07 [dino]
JD: but it is a weapon of mass destruction too
05:32:07 [dino]
GA: Not really. This is not new - you can already do it.
05:32:39 [dino]
Liam: is there a way to revert the font to its default behaviour
05:32:39 [dino]
GA: But normal means different things for different fonts
05:32:39 [dino]
JD: No.
05:32:54 [dino]
GA: No. It does not mean turn on features.
05:33:05 [dino]
JD: Propose to reject this feature request.
05:33:12 [dino]
GA: I will implement it anyway
05:33:16 [liam]
[yes you can revert to default feature set]
05:33:24 [dino]
Peter: yes, as long as it is prefixed
05:33:44 [dbaron]
alan: I'd object to having this value; too much of a footgun.
05:33:45 [dino]
Alan: I reject to having this as an available feature.
05:33:45 [dbaron]
fantasai: me too
05:34:16 [dino]
RESOLUTION: We will not add Glenn's proposal of font-feature-settings: none
05:34:58 [dino]
RESOLUTION: We will use Promises in the font loading API [From above - I didn't minute it at the time]
05:36:21 [dino]
JD: [shows example of why text decoration on the baseline can cause problems in the synthetic case for superscripts and subscripts ]
05:37:21 [rhauck]
rhauck has joined #css
05:39:12 [dino]
JD: Suggestion: sup and sub metric don't work for text decoration placement. The way to handle this is similar to when all the variants are not in the font, if there are not variant sup or sub glyphs then synthesize. If there are any text decorations we should use the synth glyphs and adjust the decoration
05:40:16 [dino]
fantasai: i can live with that
05:40:16 [dino]
dbaron: i think that is reason
05:40:16 [dino]
05:40:16 [dino]
dbaron: you're saying do the glyphs, then do what text-decoration says
05:40:23 [dbaron]
dbaron: so just doing synthesis and then text decoration stuff will be whatever the text decoration spec says?
05:40:36 [dino]
JD: shows an example from The Guardian with some superscript
05:40:50 [dino]
[which looks like shit]
05:40:51 [lmclister]
lmclister has joined #css
05:41:00 [dino]
[the lines are not equally spaced]
05:42:38 [dino]
[looks much better in chrome with the variants available]
05:43:13 [Bert]
(That's why many authors nowadays set 'sup {line-height: 0}')
05:43:17 [r12a]
05:43:33 [r12a]
05:43:42 [dino]
Leif: on wikipedia has superscripts that are underlined on hover.
05:43:46 [dino]
JD: they get the fallback
05:43:54 [dino]
Leif: is there a way to force synthesis
05:44:10 [dino]
dbaron: it's only for sites that are using this new feature to do supsub
05:44:48 [dino]
JD: However, if they are matched to the font, the text decorations are really hard to see. These variants are small.
05:46:06 [dino]
RESOLUTION: If an element with text-decoration set and font-variant non-normal then we synthesize subs/sups, and then text-decoration follows
05:46:55 [zcorpan]
zcorpan has joined #css
05:47:02 [dbaron]
<br data-duration="900s">
05:47:12 [myakura]
rrsagent, make minutes
05:47:12 [RRSAgent]
I have made the request to generate myakura
05:47:39 [zcorpan]
zcorpan has joined #css
05:49:07 [SimonSapin]
05:51:27 [SimonSapin]
05:56:21 [kawabata]
kawabata has joined #css
05:58:09 [plinss]
rrsagent, pointer?
05:58:09 [RRSAgent]
06:09:29 [leif]
leif has joined #css
06:10:22 [myakura]
myakura has left #css
06:10:32 [myakura]
myakura has joined #css
06:11:19 [leif]
ScribeNick: leif
06:11:34 [leif]
Topic: font-language override
06:11:36 [Rossen]
Rossen has joined #css
06:11:46 [rhauck]
rhauck has joined #css
06:12:21 [lmclister]
lmclister has joined #css
06:12:46 [leif]
jdaggett: OpenType has the ability to have language-specific features
06:12:58 [fantasai]
06:12:58 [trackbot]
Created ISSUE-339 - Http://; please complete additional details at <>.
06:13:07 [fantasai]
06:13:19 [leif]
jdaggett: If a specific language has glyph variants that are more common (e. g. cyrillic), then based on the content language of the element, glyphs are automatically switched.
06:13:34 [leif]
jdaggett: there are cases where the semantic language may not be support by the ont
06:14:05 [leif]
jdaggett: e.g. Serbian and Macedonian uses the same traditions, so you want to say content language is Mac, but want to use a font that only supports Serbian
06:14:23 [leif]
jdaggett: an uncommon use case
06:14:37 [leif]
jdaggett: Some people unfortunately always want to set the low-level feature.
06:14:50 [leif]
jdaggett: They view the property as a way to set the low-level property.
06:15:02 [leif]
jdaggett: fantasai wants a fallback list instead of a single language
06:15:15 [leif]
jdaggett: But when you're specifying it, you know the font, so no need to specify
06:15:48 [leif]
fantasai: But if your font has Macedonian, you should be able to express that that is your first preference.
06:15:54 [leif]
jdaggett: You're asking for a different feature.
06:16:04 [leif]
jdaggett: You want fallback.
06:16:15 [leif]
fantasai: You may or may not get the font that you specify.
06:16:25 [leif]
jdaggett: The point is that when you know the font, youll specify it.
06:16:55 [leif]
stearns: fantasai's use case is recognized, but sometimes you want an override instead of a fallback.
06:17:18 [leif]
r12a: I'm not sure fantasai is asking for a fallback, because a fallback should go back to the language asked for.
06:17:33 [leif]
jdaggett: This mechanism really is an override.
06:17:44 [leif]
fantasai: UC in spec is if your font is missing glyphs
06:18:05 [leif]
fantasai: Depending on which font you end up using, you still want to use the glyphs
06:18:29 [leif]
fantasai: Another case is if you're using Mac. and have a few quotes of Serbian, and want that to work
06:18:49 [leif]
jdaggett: As long as the font supports it, you can have multiple languages, each uses the right lgyphs from the same font.
06:19:02 [zcorpan]
zcorpan has joined #css
06:19:25 [rhauck1]
rhauck1 has joined #css
06:19:35 [leif]
jdaggett: This doesn't feel like a general-purpose feature. I'm worried about getting implementations.
06:19:40 [leif]
jdaggett: Might be at risk.
06:19:50 [leif]
jdaggett: To extend it, means a lot of work defining the fallback.
06:20:15 [leif]
fantasai: I see two UCs: Using a language close to your desired font.
06:20:28 [leif]
fantasai: 2nd case: You want your text to have a consistent typographic style.
06:20:31 [jdovey]
jdovey has joined #css
06:20:43 [leif]
fantasai: If you have a quote from another language, you don't want to suddenly change shapes.
06:21:07 [leif]
fantasai: Use style of surrounding paragraph. In that case, would make sense to have language override to use paragraph's language for that quote.
06:21:29 [leif]
glenn: We need to knowwhat features and languages a font supports.
06:21:47 [leif]
glenn: Having a fallback seems unnecessary, knowing what the font has.
06:22:23 [leif]
fantasai: If font downloading is turned off, and you're using a system font, e.g. on a ebook reader, I don't want the font-language-override to tell me what overrides to use.
06:22:34 [leif]
jdaggett: The fonts on your system are not going to be that sophisticated.
06:22:37 [leif]
fantasai: How do you know?
06:22:50 [leif]
jdaggett: I see your points, but I don't think there's a lot to be gained.
06:23:01 [leif]
stearns: The existence of an override would not preclude a future fallback mechanism.
06:23:17 [leif]
fantasai: The use case we're aiming for, you're telling the font to use the wrong thing.
06:23:20 [zcorpan]
zcorpan has joined #css
06:23:33 [leif]
stearns: In all the mailing list feedback, they're talking about an override where they know the font.
06:23:43 [leif]
fantasai: But that's not always the case while loading the page
06:24:22 [leif]
jdaggett: A system font won't have all these features.
06:24:34 [leif]
jdaggett: Straw poll…?
06:24:48 [leif]
glazou: fantasai, can you live with no change?
06:24:55 [leif]
fantasai: I don't understand the objection to fallback
06:25:06 [leif]
jdaggett: You're asking for more work, and I want to get the spec don.e
06:25:14 [leif]
jdaggett: The feature is at risk anyways.
06:25:59 [leif]
jdaggett: Prefer something simple that's actually implemented, then we'll go from there.
06:26:19 [leif]
glazou: We've said for other things that "this is interesting, but we'll move forward"
06:26:37 [leif]
fantasai: I can live with it. I just don't agree with the attitude "I know what fonts I have".
06:27:19 [leif]
jdaggett: It can go on the css4-fonts wiki page.
06:27:22 [leif]
glazou: or log an issue
06:27:39 [leif]
glenn: Do you define that this string must be a case-sensitive match to opentype language?
06:27:50 [dbaron]
fantasai, In theory, I'd agree, except the odds of a user happening to have a font with language-specific features already is probably pretty low
06:27:55 [leif]
glenn: Should be case-sensitive
06:28:07 [leif]
jdaggett: Have to look at that.
06:28:17 [leif]
jdaggett: Lots of case-sensitivity stuff sprinkled around.
06:28:47 [leif]
fantasai: Spec doesn't specify case-sensitivity, and I raised that as an issue.
06:29:19 [leif]
jdaggett: Can discuss Text on the mailing list.
06:29:39 [leif]
r12: spec says it's case sensitive
06:29:50 [leif]
Topic: Backporting level 3 changes to 2.1
06:30:28 [leif]
fantasai: My principle is that a change to L3 spec that would make a 2.1-compliant UA incompliant, that change needs to be backported.
06:30:39 [leif]
fantasai: A L3 client should also be L2 client.
06:31:01 [leif]
dbaron: Slight modification: if the change would make _all_ clients non-compliant.
06:31:15 [fantasai]
s/clients/2.1 clients
06:31:30 [leif]
TabAtkins: If there is an error in 2.1 fixed in 3, then should backport.
06:31:47 [leif]
fantasai: Level 3 can tighten definitions, that should be backported.
06:32:02 [fantasai]
06:32:09 [leif]
dbaron: If it would break content, we shouldn't be making the change.
06:32:49 [leif]
SimonSapin: When do we stop fixing CSS 2.1?
06:33:01 [leif]
fantasai: When the spec has been completely superseded.
06:33:23 [leif]
peter: when a module has replaced parts of it?
06:33:29 [leif]
TabAtkins: No, when it's completely replaced.
06:34:05 [leif]
fantasai: A L3 spec will replace parts of CSS 2.1
06:34:29 [leif]
SimonSapin: Can we deprecate parts of 2.1?
06:35:00 [leif]
fantasai: We tend to find issues in sections that haven't been rewritten, so I don't worry about it. If they've been rewritten, then we've found the inconsistencies.
06:35:38 [leif]
peter: Does everyone agree to that proposal?
06:35:55 [leif]
TabAtkins: Might not be worth it always, like every syntax change, but as a general principle, yes
06:36:02 [leif]
fantasai: Syntax may actually be the most important.
06:36:15 [leif]
TabAtkins: They're just really hard to get right.
06:36:32 [leif]
SimonSapin: We should be able to deprecate one chapter.
06:36:46 [leif]
glazou: What will be the result? 2.1 rev 2, or 2.2?
06:36:57 [leif]
dbaron: 2.2 eventually, but not as much effort as 2.1.
06:37:04 [leif]
glazou: People should be able to refer to 2.1
06:37:14 [leif]
liam: small changes -> 2nd edition.
06:37:23 [leif]
dbaron, liam: could be confusing.
06:37:50 [leif]
Bert: Pick some time in the future, then bundle and publish errata
06:39:10 [leif]
SimonSapin: What's the conclusion?
06:39:18 [leif]
fantasai, glazou: As outlined above.
06:39:25 [leif]
Bert: We should pick a date
06:39:31 [leif]
fantasai: We already picked this F2F
06:39:39 [leif]
Bert: Assign someone to follow-up?
06:40:24 [leif]
Bert: I have some other publications to do after the summer. Can follow it up October or after.
06:40:46 [leif]
glazou: Let's decide later.
06:41:25 [leif]
Topic: Text Decoration
06:41:32 [Ms2ger]
Ms2ger has joined #css
06:41:37 [fantasai]
06:42:24 [leif]
fantasai: Main issue: Position of underlines if you have an entire paragraph underlined
06:42:30 [leif]
fantasai: Where should the underline be placed?
06:42:44 [koji]
koji has joined #css
06:42:48 [leif]
fantasai draws on whiteboard: big and small text within an element
06:43:01 [leif]
fantasai: Do we use the ancestor's underline? 2.1 leaves this undefined.
06:43:30 [leif]
fantasai: Rossen posted a TC where if each line has different sizes, they get different sizes
06:43:44 [leif]
dbaron: That's contrary to the 2.1 model.
06:43:55 [leif]
fantasai: We want to have one line.
06:44:28 [fantasai]
06:45:03 [leif]
fantasai: for web compat, we probably need to stick with that behavior.
06:45:16 [leif]
dbaron: In Gecko, the underline is constant thickness.
06:45:19 [leif]
dbaron: and position
06:45:28 [leif]
dbaron: There were a bunch of tradeoffs in implemnting 2.1
06:45:36 [leif]
dbaron: We got rid of quirks mode in text decoration
06:45:46 [leif]
dbaron: There was a quirk that wasn't compatible enough with 2.1
06:45:57 [leif]
dbaron: We came up with a new, unitary model for decorations.
06:46:12 [leif]
dbaron: One of the importnat requirements: Not do ransom-note style underlining
06:46:25 [leif]
dbaron: if it crossed multiple pieces of text, you got a single undeline.
06:46:38 [leif]
dbaron: The underline comes from the element with the text-decoration property.
06:46:55 [leif]
dbaron: The spec implid that the position and thickness come from that element.
06:47:15 [leif]
dbaron: The 2.1 spec has one part where we disagreed about the grammar.
06:47:42 [leif]
jdaggett: What about vertical-aligin variatons?
06:48:07 [leif]
dbaron: In 2.1 the underline is generated by the element with the text-decoration property. The various properties of the underline come from that.
06:48:15 [leif]
dbaron: So superscript and subscript come from that.
06:48:21 [leif]
dbaron: But there was a quirk.
06:48:28 [leif]
dbaron: so be careful.
06:48:47 [leif]
dbaron: fantasai's proposing that we switch to a model where we don't just use info from that model, but also its descendents.
06:48:58 [leif]
dbaron: The union of them and all their fonts.
06:49:07 [leif]
dbaron: Problematic because it's hard to implement and is slow
06:49:17 [leif]
dbaron: and it breaks a number of invariants authors don't realize they depend on.
06:49:40 [leif]
dbaron: Authors would be surprised if they have six things underlined, and one of the them is subscripted, and behavior changes.
06:49:55 [leif]
fantasai: They'd also be surprised when underline goes through subscript.
06:50:05 [leif]
dbaron: Yes, one author problem is fixed, another is caused.
06:50:27 [leif]
Bert: One solution that we discussed about crossing the subscript is to interrupt the udnerline.
06:50:35 [leif]
dbaron: The text-decoration model has a property to allow that.
06:50:45 [fantasai]
Previous discussion on exactly this topic:
06:50:49 [leif]
r12a: isn't another solution to put a text-decor property on the subscript
06:50:54 [leif]
dbaron: That needs canceling out
06:50:57 [leif]
fantasai: Deferred to level 4
06:51:25 [leif]
dbaron: Some people say text-decor feels like an inherited property,but it's not, to allow even baseline and thickness for entire element.
06:51:42 [leif]
dbaron: I feel like this change would add a lot of complexity to fix one problem and cause another.
06:51:48 [leif]
fantasai: We discussed this last year.
06:52:15 [leif]
fantasai: Aryeh sent feedback that big text in strikthrough, the big text isn't striked through
06:52:24 [leif]
fantasai: That resulted in the current text.
06:52:34 [leif]
dbaron: I didn't understand it sufficiently at the time.
06:52:44 [leif]
dbaron: I would not have agreed to averaging over descendants.
06:53:24 [leif]
fantasai: So how can we solve both problems at once?
06:53:34 [leif]
dbaron: We don't have a reasonable solutoin yet. We should stick with the existing model.
06:53:50 [leif]
fantasai: Then I have to tell Aryeh that we're reverting the fix for his problem.
06:53:55 [leif]
dbaron: We can't fix everything.
06:54:14 [leif]
dbaron: And I really don't want to rewrite our text-decoration code every two eyars.
06:55:13 [leif]
RESOLVED: Revert the change to text-decoration behavior and go back to Last Call.
06:55:38 [leif]
fantasai: Actually, this was a clarification, and we don't want to go back, we want something completely different.
06:55:55 [leif]
glazou: Other text-decoration issues/
06:55:56 [leif]
06:56:16 [leif]
Bert: We're already in LC, we will have another one.
06:56:39 [leif]
liam: If I take the obscure big-text example, and I add an underline in the middle of the big text, it gets its own, thicker underline?
06:56:55 [leif]
fantasai: If you put a span in there, it gets a suitable underline.
06:57:04 [leif]
liam: Lots of test cases needed here!
06:57:39 [leif]
dbaron: If you specify three underlines on three elements, you should get three, even if they might cover eachother up
06:57:43 [liam]
[ - example ]
06:58:10 [leif]
s/and go back to Last Call//
06:58:29 [jdaggett]
rrsagent, make minutes pretty please
06:58:29 [RRSAgent]
I'm logging. I don't understand 'make minutes pretty', jdaggett. Try /msg RRSAgent help
06:58:37 [jdaggett]
rrsagent, make minutes
06:58:37 [RRSAgent]
I have made the request to generate jdaggett
06:59:17 [leif]
Topic: pseudo-stacking contexts
07:00:21 [leif]
dbaron: At some point we discussed whether flex items should be psc, and we decided that they should
07:00:30 [leif]
dbaron: but table cells should be too.
07:00:42 [leif]
dbaron: But then: table backgrounds and borders are complicated
07:00:50 [leif]
dbaron: should they be included in the psc?
07:01:37 [leif]
dbaron: Four issues with table backgrounds and borders:
07:01:43 [leif]
dbaron: backbrounds versus borders
07:01:50 [leif]
dbaron: separated vs. collapsed
07:01:57 [leif]
dbaron: Okay with different answers for those
07:02:23 [leif]
dbaron: But don't want different answers for backgrounds for separated vs. colapses
07:02:59 [leif]
dbaron: If we look at appendix E of 2.1
07:03:37 [leif]
dbaron: Table background painting is already described as part of the z-order in 2.1
07:04:20 [leif]
dbaron quotes the spec
07:04:31 [leif]
dbaron: Table through cell are painted in the backgrounds layer
07:04:52 [leif]
dbaron: That says that if table cells establish a PSC, that even cellbackgrounds are not inside it
07:05:02 [leif]
dbaron: Because painting them is associated with the table
07:05:17 [leif]
… At this point I've already explicitly disagreed with fantasai and TabAtkins
07:05:28 [leif]
… But I'm against changing any of this.
07:05:43 [leif]
… table borders are also painted in this layer.
07:06:01 [leif]
… This is a bit ambiguous
07:06:02 [jdovey]
jdovey has joined #css
07:06:42 [leif]
… If we don't change it , then all we need to do is decide that tables form SC
07:06:48 [leif]
… and cells are not part of that SC
07:07:06 [leif]
fantasai: If we transform a table cell with backgrounds and borders, what do I get?
07:07:17 [leif]
dbaron: the interesting part: do borders and backgrounds even move?
07:07:26 [leif]
… in the collapsed model, shouldn't move.
07:08:00 [leif]
fantasai: In some impls, if you set a transform, the backbround paints on top of the border.
07:08:04 [leif]
dbaron: A bug.
07:08:10 [leif]
dbaron: and poorly tested
07:08:17 [leif]
fantasai: Probably all the implementations.
07:08:24 [leif]
dbaron: I'm ok with cells being PSCs
07:08:35 [leif]
dbaron: if it means that the PSC doesn't include the border and background
07:08:45 [leif]
… Need a lot more work to define paint order inside cells.
07:09:34 [leif]
… Are people ok with what cells being PSCs means?
07:09:38 [leif]
… if so, just resolve.
07:09:48 [leif]
TabAtkins agrees.
07:10:57 [dbaron]
RESOLVED: table cells do create pseudo stacking-contexts (as resolved before) but borders and backgrounds (of the cell or its ancestors) are not in that pseudo stacking-context
07:11:44 [leif]
jdaggett: When we publish a new spec, since the TR URL changes, do we need permission from plh?
07:11:48 [leif]
plh: yes
07:12:04 [leif]
jdaggett: can we get css3-fonts changed to css-fonts-3?
07:12:18 [leif]
fantasai: Was going to do it all at once but can do it piecemeal
07:12:23 [leif]
plh: I agree with the change
07:12:49 [leif]
plh: All specs should be consistent
07:13:06 [leif]
Bert: But will be hard to find old mailing-list messages
07:13:12 [leif]
plinss: It's already been resolved.
07:13:32 [leif]
Topic: Text decoration, one more issue
07:13:58 [leif]
fantasai: text-underline-position: alphabetic
07:14:06 [leif]
… says use font metrics
07:14:09 [leif]
… is that reasonable?
07:14:16 [leif]
jdaggett: Sounds like existing behavior.
07:14:33 [leif]
dbaron: Part of the question is what the underlining metrics in CJK fonts look like
07:14:38 [leif]
dbaron: Ideographic baseline?
07:14:48 [koji]
koji has joined #css
07:14:48 [leif]
jdaggett: have to look it up
07:14:53 [leif]
dbaron: What is existing behavior?
07:14:56 [koji]
07:15:10 [leif]
fantasai: auto behavior says to do whatever you want, but don't cross through glyphs that shouldn't be
07:15:30 [leif]
jdaggett: We have a blacklist of fonts in Gecko, where we modify the underline if it's in the blacklist.
07:15:51 [leif]
… That is more that the underline metrics are not in line with the font
07:16:09 [leif]
fantasai: It's suggested that this property should do the right thing for the text, in cases like cjk.
07:16:21 [leif]
jdaggett: My concern: different fonts on the line, would the underline vary?
07:16:28 [leif]
fantasai: No, would pick one position for the underline.
07:16:50 [leif]
… Currently pick the lowest alphabetic position, but dbaron said we shouldn't do that. That gives interesting results if not baseline-aligned.
07:17:01 [leif]
dbaron: The spec has two values, with auto the initial value.
07:17:16 [leif]
… not clear to me how auto matches current behavior or how implementable alphabetic is.
07:17:25 [leif]
… also how useful alphabetic was
07:17:39 [leif]
jdaggett: I got an e-mail about this…
07:17:58 [leif]
… Not clear to me what you mean by 'alphabetic'. Are you trying to override the font metrics.
07:18:00 [leif]
07:18:15 [leif]
… Are you basing it on the baseline?
07:18:24 [leif]
fantasai: Expectation that font specifies the position of the baseline
07:18:35 [leif]
… You might want to underline the bottom , accounting underline…
07:18:52 [leif]
jdaggett: You use the metrics to infer where the unerline would be relative to the baseline?
07:18:54 [leif]
fantasai: yes
07:19:00 [leif]
jdaggett: What happens to implementations?
07:19:23 [leif]
dbaron: Depends on how well 'auto' match implementations and how hard to implement alphabetic.
07:19:39 [leif]
ACTION jdaggett to investigate those two questions
07:19:40 [trackbot]
Created ACTION-564 - Investigate those two questions [on John Daggett - due 2013-06-14].
07:20:21 [leif]
Topic: Reversing interrupted transitions
07:20:28 [leif]
dbaron: Haven't quite finished my test case
07:20:42 [leif]
… one algorithm and one proposal implemented, still need to impl the other one.
07:20:50 [leif]
… in javascript
07:21:03 [leif]
… Don't leave the page open in a tab after using it!
07:21:14 [leif]
plinss: Let's get back to that.
07:21:34 [leif]
Topic: white space in media queries
07:21:59 [leif]
SimonSapin: We had an issue in both MQ and @supports
07:22:20 [leif]
SimonSapin describes the issue
07:22:44 [leif]
SimonSapin: The grammar had optional white space, meaning that if you used a comment to separate the tokens, it would be correct
07:22:52 [leif]
… reader may not know this detail
07:23:02 [leif]
… We changed the grammar to allow whitespace, like calc()
07:23:22 [leif]
… Issue is resoled in @supports, but still exists in MQ. We should make the same change, but we have to wonder about compat.
07:23:27 [leif]
dbaron: I don't worry about compat.
07:23:36 [leif]
TabAtkins explains on whiteboard
07:23:58 [leif]
TabAtkins: @media screen and/**/(color) — is that correct?
07:24:30 [leif]
SimonSapin: With the current spec, and(color) looks correct, and it is not
07:24:56 [leif]
TabAtkins: This problem applies to every ident in a parenthesis that can be next to eachother without being a function
07:25:03 [leif]
dbaron: This is the problem with the function token
07:25:16 [leif]
SimonSapin: Can use the function token in the grammar, but that is more complicated. Don't want to do that
07:25:19 [leif]
TabAtkins: Agreed.
07:25:54 [leif]
glazou: Shall we adopt SimonSapin's proposal?
07:26:05 [SimonSapin]
SimonSapin: decided not to do function tokens in @supports
07:26:16 [leif]
… require shite-space in MQs
07:26:19 [leif]
07:26:31 [leif]
TabAtkins: This will come up every time we have parentheses
07:26:43 [leif]
plinss: As long as you have some token between, should be valid.
07:26:51 [leif]
… But want it to be consistent.
07:27:09 [leif]
glazou: People expect it to work, because it's * in the grammar.
07:27:17 [leif]
Bert: Can just add a comment in the grammar.
07:27:43 [leif]
plinss: But have to do it everywhere. But I don't feel strongly about and(color). Just want it consistent.
07:28:02 [leif]
glazou: Why is white-space required in @supports?
07:28:14 [leif]
TabAtkins: To avoid that removing a comment changes the meaning.
07:28:34 [leif]
SimonSapin: @supports now requires white-space on both sides.
07:28:50 [leif]
plinss: Need to adopt this anywhere we have parens.
07:29:04 [leif]
glazou: Not everywhere, just when it's not a function.
07:29:12 [leif]
plinss: Don't want white-space in nested parens.
07:29:25 [leif]
TabAtkins: Any time an IDENT is next to a parenthesis, we require white-space.
07:29:37 [leif]
plinss: on the outside of either parenthesis.
07:29:55 [leif]
RESOLVED: MQ requires white-space on both sides of a parenthesis
07:30:04 [leif]
Bert: Don't require it in the font shorthand
07:30:14 [leif]
… basically the same case.
07:30:47 [leif]
… If you have the font shorthand. "font: Times/**/10pt" is fine, but omit comment is not.
07:30:58 [leif]
plinss: Times10pt becomes one item
07:31:17 [leif]
SimonSapin: If you aren't familiar with the tokenizer, it's much more understandable than with parentheses.
07:31:24 [leif]
Bert: But we're talking about consistency
07:31:31 [leif]
plinss: Really only an issue with parentheses.
07:31:44 [Koji_]
Koji_ has joined #css
07:32:02 [leif]
Bert: An issue with all tokens with more than one character. Also with the ~= or the ||.
07:32:15 [leif]
plinss: That's an interesting change, going back to syntax.
07:32:35 [leif]
… if the attribute matcher becomes one token if they had a comment between before
07:32:40 [leif]
… that's a functional change.
07:32:47 [leif]
TabAtkins: A precedent of ignoring comments in weird places.
07:32:55 [leif]
plinss: They kind of deserve it.
07:33:16 [leif]
Bert: I guess I'm not sure which is better, but doesn't seem like a big problem at the moment. Can't see the big story yet.
07:33:22 [leif]
TabAtkins: Where would we define this?
07:33:28 [leif]
… Values and Units?
07:33:34 [leif]
… because it changes the prop grammar.
07:33:39 [leif]
plinss: Syntax?
07:33:53 [leif]
… it's a fundamental thing.
07:34:09 [leif]
TabAtkins: Don't want a resolution that requires us to re-ask about it.
07:34:54 [leif]
RESOLVED: white-space between any IDENT an the outside of a parenthesis.
07:35:12 [leif]
SimonSapin: The proposal was to require white-space on both sides.
07:35:16 [leif]
plinss: Yes, do that everywhere
07:35:29 [leif]
TabAtkins: That's what we require in @supports.
07:35:44 [SimonSapin]
plinss: yes, both )<ident> and <ident>(
07:36:01 [leif]
Bert: Just came to mind: can make 'and' a keyword, so it can be followed by paren.
07:36:13 [leif]
TabAtkins: The issue is not related to 'and' specifically.
07:36:21 [leif]
… Anytime you have keywords next to parens.
07:36:36 [leif]
… Anytime a paren is valid by itself and an ident is valid next to it.
07:37:01 [leif]
TabAtkins: One example is in grid syntax, if we switch to named line syntax
07:37:19 [leif]
… (x y)auto needs white space.
07:37:30 [leif]
… so no tightly-bounded set of keywords.
07:38:00 [leif]
TabAtkins: All parentheses, or just naked parentheses? what about an ident following a function?
07:38:16 [leif]
… function, the concept, not the token.
07:38:33 [leif]
plinss: could it be a compat risk?
07:38:40 [leif]
… ident after function.
07:38:57 [leif]
fantasai: Yeah, gradient followed by length in background shorthand. A likely typo.
07:39:07 [leif]
plinss: So we can't require it everywhere.
07:39:13 [leif]
TabAtkins: So only naked parenthesis groups
07:39:26 [leif]
plinss: We don't have naked parentheses anywhere else, so not a problem
07:39:32 [leif]
dbaron: We have it inside calc()
07:39:37 [leif]
TabAtkins: But you never have an ident.
07:39:44 [leif]
… Need a delim, no implied multiplication.
07:40:12 [leif]
fantasai: One reason why we feel it's awkard and want symmetry in MQ and @supports is that they are conjunctions.
07:40:23 [leif]
… I'm happy if we just require it for conjunctions.
07:40:49 [leif]
TabAtkins: If we did that, and didn't care about end parens, we could just make the parser recognize and( as a function token.
07:40:55 [leif]
… dropping the comment.
07:41:02 [leif]
… and be invalid.
07:41:07 [leif]
plinss: I guess that's fine
07:41:12 [leif]
TabAtkins: Can handle it either way
07:41:21 [leif]
plinss: No, I don't think that's fine.
07:41:29 [leif]
… url/**/( is not a URL token
07:41:35 [leif]
… That would turn it into a function.
07:41:40 [leif]
… making it valid.
07:41:57 [leif]
TabAtkins: Handle it as grammar then.
07:42:26 [leif]
… idents followed by open parenthesis must have white space between the two unless it's a function.
07:42:50 [leif]
RESOLVED: (replaces previous resolution) Idents followed by open parenthesis must have white space between the two unless it's a function.
07:43:17 [SimonSapin]
Topic: CSS escapes in attr() values
07:43:31 [leif]
SimonSapin: attr() defined in the values spec
07:43:59 [leif]
… This function now takes a parameter with expected type
07:44:04 [leif]
… can pass integer etc.
07:44:16 [leif]
… In the defining for string and url, we say that the absolute value is passed
07:44:18 [Rossen]
Rossen has joined #css
07:44:23 [myakura]
myakura has joined #css
07:44:28 [leif]
… should clarify whether CSS escapes are interpreted, and I think they should not be.
07:44:50 [leif]
… If they need to be serialized, we may need to add escapes, but that's a separate concern.
07:45:23 [leif]
TabAtkins: att="foo\33", content: attr(att) displays "foo33" or "foo\33"?
07:45:38 [leif]
plinss: Don't want to move escapes from one context to another.
07:45:52 [leif]
… it should be resolved before.
07:46:16 [leif]
glazou: Entities should not leave their context.
07:46:34 [leif]
RESOLVED: String and URL types for attribute literally takes the attribute's value without parsing.
07:47:25 [leif]
Topic: Alignment
07:47:58 [SimonSapin]
(previous topic) In particular: clarify that no CSS escaping is involved. Probably remove wording like "parsed as the contents of a CSS <string>".
07:48:30 [leif]
TabAtkins explains concepts, but not the basic properties
07:48:38 [leif]
TabAtkins: This applies flexbox alignment props to rest of CSS
07:48:52 [leif]
fantasai: Most keywords are axis agnostic, so put them in a separate section
07:49:01 [leif]
TabAtkins: Only non-obvious are self-start and -end
07:49:20 [leif]
… [missed] are defined based on the mode and directionality of the parent element
07:49:29 [leif]
… self-* are defined based on the element itself.
07:49:43 [leif]
… flex-start and -end are based on the flex directionality instead of the writing ode
07:50:00 [leif]
dbaron: Do flex-start and -end fall back?
07:50:04 [leif]
fantasai: to start and end.
07:50:13 [leif]
… if not flexbox
07:50:42 [leif]
fantasai: we have left and right, because sometimes you want that, but we can't always fulfil that.
07:50:51 [leif]
TabAtkins: And helps explain <align>
07:51:10 [leif]
fantasai: stretch depends on the layout mode, defined further down
07:51:34 [leif]
… We pulled the baseline definition from 2.1 and put it here.
07:51:43 [leif]
… Flexbox also has it
07:52:22 [leif]
dbaron: doesn't distinguish between inline-block and [...]
07:52:30 [leif]
… defined to use last-line baseline in 2.1
07:52:45 [leif]
… Need to spec first-line basline and last-line baseline
07:52:52 [leif]
… and which are used for different things.
07:53:25 [leif]
… first-line and last-line baseline interaction is complicated, so need to define based on context, and research it.
07:53:33 [leif]
… Don't expect impls to be sensible.
07:53:52 [leif]
RESOLVED: Need more work on baseline section, define first-line and last-line baseline.
07:54:10 [leif]
fantasai: Block-axis of table is undefined.
07:54:37 [leif]
… Table with a block of text inside, with a vertical text context, then the block axis will align with the inline axis
07:54:46 [leif]
… Need a concept of baseline for each box
07:54:58 [leif]
… Is it based on the baseline of the first column, or does it not have a baseline?
07:55:03 [leif]
TabAtkins: No testing yet
07:55:16 [leif]
fantasai: Basing on first column makes sense
07:55:23 [leif]
Bert: Why not center?
07:55:29 [leif]
fantasai: then you would center it.
07:55:39 [leif]
TabAtkins: There is a keyword for that.
07:55:57 [leif]
fantasai: We'll do another pass, but needs review eventually.
07:56:22 [leif]
fantasai explains distributed alignment
07:56:54 [leif]
TabAtkins: space-evenly is new, based on requests to flexbox
07:57:09 [leif]
fantasai: Useful for two-column layout with different layout models in each
07:57:35 [leif]
TabAtkins: 'stretch' came from Grid Layout.
07:57:45 [leif]
fantasai: Needed for flex lines.
07:58:10 [leif]
fantasai explains overflow alignment
07:58:44 [jdovey]
jdovey has joined #css
07:59:37 [leif]
fantasai explains justify-content and align-content
08:01:29 [leif]
dbaron: not handled the same way as the 'align' attributes?
08:01:38 [leif]
TabAtkins: We have special keyword.
08:02:14 [leif]
dbaron: People have trouble following, not really working as an introduction.
08:02:31 [leif]
TabAtkins explains justify-items
08:02:45 [leif]
TabAtkins: can choose legacy behavior
08:03:09 [leif]
dbaron: My issue was with how you mapped HTML alignment attributes that don't have a BFC.
08:03:32 [leif]
fantasai: Vertical alignment in the vertical axis forces a BFC.
08:03:38 [leif]
… but might need thinking about
08:03:45 [leif]
… might also need horizontal axis.
08:03:56 [leif]
TabAtkins: Can only use the block-axis one on blocks
08:04:07 [leif]
… get center behavior by using legacy
08:04:20 [leif]
… The property that does that does not have the BFC behavior
08:04:36 [leif]
Bert: 'safe' and 'true' centering…
08:04:54 [leif]
… I want to reintroduce true centering in text-align, even where there's a flow.
08:04:54 [jdovey_]
jdovey_ has joined #css
08:05:07 [leif]
… and margin: auto, where I want centering without clamping
08:05:09 [jdovey_]
jdovey_ has left #css
08:05:22 [leif]
fantasai: This spec takes those props and applies them to all box models
08:05:36 [leif]
Bert: Don't use margins to center. Use align property to choose true center.
08:05:48 [leif]
08:06:12 [jdovey]
jdovey has joined #css
08:06:17 [leif]
fantasai draws case with shrink-wrapped table with margins and centering.
08:06:37 [leif]
fantasai: Want at least a certain margin, but also want centering. This is a better model for that, using justify-self.
08:06:46 [leif]
… have cake and eat it
08:07:26 [leif]
fantasai: justify/align applies to block/inline.
08:08:08 [leif]
SimonSapin: block-align and inline-align?
08:08:17 [leif]
TabAtkins: Flexbox doesn't care about your writing direction
08:08:25 [leif]
… prop names are not renameable.
08:08:31 [leif]
… Need to discuss abspos
08:08:52 [leif]
Bert: Can I use other props in the normal flow?
08:08:58 [leif]
TabAtkins: Can align the entire block's contents
08:09:08 [leif]
… It's defined in the spec.
08:09:28 [leif]
fantasai: Vertical centering: use align-content on an element
08:09:45 [leif]
TabAtkins: Spec is split into two axes and three alignments applied to them
08:10:16 [leif]
Bert: last column "Applies to" answers my questions.
08:10:25 [leif]
… Have to rewrite Box Model
08:10:31 [leif]
Rossen: These apply to border box or margin box?
08:10:34 [leif]
fantasai: Margin boxes.
08:11:07 [leif]
TabAtkins: In case of vertical-aligned paragraphs, the outermost bounding box of the contents.
08:11:25 [leif]
Rossen: justify-self: true center on box with 25% width and 50% left margin, will be centered with the margin box?
08:11:35 [leif]
TabAtkins draws on board
08:11:41 [leif]
Rossen is satisfied
08:12:03 [leif]
TabAtkins: Let's talk about abspos
08:12:16 [leif]
fantasai: The plan of this draft is to make it easy to center things, including abspos
08:12:39 [leif]
… The containing block for your asbspos item has offsets specified
08:12:50 [leif]
… That creates a modified containing block.
08:12:57 [leif]
… by default, you do as in 2.1
08:13:11 [leif]
… If you specify center, then you'll shrink-wrap.
08:13:30 [leif]
dbaron: 2.1 isn't quite that simple. Function of wether widht and height are specified
08:13:39 [leif]
TabAtkins: If neither is auto, then we do these things.
08:13:46 [leif]
… was confusing to write!
08:14:15 [leif]
… If you have explicit margins and left and right props, then when calculating auto width, shrink to fit.
08:14:24 [leif]
dbaron: Also, when no auto width, also align.
08:14:46 [leif]
Rossen: change of behavior?
08:14:50 [leif]
fantasai: No, compatible with 2.1
08:15:06 [leif]
TabAtkins: stretch is default. Absposes behave as in 2.1
08:15:23 [leif]
TabAtkins: Possible that there are some deep details that we missed, so needs review at some point.
08:15:53 [leif]
fantasai: Get true alignment in grid and flexbox, but safe alignment in doc-centric layout, i.e. tables and blocks.
08:16:06 [leif]
… Can't make them all safe, because flexbox has true.
08:16:18 [leif]
TabAtkins: Could define whatever for blocks
08:16:31 [leif]
Rossen: Should keep doc-centric ones safe and app-centric true.
08:17:06 [leif]
fantasai describes property index
08:17:27 [leif]
TabAtkins: Please someone look at legacy left/right/center, is there a better way to do it?
08:17:36 [leif]
fantasai: Want to express that we're enforcing alignment.
08:17:51 [leif]
… Right now only with left/right/center, but if it's useful, can align with start/end.
08:18:07 [leif]
… Think about: do we want to allow it for other keywords.
08:18:55 [leif]
fantasai describes auto/legacy
08:20:44 [dbaron]
08:20:53 [leif]
Topic: Reversing interrupted transitions
08:21:05 [leif]
dbaron: only tested in gecko
08:22:01 [leif]
… relied on mouseenter/mouseover, but those are even worse than a decade ago
08:22:07 [myakura]
myakura has joined #css
08:22:18 [leif]
dbaron and TabAtkins discuss JS implementation
08:28:05 [leif]
dbaron explains various proposals in testcase
08:29:04 [leif]
dbaron: There were other proposals, but I didn't implement
08:29:15 [leif]
TabAtkins: Your proposal is better than the current spec, at least.
08:30:19 [leif]
dino: Reversing is only when in a transition and you set the value to where you came from? If it has ended, run a normal transition?
08:30:21 [leif]
dbaron: yes
08:30:34 [leif]
SimonSapin: What if enter a transition and go to another one?
08:30:50 [leif]
dbaron: No special treatment. Hard to impl. sensibly.
08:31:23 [leif]
fantasai: if we have transitionin but not -out?
08:31:32 [leif]
dbaron: Then will not have transitionout.
08:31:46 [leif]
dino: What if a different timing function or duration? should break reversal.
08:31:49 [leif]
dbaron: Disagree.
08:32:07 [leif]
… in many cases people will want different timing functions, because they want that behavior.
08:32:37 [leif]
… With my approach, they'll still get the specified timing function for each direction.
08:33:13 [leif]
dbaron gives example with timing function on hover state
08:34:07 [leif]
dino: People that care about this will want to tweak everything. Can't address that without adding props.
08:34:16 [leif]
… Just make it work for the majority of cases
08:34:34 [leif]
fantasai: If timing-in was 4s and -out was linear 4s…
08:34:42 [leif]
dbaron: My proposal looks only at value, not timing.
08:34:57 [leif]
… Sometimes 50 % through value space in 12 % of the time
08:35:07 [leif]
… I say 50 % in 50 %
08:35:19 [leif]
dino: If linear in both directions, 4s one way 2s in the other…
08:35:42 [leif]
[not minuting clarifying discussion]
08:36:09 [leif]
fantasai: What if the timing function is slow for 15% and then slow?
08:36:13 [leif]
dbaron: That's ease-in
08:36:38 [leif]
… If you mouse out at 50%, the time going back is close to the time going forward
08:36:51 [leif]
… Time going back was shortened quite a bit
08:37:22 [leif]
krit: ease-in is better with the current spec, ease-out is better with your proposal
08:37:28 [leif]
dino: Depends on when you interrupt it
08:37:47 [leif]
rik: goes too fast back when shortening the time
08:37:59 [leif]
dbaron: Don't like discontinuity between 99% and 100%
08:38:18 [leif]
dino: Some people might want an interrupted transition at 99%, pretend it finished.
08:38:32 [leif]
dbaron: Mine: it gives 99% of the duration, so almost undetectable.
08:38:54 [leif]
dino: Should just pick one, yours is fine. Let's implement it and see.
08:39:03 [leif]
dbaron: Always like this in Gecko
08:39:12 [leif]
krit: Safari just unprefixed transitions
08:39:43 [leif]
dino: Concern is that people have content where they instead of transitionend event assumed that something happened.
08:39:53 [leif]
… we're effectively changing t-duration on them.
08:40:06 [leif]
TabAtkins: Adding a delay between the real end and the …
08:40:16 [leif]
dbaron: Probably need some real events for interruption
08:40:23 [leif]
… no transitionend event.
08:40:35 [leif]
dino: There's interrupted and there's paused.
08:40:50 [leif]
… suspended, e.g. if animations are paused on scroll
08:40:57 [leif]
… duration is possibly longer
08:41:10 [leif]
… People have requested that if prop is set to same value, then no transition.
08:41:21 [leif]
… Adopt your proposal.
08:41:29 [leif]
cabanier: Apple's spec is better, actually.
08:41:42 [leif]
dino: I don't care much. Want to stop hover complaints.
08:42:21 [leif]
… Safari has no reversing, so need to implement to see.
08:42:43 [leif]
cabanier: Don't we already have a demo for side-by-side
08:42:44 [leif]
08:42:52 [leif]
dino: Need a complete implementation.
08:43:03 [leif]
krit: Can also be decided on CR.
08:43:24 [leif]
plinss: Do we want to change?
08:43:28 [leif]
TabAtkins: Spec behavior is bad.
08:43:30 [Zakim]
dbaron, you asked to be reminded at this time to go home
08:43:36 [leif]
krit, cabanier: no, not bad.
08:43:44 [leif]
dino: We don't know, because we haven't implemented it.
08:44:56 [leif]
… propose dbaron's suggestion. Firefox already shipped, looks good enough.
08:45:16 [leif]
RESOLVED: dbaron's proposal for reversing interrupted transitions is accepted.
08:45:22 [leif]
Meeting adjourned.
08:45:28 [leif]
rrsagent, make minutes
08:45:28 [RRSAgent]
I have made the request to generate leif
08:45:30 [myakura]
rrsagent, make minutes
08:45:30 [RRSAgent]
I have made the request to generate myakura
08:47:22 [cabanier]
cabanier has joined #css
08:51:05 [leif1]
leif1 has joined #css
09:06:04 [glenn]
glenn has joined #css
09:11:02 [leif]
leif has joined #css
09:15:06 [leif1]
leif1 has joined #css
09:24:41 [SimonSapin]
SimonSapin has joined #css
09:40:09 [leif]
leif has joined #css
09:43:58 [ivan]
ivan has joined #css
10:01:47 [dbaron]
dbaron has joined #css
10:02:07 [SimonSapin]
SimonSapin has joined #css
10:02:59 [cabanier]
cabanier has joined #css
10:04:01 [krit]
krit has joined #css
10:09:14 [glenn_]
glenn_ has joined #css
10:10:55 [lmclister]
lmclister has joined #css
10:16:23 [krit1]
krit1 has joined #css
10:16:25 [liam]
liam has joined #css
11:01:53 [cabanier]
cabanier has joined #css
11:08:10 [krit]
krit has joined #css
11:19:01 [krit]
krit has joined #css
11:24:41 [dino]
dino has joined #css
13:01:23 [Zakim]
Zakim has left #css
13:27:04 [plh]
plh has joined #css
13:28:16 [plh3]
plh3 has joined #css
13:45:04 [dbaron]
dbaron has joined #css
13:45:39 [zcorpan]
zcorpan has joined #css
13:49:33 [leif]
leif has joined #css
13:58:14 [SimonSapin]
SimonSapin has joined #css
13:58:34 [cabanier]
cabanier has joined #css
14:16:56 [zcorpan]
zcorpan has joined #css
14:33:41 [leif]
leif has joined #css
14:33:52 [krit]
krit has joined #css
14:41:42 [tantek]
tantek has joined #css
14:49:57 [SimonSapin]
SimonSapin has joined #css
14:51:01 [leif]
leif has joined #css
14:58:44 [leif]
leif has joined #css
15:10:02 [leif1]
leif1 has joined #css
15:26:19 [zcorpan]
zcorpan has joined #css
16:12:41 [zcorpan]
zcorpan has joined #css
16:13:25 [arno]
arno has joined #css
16:33:01 [arno1]
arno1 has joined #css
16:37:03 [zcorpan_]
zcorpan_ has joined #css
16:52:17 [jet]
jet has joined #css
18:00:44 [arno]
arno has joined #css
18:02:19 [arno]
arno has joined #css
18:10:48 [jet]
jet has joined #css
18:18:39 [abucur]
abucur has joined #css
18:44:05 [nvdbleek]
nvdbleek has joined #css
19:06:01 [darktears]
darktears has joined #css
21:02:22 [arno]
arno has joined #css
21:07:10 [arno]
arno has joined #css
22:13:59 [liam]
liam has joined #css
22:21:58 [arno]
arno has joined #css
23:01:35 [dbaron]
dbaron has joined #css
23:20:52 [SimonSapin]
SimonSapin has joined #css