Cascading Style Sheets (CSS) Working Group Teleconference -- 07 Jun 2013

<dbaron> trackbot, start meeting

<trackbot> Date: 07 June 2013

<glazou> ScribeNick: Rossen

Selectors 4

February-or-so Face-to-Face

<dbaron> dbaron: want to do a doodle for scheduling

<dbaron> [discussion of contintents, probably North America's turn]

<dbaron> [discussion of who can host, and who just hosted]

Feb is NYC tentative

<dbaron> (some were going to look into hosting in California too, I think?)

<liam> ScribeNick: Liam

<Rossen> nm last topic... new topic is Grid

<TabAtkins> http://dev.w3.org/csswg/css-grid/

Tab: section 1...

[question of scope from fantasai]

question is about snapping items to grid

you can already align things, but this is moer about sizing things

proposal from Tab is to push snap-to-grid off to a later spec

no objections

glazou: accepted.

tab: section 4 issue 3

positions of things not explicitly given a grid position

[Tab goes through the four options in the issue]

fantasai: [draws on the board]

1. always auto-position

(by default)

2. put unpositioned elements in slot 1 1

3. add ability to define a default slot, and then do either 1 or 2

bert: first look at area, then look at flow, then look at normal positions just a process

tab: this is for the case there's no explicit position

Bert: if y udon't have a grid area there's still flow-into that may give you a position

fantasai: yuo have a doc, e.g 5 elements in body, and the only style is display:grid on the body

so these subelements have no explicit styles at all

bert: then they all go into the default slot

tab: what happens if yuo don't define a default slot?

bert: but 1 1 might be an empty slot

Rossen: we currently do 1 1

toggling display: grid on/off will have no effect in that case for us

if yuo have al lof the in one anyonymous grid item

alan: if you had discontiguous elements you might not want to put them all into the same container

fantasai: adv. of auto-positioning is that things don't pile on top of each other

adv. of everything piling up is tha tyou don't change the size of the grid, but then you can't see the top

tab: if you're using grid and not positioning things, you're doing it wrong

Rossen, we were strongly considering (4)

4. Flow everything together into the default slot.

e.g. if there are 3 P elements you get all 3 stacked separately

alan: it runs into the complications we had with named flows

e.g. margins collapsing

<jet> TabAtkins: @door with others

tab: floxbox now, all elements get coerced into flex items

other option: autoposition everything with autoflow: row

margins will no longer collapse when grid is toggled but it'll be more like flexbox

fantasai: [agrees]

so either autoposition, or do the flow

bert: I'd like this to be more compatible with regions

tab: wherever we have slot pseudoelements they should be able to accept grid as well

dbaron: I'm concerned about difficulty of implementation

<dbaron> I'm concerned about the difficulty of doing 4.

fantasai: I'm inclined to go with 1

alan: 4 isn't quite regions, still in same parent

<dbaron> fantasai: ... consistent with the way flexbox works, so you switch from flexbox to grid

tab: but taking discontiguous flow elements together
... doing 4 is basically equiv. to taking all the flow items out and then taking what is left

and putting it into one big anonymous grid item in the default slot

dbaron: presumably you can't have absolute positioning on grid items

tab: right, then it's not a grid item

alan: default slot is * or 1 1 if there isn't a * ?

tab: [agrees]
... template draft uses @ for it
... we'll add properties for specifyingit

alan: if yo uhave more than one cell marked with a * ?

Bert: an error if disjoint

fantasai: [elimination game for other alternatives]

1 stacking everything on top of each other, i.e. auto position by default

Rossen: that's what we do today

4: flow everything together into the default slot.

bert: 11 might be empty, "."

tab: so, if there's no explicit default slot define, use a row-major seacrh to find the first non-empty slot and use that.

alan: if you want to avoid overlap, sometimes you'll have to create a new row.

tab: sometimes you'll need to specify a default position

bert: ok

this is fallback behaviour anyway

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

issue 4, non-children grid items

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

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.

dbaron: what if it gives no position?

alan: it becomes a grid item

tab: so it must be autopostioned
... how about if we only do this if the item has both position: grid and an explicit position?

<dbaron> peterl: what about using the fact that it's positioned in a grid instead of using position:grid?

tab: we do need an explicit flag, "I want to be a grid item"

I'd be fine amending this to say you must also provide explicit positioning in addition to grid: position

If you're positioning to a named area/gridline, and the nearest grid doesn't have that, the spec says keep moving up the tree until yuo find a grid with that line

or we could say, you failed

benefis - you can refer to the page grid anywhere in the document

plinss: is that true if you're asking for a line ot in yur grid?

fantasai: if you wanted to make that work yuo could just say position:grid on taht item

tab: a normal line item referencing a line not in its grid just pops up?

fantasai: what if you speciy two grid lines and they come from different grids?

tab: goes in the first grid it can find

bert: so we'reusing the position property to turn this on?

tab: yes, if you're not a direct child of a grid

we have otehr ways we want to use the position properties so we want to make it an explicit switch

bert: you only do that for elements that are themselves of grid items?

fantasai: any descendent of a grid can take position: grid and become a participant in that grid

tab: what if yuo can't find something with tha tname?

maybe they should be autopositioned in the nearest grid?

if you're a grandchild of a grid you need to opt in explicitly, if you're a child it's automatic

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

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

]

if you don't find any lines you should still be positioned in the closest grid you find

alan: be good to spearate the fallback from the sub-grid that works

tab: [agreed]

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

plinss: nok because there are other uses for the properties

tab: section 4.2 has the abspos case

[4.2. Absolutely-positioned Grid Children http://dev.w3.org/csswg/css-grid/#abspos-items]

fantasai: [draws a diagram]
... everything is like abs-pos except that if the containing block is a grid you can position yourself with respect to the grid lines

tab, peter [discuss possible changes to abs pos]

tab: we don't want to change abs-pos too much

plinss: but the abs-pos'd items don't affect the grid layout

plinss, what if fixed position?

dbaron: with transforms, fixed works like abspos

tab: assuming fixed-pos can find a containing grid it should work just like abs
... example: {

grid-col-start: 2, auto

grid-col-end: auto

}

tab: wondering about this only for abs-pos'd items

fantasai: if it's all auto you use the outer edge

plinss: a little bothered it's different for abspos and grid items
... need to make sure auto gets you a regular abs-pos behaviour

tab: you can use the grid-col properties to change your containing block, for abs-pos

<glazou> test

plinss: normal abs positioning of the column edge, [scribe missed]

fantasai: if you have a grid ... [draws] that's 1 x 1 , autosized ...

my vertical gridlines will be, content edge, and sized out

so e.g. align: centre should centre that box (the grid) in the containing block

so the abs pos first and last grid line, you'll align to those, wherever they end up being

may or may not correspond to the content of th box

abspos auto means the normal containing block edge

plinss: but if it's a grid item it means something slightly different

fantasai, tab: [agree]

resolved: abspos for grid items accepted as described in the spec, with auto meaning use padding edge of containing box

<dbaron> plinss: to clarify, display:grid isn't always an abs pos containing block?

<dbaron> fantasai, Tab: correct

plinss, can we add "containing-block: always"?

back to issue 5, non-children grid items

plinss: these items only behave oddly if yuo positioni them absolutely

<dbaron> (plinss arguing that you shouldn't need position:grid, you can just apply the stuff in section 4.1 when not position:absolute)

tab: we still want an explicit indicator [for grid-item-ness] so yuo can opt into autoflow

plinss, so you can have a position: grid, but only necessary if you don't want auto?

tab: yes
... now have an additional problem, if you have position: grid, a named line, and can't find it

so we don't know what grid to put you in

we coud say you reman in flow

If you're a real grid item

your parent is a grid container

and we can't find your lines

we default you to auto

so auto-positioning or default slot

if you'er grid descendent we don't want tha tbehaviour

so are we OK with saying no, you're not a grid item, if w can't find the line

bert: first step is going up the tree

maybe all the way up to the page

tab: assuming w did that and can't find the grid

don't want to put grid items into the default slot

so it stays in flow in normal positioning

plinns: if autopositioning is turned on there's not reason why we couldn't autoposition it ...

so maybe "we do nothing" is the fallback, i.e. ignore the position: grid

tab: seems reasonable

[accepted]

alan: so if you have a grid container, one of its direct children, but you put position:grid on it

tab: it goes into the default slot, normal flow, position: idd will act like position: static in that case

plinns: it seems to me all direct children of a grid will compute to position: grid

bert: that depends on the position property

position: static means they arein the normal flow

fantasai: [disagrees]

tab: sometimes we do want to put things with position: grid in the default slot, if they are grid items

I'd be OK with position computing to grid

we don't do it to flexbox but we don't have children there

Rossen: how do you break out of your grid in that case?

plinss: same as before, you'd use a name of a higher grid line

bert: you'd put a div element wrapper in there

<Bert> (which, of course, is not desirable)

fantasai: I don't like that if you're a child of a grid you can suddenly jump around

plinns: but aren't immediate children grid items anyway?

<dbaron> I'm not crazy about all the use of the 'position' property (and 'display:grid' vs. 'position:grid' is especially confusing)

fantasai: yes, but nothing makes them jump about out f the grid

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

<dbaron> tab: use a seamless iframe

<stearns> +1 dbaron, particularly in that position:grid really means something like supra-grid or jump-into-an-ancestor's-grid

dbaron: I'm generally unhappy about adding more uses of the position property

<dbaron> (explains IRC comment above)

bert: we can reduce by one based on presence of template

tab: we wanted an explicit flag

you can set none of the properties and you'll be autopositioned

bert: which is more common?

<dbaron> dbaron^: ... since the 'position' property is mostly a list of things that should have been values of 'display' instead

fantasai: depends what you're doing, e.g. a catalogue where yuo want items in a grid

tab: we can do display: grid-item

plinss: but then you lose display: auto

tab: current values of position should have been position

dbaron: position fixed is really a display value, position relative is an unrelated feature

tab: could add display: outside-grid-item

<dbaron> tab: could add display-outside: grid-item instead of position:grid

fantasai: it's getting complicated
... I like how flex-box is very straight-forward

whereas here, when you turn on display: grid, shouldn't soemthing happen?

tab: are you saying we should default grid properties to more than a 1x1 grid?

fantasai: we don't generally have things jumping around reparenting themselves

it should be self-contained, you turn on grid and everything looks like a grid

plinss: that _is_ what's going to happen

[discussion about reparenting]

fantasai: I want the jumping to be opt-out on the jumpee item

tab: that only happens if you're using useless grid item properties

fantasai: I don't want setting something on a parent to trigger the ability of a child to jump out

plinss: the child is already opting into some grid behaviour

Rossen: do we need al lthis for level 1?

bert: yes!

Rossen: I mean the jumping out

alan: if we don't do it now, we'd have to invent entirely new properties to get this in the future

tab: can possibly do it more simply and interated way right now

plinss: if you're explicitly opting in to some grid line, why should you have to turn on another property to make that work?

fantasai: [scribe couldn't hear]

tab: probably opting in will be needed

plinss: position: snap, or something
... what if everyone had to say position: grid?

and no magical behaviour

because now just being a child of a grid makes you magic

Bert: this should be like columns, not flexbox

tab: but flexbox isn't used in the same case, and neither is columns

bert: if you position yourself in the grid you get a position in the grid, doesn't matter if it's your parent

tab: opting in to autoposition would have to be explicit

couldn't just turnon grid and have everything positioned into row

fantasai: wants turning display:grid on to make a grid that's one column (if you don't do anything else)

tab: skipping

4.3 issue 8 visibility

<dbaron> peterl: better to do other issues for next 15 minutes and come back to this

" Or should the track size be set to 0 regardless of its sizing function? "

tab: make visibility collapse, remove it from the grid, but still affect on sizing

collapse becomes visibility: hidden, except,

if everything in a track collapses the track size drops to zero

a. is this reasonable?

b. should this be intrinsic size ofthe track?

dbaron: if you set some of the items to visibility: collpased, no change on track size?

tab: yes

dbaron: that's not the same as tables

bert: you set it on the table row or col

dbaron: the intermediate state seems weird

if the featre is useful enough to exist, I'd be OK to change for each collapse change

tab: then it's same as display: none

dbaron: OK, I see why you did what you did

<dbaron> ... but it's still annoying

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

dbaron: for reference we still haven't defined how the table thing works!

tab: probably should kill this section and think about it some more

decision: change issue 8 into a more general issue about the feature

issue 9

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

]]

tab: right now you have:

grid-definition-rows

grid-definition-columns

grid-template

}

tab: [suggests some alternate names for the properties]

A. grid-template-[rows|columns|slots]

B. grid-definition-[rows|columns|slots]

dbaron: so the rows and cols properties are really giving the sizes of each column/row

<dbaron> ?: and the number (as does slots)

tab: rows and columns also name lines and give the numbers of rows/columns

<dbaron> s/?/tab\/fantasai/

bert: I used the shorter name for defining grids

tab: you'll more likely be using the positioning properties, defs are once per container not once per item

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

TabAtkins: tehre are strong use cases for [explicit definition properties]

bert: don't like the word definition, maybe "size"?

tab: we want a common prefix

bert: "grid" is the common prefix

fantasai: it's not just sizes, also names

<dbaron> I'm happy with A or B, probably slightly prefer A.

<jerenkrantz> prefer A

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

tab: maybe we can say "area"?

<dbaron> tab: replaces A with grid-template-[rows|cols|areas]

so, grid-template-[rows|columns|areas]

and grid-template is a short-hand using Bert's draft

[discussion of Bert's syntax for shorthand, plinss and tab agree it might need work

]

tab: could say it's a slightly odd shorthand, can't omit the template from the shorthand, but this is weird

bert: it's not weird!

[discussion, do you need to mention the template in the shorthand property?]

tab: given a 3x3 you have to do ". . ." ". . ." ".. . ."

[lunch]

<glazou> ScribeNick: dino

tab: we deferred a couple of issues
... 1. Position: grid stuff. Peter, Elika and I decided on something.
... position:grid on anything makes it a grid item, and makes it jump up the tree looking for lines.
... this leads to interesting auto-placement....

dbaron: [interrupts]

<stearns> normal grid children do not jump up the grid

tab: ok, cool.
... we propose eliminate auto-flow:none, switch initial value to rows (grid-overflow), and have that as the overflow behaviour

<dbaron> s/overflow/autoflow/ ?

tab: this has the benefit that it is close in apparent behaviour to the default cell.

(with display: grid)

tab: and acts grid-like when you apply more of the grid properties

TabAtkins: and matches flexbox more closely
... -> unambiguous behaviour when pos:grid items that can't find lines (or are auto). they act the same as a grid child.

-> find nearest grid, and become autoflow item there

alan: soyou can no longer have pos:grid and have it remain in the flow

TabAtkins: correct

bert: means i can't use the same grid for templates.

TabAtkins: the region behaviour should be addressed separately.
... this is simpler overall.

Bert: but less useful
... everything has to be parent child

TabAtkins: no, use position: grid

Bert: I want to use props starting with grid. they are useful.
... they work like regions. content flows into the grid.
... this is reversed. when i set the grid properties on an element, i need to duplicate the properties on children.

TabAtkins: (disagrees)
... a. regions lets you do everything right now
... b. if we want to do this later, it's easy

[ Bert requests maintaining existing behaviour. Tab explains that this is like flexbox ]

Bert: it is easier if you have markup designed to behave that way. this is not normally the case.
... my approach is easier. if you want something floated, you put a property on it. that's what removes it from the normal flow.

TabAtkins: i understand there are strong reasons for your way, but my way is much more simple.

Bert: they were simple before too

elika: the point of having everything become a grid is that display:grid makes things appear like a grid.
... set rows, you get that number of rows, etc
... we wanted this for flexbox, and we're following here.

TabAtkins: we're proposing to start with this simple model, and add your case later.

Bert: both behaviours are useful. the nice thing was that you could use the same properties to set up for both.

TabAtkins: you can still do this.

[ disagreement about how many properties each case needs to set ]

Bert: i've tried many different examples...

TabAtkins: all document-centric
... app-centric gravitate towards my model

Bert: yeah, it is very common to have flowing text. I don't want to have to set two properties.

elika: when you have flowing text you normally have a parent/child relationship

Bert: disagree.

TabAtkins: do that by changing grid:auto-flow into a new value

alan: i don't understand how this addresses bert's case

TabAtkins: once we add it, it is simple to turn on

Bert: why not have it as part of the shorthand? it could say either the template or a keyword positioning v flowing

TabAtkins: right now grid:autoflow is not part of the shorthand. we could add that.
... this is not necessarily new stuff, we'd just changing what the auto value does.

Bert: you could also use the display property as the switch.

TabAtkins: it is simple to add this later. are we happy to change our default behaviour over to this?

Bert: flexbox is the wrong model to follow. multicolumn is a better example.

TabAtkins: i'm not trying to justify flexbox.
... can you live with the change I suggested?

Bert: it's a radical change

TabAtkins: no, it's just the initial value of one property

Bert: syntax wise yes. but requires a new template layout model.

TabAtkins: [disagrees]

Bert: what does the default slot become?

TabAtkins: when you use the flowing behaviour you define what the slot is. We don't have to worry about this in default.

Bert: [explains a complicated example in a manner that would be difficult to minute, using hand gestures]

TabAtkins: [answers the example :]
... the two things you can't mix are the two types of auto-positioning. use regions for that.

Bert: i have a grid element, with a template, it isn't auto positioned, with some child that I do want positioned
... do i then have to use pos:grid

TabAtkins: no, use grid area
... the rest are auto-flowed
... look at grid: auto-flow and do what that says

<Rossen> #grid { grid-auto-flow: rows; display: grid; } #grid > * { grid-area: auto }

Rossen: is that enough to get all of the auto positioned in a row?

<Rossen> #grid { grid-auto-flow: columns; display: grid; } #grid > * { grid-area: auto }

TabAtkins: not even that much. just set display:grid.
... we're just saying the default value should be grid-auto-flow: rows

Bert: you still have to set two properties together

TabAtkins: one of them has to be privileged

Bert: what is interaction btw flow into and grid area?

TabAtkins: i have no idea and don't want to think about it now

Bert: we will have to prepare for it

TabAtkins: in the regions draft, sure.

Bert: flow-into is used, and grid-area is auto....

TabAtkins: YES

Bert: NO

TabAtkins: NO

Bert: YES

Peter: suggest accepting tab's proposal, bert's objection noted, we will discuss it again.

alan: the proposal said you'd change the default and defer none? could we leave it in the draft for now?

TabAtkins: yes.

<dbaron> (grid-autoflow: none)

RESOLUTION: accept tab's proposal, bert's objection noted, we will discuss it again (issue marked in spec)

TabAtkins: shorthand.
... accept bert's shorthand with tiny changes (separators)

peter: do this later

<jerenkrantz> RRSAgent: make minutes

Font Load Events

<stearns> http://dev.w3.org/csswg/css-font-load-events/

<TabAtkins> http://dev.w3.org/csswg/css-font-load-events/#fontloader-interface

<liam> [tab shows a picture of an earwig]

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

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.

eg. canvas

e.g. show a menu of available fonts

- you don't know metrics, etc

JD: been an issue, many people want a solution.
... I sketched out a proposal for a FontLoader that hangs off document.
... gives a way to trigger some loads... just tell me when I'm done.
... most authors don't need to know specifics
... there is a more complex use case where they want to know exactly when every font is available

<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Apr/0064.html

JD: two handlers, and a bunch of methods
... loadFont ( font, text, successCallback, errorCallback )
... it's the same as the font property
... text is provided to help selection

krit: ???
... so font is a list of fonts?

JD: yes

glenn: what are semantics of the text member of LoadFontParameters?

JD: you go through the characters to see if you need fonts.

glenn: Please rename this parameter to something more descriptive.

JD: successcallback just tells you when things went ok

[ignore that last line]

JD: explains checkFont and notifyWhenFontReady

[ they were obvious so I didn't minute ]

TabAtkins: [ explains futures ]
... most of the API is "do something and tell me when it completes"
... All of John's API is reproduced in my proposal.
... e.g. - tell we when everything is ready to draw
... ... is ready().. returns a Future
... you then register callbacks on the Future...

glenn: Is this the first place in the Web ecosystems that is using Futures?

TabAtkins: No. e.g. JSON Linked Data.

Rossen: How are they different from Promises?

TabAtkins: the name has changed, but the same.
... The new TAG likes Futures and will be pushing it.

Peter: The TAG has consensus that this is a good approach.

glenn: I object unless there is a concerted effort to convert to Futures across the board.
... if there is a concerted effort to change existing APIs towards this, then i accept it.

peter: that is the plan.

<SimonSapin> http://w3cmemes.tumblr.com/post/48887723979/does-your-api-use-futures-yet

JD: Microsoft/Rossen and Apple/Dean, have you heard about Promises? Are you using them?

Rossen: we shipped them already. they are the way you write apps in Win8.

Dean: I have been paying no attention.

Peter: there were two people from mozilla that support this.

JD: just concerned about time lag if we have to depend on the feature

Glenn: my concern too

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.

Dean: It's new features like this that will drive the use of futures, so I support it.

TabAtkins describes how JD's proposal merges into his. Basically callbacks become futures.

<dbaron> onloading is any transition from 0 fonts loading to 1 font loading

JD: in my proposal onloading is fired when a font starts loading. onloadingdone fires when all fonts are loaded.

<dbaron> onloadingdone is any transition from 1 font loading to 0 fonts loading

JD: onloadstart fires on each font
... the difference is that if you want to know when fonts load you have to create a future for each of the fonts

TabAtkins: you just want to be notified when fonts load

dbaron: Tab, I think you've removed the low-level api that allows people to listen for each font load.

TabAtkins: no...

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.

TabAtkins: that's a small use case. I suggest waiting for the all loaded event.
... it takes a little longer.

dbaron: that makes the basic api more complex

TabAtkins: no, the basic API is just knowing when all fonts are loaded

Krit: ???

Liam: Does the spec handle the case when the font failed.

<liam> [answer: yes, I don't have to wait until all fonts have loaded before finding that one failed]

dbaron: in tab's proposal, what happens if one loads and one fails?

TabAtkins: loading done will fire when they are both finished. the event will have info on which ones worked and which ones didn't/

krit: ???

JD: it is weird to have a mix of futures and events

TabAtkins: it's not too weird

Peter: there is a promises-like thing for streaming situations

<ivan> (A blog of Tab on futures, for those (like me) who do not really know what those are: http://www.xanthir.com/b4PY0)

krit: ???
... is this API necessary?

everyone: YES!!

JD: e.g. webkit does not include font loads in the "load" event

TabAtkins: Google Docs slaps me every day about this

JD: We have a direction.... i'm not completely comfortable, but that's just details.
... issues - canvas web workers want fonts, but they have no DOM
... e.g. pdf.js wants to do work on a different thread.
... But Fonts are tied to a document
... It seems that the group wants to go in the direction of Futures...

glenn: Should we ask for a straw poll.

Straw poll: 11 people want a futures-based API. 1 against (for the record, it was Glenn)

JD: Next topic - Glenn wanted the ability to turn off all font settings. e.g. font-feature-settings: none.
... 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.
... I don't see the need.

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.
... Very useful for testing.
... You can already turn all these off. it's just a shorthand.
... If there was a way to enumerate the properties of a font... you could do that.

Elika: this is not a shorthand in the typical sense.

Dean: "shortcut" not "shorthand"

Alan: Glen is saying if there was a way to enumerate all the available features, he might be able to avoid this.

fantasai: just list them all

GA: there are some custom/private ones

glazou: how can I know that ligatures are enabled?

GA: you can't

JD: you'd turn it off and on and see if there was a difference
... there is no computed value to check

dbaron: this is a low level control property

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.

GA: My example is that I get a font from a customer with strange results. I don't have any way to know why.

JD: this is a pretty edge use case
... but it is a weapon of mass destruction too

GA: Not really. This is not new - you can already do it.

Liam: is there a way to revert the font to its default behaviour

GA: But normal means different things for different fonts

JD: No.

GA: No. It does not mean turn on features.

JD: Propose to reject this feature request.

GA: I will implement it anyway

<liam> [yes you can revert to default feature set]

Peter: yes, as long as it is prefixed

<dbaron> alan: I'd object to having this value; too much of a footgun.

Alan: I reject to having this as an available feature.

<dbaron> fantasai: me too

RESOLUTION: We will not add Glenn's proposal of font-feature-settings: none
... We will use Promises in the font loading API [From above - I didn't minute it at the time]

JD: [shows example of why text decoration on the baseline can cause problems in the synthetic case for superscripts and subscripts ]
... 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

fantasai: i can live with that

dbaron: i think that is reason

s/reason/reasonable/.

dbaron: you're saying do the glyphs, then do what text-decoration says

<dbaron> dbaron: so just doing synthesis and then text decoration stuff will be whatever the text decoration spec says?

JD: shows an example from The Guardian with some superscript

[which looks like shit]

[the lines are not equally spaced]

[looks much better in chrome with the variants available]

<Bert> (That's why many authors nowadays set 'sup {line-height: 0}')

<r12a> people.mozilla.org/~jdaggett/tests/multicolumnsuperscript.html

<r12a> http://people.mozilla.org/~jdaggett/tests/multicolumnsuperscript.html

Leif: on wikipedia has superscripts that are underlined on hover.

JD: they get the fallback

Leif: is there a way to force synthesis

dbaron: it's only for sites that are using this new feature to do supsub

JD: However, if they are matched to the font, the text decorations are really hard to see. These variants are small.

RESOLUTION: If an element with text-decoration set and font-variant non-normal then we synthesize subs/sups, and then text-decoration follows

<SimonSapin> s/^RESOLUTION:/RESOLVED/g

<SimonSapin> s/^RESOLVED /RESOLVED: /g

<leif> ScribeNick: leif

font-language override

jdaggett: OpenType has the ability to have language-specific features

<fantasai> Issue: http://lists.w3.org/Archives/Public/www-style/2013May/0578.html

<trackbot> Created ISSUE-339 - Http://lists.w3.org/Archives/Public/www-style/2013May/0578.html; please complete additional details at <http://www.w3.org/Style/CSS/Tracker/issues/339/edit>.

<fantasai> comment: http://lists.w3.org/Archives/Public/www-style/2013May/0736.html

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.
... there are cases where the semantic language may not be support by the ont
... 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
... an uncommon use case
... Some people unfortunately always want to set the low-level feature.
... They view the property as a way to set the low-level property.
... fantasai wants a fallback list instead of a single language
... But when you're specifying it, you know the font, so no need to specify

fantasai: But if your font has Macedonian, you should be able to express that that is your first preference.

jdaggett: You're asking for a different feature.
... You want fallback.

fantasai: You may or may not get the font that you specify.

jdaggett: The point is that when you know the font, youll specify it.

stearns: fantasai's use case is recognized, but sometimes you want an override instead of a fallback.

r12a: I'm not sure fantasai is asking for a fallback, because a fallback should go back to the language asked for.

jdaggett: This mechanism really is an override.

fantasai: UC in spec is if your font is missing glyphs
... Depending on which font you end up using, you still want to use the glyphs
... Another case is if you're using Mac. and have a few quotes of Serbian, and want that to work

jdaggett: As long as the font supports it, you can have multiple languages, each uses the right lgyphs from the same font.
... This doesn't feel like a general-purpose feature. I'm worried about getting implementations.
... Might be at risk.
... To extend it, means a lot of work defining the fallback.

fantasai: I see two UCs: Using a language close to your desired font.
... 2nd case: You want your text to have a consistent typographic style.
... If you have a quote from another language, you don't want to suddenly change shapes.
... Use style of surrounding paragraph. In that case, would make sense to have language override to use paragraph's language for that quote.

glenn: We need to knowwhat features and languages a font supports.
... Having a fallback seems unnecessary, knowing what the font has.

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.

jdaggett: The fonts on your system are not going to be that sophisticated.

fantasai: How do you know?

jdaggett: I see your points, but I don't think there's a lot to be gained.

stearns: The existence of an override would not preclude a future fallback mechanism.

fantasai: The use case we're aiming for, you're telling the font to use the wrong thing.

stearns: In all the mailing list feedback, they're talking about an override where they know the font.

fantasai: But that's not always the case while loading the page

jdaggett: A system font won't have all these features.
... Straw poll…?

glazou: fantasai, can you live with no change?

fantasai: I don't understand the objection to fallback

jdaggett: You're asking for more work, and I want to get the spec don.e
... The feature is at risk anyways.
... Prefer something simple that's actually implemented, then we'll go from there.

glazou: We've said for other things that "this is interesting, but we'll move forward"

fantasai: I can live with it. I just don't agree with the attitude "I know what fonts I have".

jdaggett: It can go on the css4-fonts wiki page.

glazou: or log an issue

glenn: Do you define that this string must be a case-sensitive match to opentype language?

<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

glenn: Should be case-sensitive

jdaggett: Have to look at that.
... Lots of case-sensitivity stuff sprinkled around.

fantasai: Spec doesn't specify case-sensitivity, and I raised that as an issue.

jdaggett: Can discuss Text on the mailing list.

r12: spec says it's case sensitive

Backporting level 3 changes to 2.1

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.
... A L3 client should also be L2 client.

dbaron: Slight modification: if the change would make _all_ 2.1 clients non-compliant.

TabAtkins: If there is an error in 2.1 fixed in 3, then should backport.

fantasai: Level 3 can tighten definitions, changes should be backported.

dbaron: If it would break content, we shouldn't be making the change.

SimonSapin: When do we stop fixing CSS 2.1?

fantasai: When the spec has been completely superseded.

peter: when a module has replaced parts of it?

TabAtkins: No, when it's completely replaced.

fantasai: A L3 spec will replace parts of CSS 2.1

SimonSapin: Can we deprecate parts of 2.1?

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.

peter: Does everyone agree to that proposal?

TabAtkins: Might not be worth it always, like every syntax change, but as a general principle, yes

fantasai: Syntax may actually be the most important.

TabAtkins: They're just really hard to get right.

SimonSapin: We should be able to deprecate one chapter.

glazou: What will be the result? 2.1 rev 2, or 2.2?

dbaron: 2.2 eventually, but not as much effort as 2.1.

glazou: People should be able to refer to 2.1

liam: small changes -> 2nd edition.

dbaron, liam: could be confusing.

Bert: Pick some time in the future, then bundle and publish errata

SimonSapin: What's the conclusion?

fantasai, glazou: As outlined above.

Bert: We should pick a date

fantasai: We already picked this F2F

Bert: Assign someone to follow-up?
... I have some other publications to do after the summer. Can follow it up October or after.

glazou: Let's decide later.

Text Decoration

<fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013

fantasai: Main issue: Position of underlines if you have an entire paragraph underlined
... Where should the underline be placed?

fantasai draws on whiteboard: big and small text within an element

fantasai: Do we use the ancestor's underline? 2.1 leaves this undefined.
... Rossen posted a TC where if each line has different sizes, they get different sizes

dbaron: That's contrary to the 2.1 model.

fantasai: We want to have one line.

<fantasai> http://jsfiddle.net/4sC2T/1/

fantasai: for web compat, we probably need to stick with that behavior.

dbaron: In Gecko, the underline is constant thickness.
... and position
... There were a bunch of tradeoffs in implemnting 2.1
... We got rid of quirks mode in text decoration
... There was a quirk that wasn't compatible enough with 2.1
... We came up with a new, unitary model for decorations.
... One of the importnat requirements: Not do ransom-note style underlining
... if it crossed multiple pieces of text, you got a single undeline.
... The underline comes from the element with the text-decoration property.
... The spec implid that the position and thickness come from that element.
... The 2.1 spec has one part where we disagreed about the grammar.

jdaggett: What about vertical-aligin variatons?

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.
... So superscript and subscript come from that.
... But there was a quirk.
... so be careful.
... fantasai's proposing that we switch to a model where we don't just use info from that model, but also its descendents.
... The union of them and all their fonts.
... Problematic because it's hard to implement and is slow
... and it breaks a number of invariants authors don't realize they depend on.
... Authors would be surprised if they have six things underlined, and one of the them is subscripted, and behavior changes.

fantasai: They'd also be surprised when underline goes through subscript.

dbaron: Yes, one author problem is fixed, another is caused.

Bert: One solution that we discussed about crossing the subscript is to interrupt the udnerline.

dbaron: The text-decoration model has a property to allow that.

<fantasai> Previous discussion on exactly this topic: http://lists.w3.org/Archives/Public/www-style/2012Nov/0129.html

r12a: isn't another solution to put a text-decor property on the subscript

dbaron: That needs canceling out

fantasai: Deferred to level 4

dbaron: Some people say text-decor feels like an inherited property,but it's not, to allow even baseline and thickness for entire element.
... I feel like this change would add a lot of complexity to fix one problem and cause another.

fantasai: We discussed this last year.
... Aryeh sent feedback that big text in strikthrough, the big text isn't striked through
... That resulted in the current text.

dbaron: I didn't understand it sufficiently at the time.
... I would not have agreed to averaging over descendants.

fantasai: So how can we solve both problems at once?

dbaron: We don't have a reasonable solutoin yet. We should stick with the existing model.

fantasai: Then I have to tell Aryeh that we're reverting the fix for his problem.

dbaron: We can't fix everything.
... And I really don't want to rewrite our text-decoration code every two eyars.

RESOLUTION: Revert the change to text-decoration behavior .

fantasai: Actually, this was a clarification, and we don't want to go back, we want something completely different.

glazou: Other text-decoration issues/

Bert: We're already in LC, we will have another one.

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?

fantasai: If you put a span in there, it gets a suitable underline.

liam: Lots of test cases needed here!

dbaron: If you specify three underlines on three elements, you should get three, even if they might cover eachother up

<liam> [ http://jsfiddle.net/Xfb9v/3/ - example ]

pseudo-stacking contexts

dbaron: At some point we discussed whether flex items should be psc, and we decided that they should
... but table cells should be too.
... But then: table backgrounds and borders are complicated
... should they be included in the psc?
... Four issues with table backgrounds and borders:
... backbrounds versus borders
... separated vs. collapsed
... Okay with different answers for those
... But don't want different answers for backgrounds for separated vs. colapses
... If we look at appendix E of 2.1
... Table background painting is already described as part of the z-order in 2.1

dbaron quotes the spec

dbaron: Table through cell are painted in the backgrounds layer
... That says that if table cells establish a PSC, that even cellbackgrounds are not inside it
... Because painting them is associated with the table

… At this point I've already explicitly disagreed with fantasai and TabAtkins

… But I'm against changing any of this.

… table borders are also painted in this layer.

… This is a bit ambiguous

… If we don't change it , then all we need to do is decide that tables form SC

… and cells are not part of that SC

fantasai: If we transform a table cell with backgrounds and borders, what do I get?

dbaron: the interesting part: do borders and backgrounds even move?

… in the collapsed model, shouldn't move.

fantasai: In some impls, if you set a transform, the backbround paints on top of the border.

dbaron: A bug.
... and poorly tested

fantasai: Probably all the implementations.

dbaron: I'm ok with cells being PSCs
... if it means that the PSC doesn't include the border and background

… Need a lot more work to define paint order inside cells.

… Are people ok with what cells being PSCs means?

… if so, just resolve.

TabAtkins agrees.

<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

jdaggett: When we publish a new spec, since the TR URL changes, do we need permission from plh?

plh: yes

jdaggett: can we get css3-fonts changed to css-fonts-3?

fantasai: Was going to do it all at once but can do it piecemeal

plh: I agree with the change
... All specs should be consistent

Bert: But will be hard to find old mailing-list messages

plinss: It's already been resolved.

Text decoration, one more issue

fantasai: text-underline-position: alphabetic

… says use font metrics

… is that reasonable?

jdaggett: Sounds like existing behavior.

dbaron: Part of the question is what the underlining metrics in CJK fonts look like
... Ideographic baseline?

jdaggett: have to look it up

dbaron: What is existing behavior?

<koji> http://lists.w3.org/Archives/Public/www-style/2013May/0159.html

fantasai: auto behavior says to do whatever you want, but don't cross through glyphs that shouldn't be

jdaggett: We have a blacklist of fonts in Gecko, where we modify the underline if it's in the blacklist.

… That is more that the underline metrics are not in line with the font

fantasai: It's suggested that this property should do the right thing for the text, in cases like cjk.

jdaggett: My concern: different fonts on the line, would the underline vary?

fantasai: No, would pick one position for the underline.

… Currently pick the lowest alphabetic position, but dbaron said we shouldn't do that. That gives interesting results if not baseline-aligned.

dbaron: The spec has two values, with auto the initial value.

… not clear to me how auto matches current behavior or how implementable alphabetic is.

… also how useful alphabetic was

jdaggett: I got an e-mail about this…

… Not clear to me what you mean by 'alphabetic'. Are you trying to override the font metrics.

… Are you basing it on the baseline?

fantasai: Expectation that font specifies the position of the baseline

… You might want to underline the bottom , accounting underline…

jdaggett: You use the metrics to infer where the unerline would be relative to the baseline?

fantasai: yes

jdaggett: What happens to implementations?

dbaron: Depends on how well 'auto' match implementations and how hard to implement alphabetic.

ACTION jdaggett to investigate those two questions

<trackbot> Created ACTION-564 - Investigate those two questions [on John Daggett - due 2013-06-14].

Reversing interrupted transitions

dbaron: Haven't quite finished my test case

… one algorithm and one proposal implemented, still need to impl the other one.

… in javascript

… Don't leave the page open in a tab after using it!

plinss: Let's get back to that.

white space in media queries

SimonSapin: We had an issue in both MQ and @supports

SimonSapin describes the issue

SimonSapin: The grammar had optional white space, meaning that if you used a comment to separate the tokens, it would be correct

… reader may not know this detail

… We changed the grammar to allow whitespace, like calc()

… Issue is resoled in @supports, but still exists in MQ. We should make the same change, but we have to wonder about compat.

dbaron: I don't worry about compat.

TabAtkins explains on whiteboard

TabAtkins: @media screen and/**/(color) — is that correct?

SimonSapin: With the current spec, and(color) looks correct, and it is not

TabAtkins: This problem applies to every ident in a parenthesis that can be next to eachother without being a function

dbaron: This is the problem with the function token

SimonSapin: Can use the function token in the grammar, but that is more complicated. Don't want to do that

TabAtkins: Agreed.

glazou: Shall we adopt SimonSapin's proposal?

<SimonSapin> SimonSapin: decided not to do function tokens in @supports

… require white-space in MQs

TabAtkins: This will come up every time we have parentheses

plinss: As long as you have some token between, should be valid.

… But want it to be consistent.

glazou: People expect it to work, because it's * in the grammar.

Bert: Can just add a comment in the grammar.

plinss: But have to do it everywhere. But I don't feel strongly about and(color). Just want it consistent.

glazou: Why is white-space required in @supports?

TabAtkins: To avoid that removing a comment changes the meaning.

SimonSapin: @supports now requires white-space on both sides.

plinss: Need to adopt this anywhere we have parens.

glazou: Not everywhere, just when it's not a function.

plinss: Don't want white-space in nested parens.

TabAtkins: Any time an IDENT is next to a parenthesis, we require white-space.

plinss: on the outside of either parenthesis.

RESOLUTION: MQ requires white-space on both sides of a parenthesis

Bert: Don't require it in the font shorthand

… basically the same case.

… If you have the font shorthand. "font: Times/**/10pt" is fine, but omit comment is not.

plinss: Times10pt becomes one item

SimonSapin: If you aren't familiar with the tokenizer, it's much more understandable than with parentheses.

Bert: But we're talking about consistency

plinss: Really only an issue with parentheses.

Bert: An issue with all tokens with more than one character. Also with the ~= or the ||.

plinss: That's an interesting change, going back to syntax.

… if the attribute matcher becomes one token if they had a comment between before

… that's a functional change.

TabAtkins: A precedent of ignoring comments in weird places.

plinss: They kind of deserve it.

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.

TabAtkins: Where would we define this?

… Values and Units?

… because it changes the prop grammar.

plinss: Syntax?

… it's a fundamental thing.

TabAtkins: Don't want a resolution that requires us to re-ask about it.

RESOLUTION: white-space between any IDENT an the outside of a parenthesis.

SimonSapin: The proposal was to require white-space on both sides.

plinss: Yes, do that everywhere

TabAtkins: That's what we require in @supports.

<SimonSapin> plinss: yes, both )<ident> and <ident>(

Bert: Just came to mind: can make 'and' a keyword, so it can be followed by paren.

TabAtkins: The issue is not related to 'and' specifically.

… Anytime you have keywords next to parens.

… Anytime a paren is valid by itself and an ident is valid next to it.

TabAtkins: One example is in grid syntax, if we switch to named line syntax

… (x y)auto needs white space.

… so no tightly-bounded set of keywords.

TabAtkins: All parentheses, or just naked parentheses? what about an ident following a function?

… function, the concept, not the token.

plinss: could it be a compat risk?

… ident after function.

fantasai: Yeah, gradient followed by length in background shorthand. A likely typo.

plinss: So we can't require it everywhere.

TabAtkins: So only naked parenthesis groups

plinss: We don't have naked parentheses anywhere else, so not a problem

dbaron: We have it inside calc()

TabAtkins: But you never have an ident.

… Need a delim, no implied multiplication.

fantasai: One reason why we feel it's awkard and want symmetry in MQ and @supports is that they are conjunctions.

… I'm happy if we just require it for conjunctions.

TabAtkins: If we did that, and didn't care about end parens, we could just make the parser recognize and( as a function token.

… dropping the comment.

… and be invalid.

plinss: I guess that's fine

TabAtkins: Can handle it either way

plinss: No, I don't think that's fine.

… url/**/( is not a URL token

… That would turn it into a function.

… making it valid.

TabAtkins: Handle it as grammar then.

… idents followed by open parenthesis must have white space between the two unless it's a function.

RESOLUTION: (replaces previous resolution) Idents followed by open parenthesis must have white space between the two unless it's a function.

CSS escapes in attr() values

SimonSapin: attr() defined in the values spec

… This function now takes a parameter with expected type

… can pass integer etc.

… In the defining for string and url, we say that the absolute value is passed

… should clarify whether CSS escapes are interpreted, and I think they should not be.

… If they need to be serialized, we may need to add escapes, but that's a separate concern.

TabAtkins: att="foo\33", content: attr(att) displays "foo33" or "foo\33"?

plinss: Don't want to move escapes from one context to another.

… it should be resolved before.

glazou: Entities should not leave their context.

RESOLUTION: String and URL types for attribute literally takes the attribute's value without parsing.

Alignment

<SimonSapin> (previous topic) In particular: clarify that no CSS escaping is involved. Probably remove wording like "parsed as the contents of a CSS <string>".

TabAtkins explains concepts, but not the basic properties

TabAtkins: This applies flexbox alignment props to rest of CSS

fantasai: Most keywords are axis agnostic, so put them in a separate section

TabAtkins: Only non-obvious are self-start and -end

… [missed] are defined based on the mode and directionality of the parent element

… self-* are defined based on the element itself.

… flex-start and -end are based on the flex directionality instead of the writing ode

dbaron: Do flex-start and -end fall back?

fantasai: to start and end.

… if not flexbox

fantasai: we have left and right, because sometimes you want that, but we can't always fulfil that.

TabAtkins: And helps explain <align>

fantasai: stretch depends on the layout mode, defined further down

… We pulled the baseline definition from 2.1 and put it here.

… Flexbox also has it

dbaron: doesn't distinguish between inline-block and [...]

… defined to use last-line baseline in 2.1

… Need to spec first-line basline and last-line baseline

… and which are used for different things.

… first-line and last-line baseline interaction is complicated, so need to define based on context, and research it.

… Don't expect impls to be sensible.

RESOLUTION: Need more work on baseline section, define first-line and last-line baseline.

fantasai: Block-axis of table is undefined.

… Table with a block of text inside, with a vertical text context, then the block axis will align with the inline axis

… Need a concept of baseline for each box

… Is it based on the baseline of the first column, or does it not have a baseline?

TabAtkins: No testing yet

fantasai: Basing on first column makes sense

Bert: Why not center?

fantasai: then you would center it.

TabAtkins: There is a keyword for that.

fantasai: We'll do another pass, but needs review eventually.

fantasai explains distributed alignment

TabAtkins: space-evenly is new, based on requests to flexbox

fantasai: Useful for two-column layout with different layout models in each

TabAtkins: 'stretch' came from Grid Layout.

fantasai: Needed for flex lines.

fantasai explains overflow alignment

fantasai explains justify-content and align-content

dbaron: not handled the same way as the 'align' attributes?

TabAtkins: We have special keyword.

dbaron: People have trouble following, not really working as an introduction.

TabAtkins explains justify-items

TabAtkins: can choose legacy behavior

dbaron: My issue was with how you mapped HTML alignment attributes that don't have a BFC.

fantasai: Vertical alignment in the vertical axis forces a BFC.

… but might need thinking about

… might also need horizontal axis.

TabAtkins: Can only use the block-axis one on blocks

… get center behavior by using legacy

… The property that does that does not have the BFC behavior

Bert: 'safe' and 'true' centering…

… I want to reintroduce true centering in text-align, even where there's a flow.

… and margin: auto, where I want centering without clamping

fantasai: This spec takes those props and applies them to all box models

TabAtkins: Don't use margins to center. Use align property to choose true center.

fantasai draws case with shrink-wrapped table with margins and centering.

fantasai: Want at least a certain margin, but also want centering. This is a better model for that, using justify-self.

… have cake and eat it

fantasai: justify/align applies to block/inline.

SimonSapin: block-align and inline-align?

TabAtkins: Flexbox doesn't care about your writing direction

… prop names are not renameable.

… Need to discuss abspos

Bert: Can I use other props in the normal flow?

TabAtkins: Can align the entire block's contents

… It's defined in the spec.

fantasai: Vertical centering: use align-content on an element

TabAtkins: Spec is split into two axes and three alignments applied to them

Bert: last column "Applies to" answers my questions.

… Have to rewrite Box Model

Rossen: These apply to border box or margin box?

fantasai: Margin boxes.

TabAtkins: In case of vertical-aligned paragraphs, the outermost bounding box of the contents.

Rossen: justify-self: true center on box with 25% width and 50% left margin, will be centered with the margin box?

TabAtkins draws on board

Rossen is satisfied

TabAtkins: Let's talk about abspos

fantasai: The plan of this draft is to make it easy to center things, including abspos

… The containing block for your asbspos item has offsets specified

… That creates a modified containing block.

… by default, you do as in 2.1

… If you specify center, then you'll shrink-wrap.

dbaron: 2.1 isn't quite that simple. Function of wether widht and height are specified

TabAtkins: If neither is auto, then we do these things.

… was confusing to write!

… If you have explicit margins and left and right props, then when calculating auto width, shrink to fit.

dbaron: Also, when no auto width, also align.

Rossen: change of behavior?

fantasai: No, compatible with 2.1

TabAtkins: stretch is default. Absposes behave as in 2.1
... Possible that there are some deep details that we missed, so needs review at some point.

fantasai: Get true alignment in grid and flexbox, but safe alignment in doc-centric layout, i.e. tables and blocks.

… Can't make them all safe, because flexbox has true.

TabAtkins: Could define whatever for blocks

Rossen: Should keep doc-centric ones safe and app-centric true.

fantasai describes property index

TabAtkins: Please someone look at legacy left/right/center, is there a better way to do it?

fantasai: Want to express that we're enforcing alignment.

… Right now only with left/right/center, but if it's useful, can align with start/end.

… Think about: do we want to allow it for other keywords.

fantasai describes auto/legacy

<dbaron> http://dbaron.org/css/test/2013/transition-reversing-demo

Reversing interrupted transitions

dbaron: only tested in gecko

… relied on mouseenter/mouseover, but those are even worse than a decade ago

dbaron and TabAtkins discuss JS implementation

dbaron explains various proposals in testcase

dbaron: There were other proposals, but I didn't implement

TabAtkins: Your proposal is better than the current spec, at least.

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?

dbaron: yes

SimonSapin: What if enter a transition and go to another one?

dbaron: No special treatment. Hard to impl. sensibly.

fantasai: if we have transitionin but not -out?

dbaron: Then will not have transitionout.

dino: What if a different timing function or duration? should break reversal.

dbaron: Disagree.

… in many cases people will want different timing functions, because they want that behavior.

… With my approach, they'll still get the specified timing function for each direction.

dbaron gives example with timing function on hover state

dino: People that care about this will want to tweak everything. Can't address that without adding props.

… Just make it work for the majority of cases

fantasai: If timing-in was 4s and -out was linear 4s…

dbaron: My proposal looks only at value, not timing.

… Sometimes 50 % through value space in 12 % of the time

… I say 50 % in 50 %

dino: If linear in both directions, 4s one way 2s in the other…

[not minuting clarifying discussion]

fantasai: What if the timing function is slow for 15% and then slow?

dbaron: That's ease-in

… If you mouse out at 50%, the time going back is close to the time going forward

… Time going back was shortened quite a bit

krit: ease-in is better with the current spec, ease-out is better with your proposal

dino: Depends on when you interrupt it

rik: goes too fast back when shortening the time

dbaron: Don't like discontinuity between 99% and 100%

dino: Some people might want an interrupted transition at 99%, pretend it finished.

dbaron: Mine: it gives 99% of the duration, so almost undetectable.

dino: Should just pick one, yours is fine. Let's implement it and see.

dbaron: Always like this in Gecko

krit: Safari just unprefixed transitions

dino: Concern is that people have content where they instead of transitionend event assumed that something happened.

… we're effectively changing t-duration on them.

TabAtkins: Adding a delay between the real end and the …

dbaron: Probably need some real events for interruption

… no transitionend event.

dino: There's interrupted and there's paused.

… suspended, e.g. if animations are paused on scroll

… duration is possibly longer

… People have requested that if prop is set to same value, then no transition.

… Adopt your proposal.

cabanier: Apple's spec is better, actually.

dino: I don't care much. Want to stop hover complaints.

… Safari has no reversing, so need to implement to see.

cabanier: Don't we already have a demo for side-by-side

dino: Need a complete implementation.

krit: Can also be decided on CR.

plinss: Do we want to change?

TabAtkins: Spec behavior is bad.

krit, cabanier: no, not bad.

dino: We don't know, because we haven't implemented it.

… propose dbaron's suggestion. Firefox already shipped, looks good enough.

RESOLUTION: dbaron's proposal for reversing interrupted transitions is accepted.

Meeting adjourned.

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference
07 Jun 2013

Attendees

Contents

Selectors 4

February-or-so Face-to-Face

Font Load Events

font-language override

Backporting level 3 changes to 2.1

Text Decoration

pseudo-stacking contexts

Text decoration, one more issue

Reversing interrupted transitions

white space in media queries

CSS escapes in attr() values

Alignment

Reversing interrupted transitions

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference 07 Jun 2013

Attendees

Contents

Selectors 4

February-or-so Face-to-Face

Font Load Events

font-language override

Backporting level 3 changes to 2.1

Text Decoration

pseudo-stacking contexts

Text decoration, one more issue

Reversing interrupted transitions

white space in media queries

CSS escapes in attr() values

Alignment

Reversing interrupted transitions

Summary of Action Items

Scribe.perl diagnostic output

Cascading Style Sheets (CSS) Working Group Teleconference
07 Jun 2013