SV_MEETING_TITLE -- 19 Dec 2012

<stearns> bah

<scribe> ScribeNick: leif

plinss: agenda dditions? Did get note from sylvaing_away

dbaron_: Did you see my comments on animations?

plinss: no

dbaron_: I replied to the minutes

plinss: If we have time, otherwise defer to next time

<Ms2ger> www.w3.org/mid/20121218214248.GA2120@crum.dbaron.org

… molly has been reminding people to sign up on wiki

<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0268.html

… still probably people missing. Sign up now! Or risk not having hotel

… She also sent a hotel booking number

… Microsoft asked for Rossen to take over editing from Alex and Phil

… for Grid and Flexbox

… no objections

RESOLUTION: Rossen new editor of Grid and Flexbox, taking over for Alex and Phil

Flexbox

… kicking a few issues down the curb

TabAtkins: Still not ready to talk about them

Rossen: the multiline issue?

… basically two issues

… reposted a couple of days ago

… has to do with what do we consider orthogonal

… Will vertical writing mode treat flexobx as vertical

<dbaron> are we now discussing the issue that TabAtkins said he wasn't ready to discuss?

<TabAtkins> Yes.

… I don't see why we shouldn't allow multicol with a horizontal writing mode behave like a vertical writing with flex-flow: row

TabAtkins: This is very similar to something in multicol, we were able to come up with something that often gives ok results

… willing to look into somethign similar here

Rossen: Are you talking about the algorithm you gave to Elika to resolve auto-width columns

TabAtkins: No, something recent a mozilla dev brought up to make multicol and flexbox work consistently

<dbaron> (Daniel Holbert)

<SimonSapin> leif: is your mike close to your keyboard?

… We worked on the multicol sizing algorithm so would respond better to wrapping in a flexbox, could do something similar for flexbox in flexbox

… current naive solution doesn't always give good results

… not ready to discuss just yet

… Just need time and energy to think about this

<Rossen> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2022

Rossen: I can give the test case

plinss: Defer then

<SimonSapin> leif: great :)

Publish update to csc-cascade

TabAtkins: See summary e-mail

<TabAtkins> https://lists.w3.org/Archives/Member/w3c-css-wg/2012OctDec/0315.html

dbaron: Raised a bunch of issues yesterady

… Might be worth getting it a little more stable

TabAtkins: Can we not just address them quickly in LC?

dbaron: We should be mostly lalright

… In your reply you said that scoping for !important and scope goes backwards through the scopes rather than forward

… that seems backwards to me, and I didn't see it in the spec

TabAtkins: In the paragraph before we talk about style attr, to match the behavior of non-!important origins go ua-author rather than author-ua

… Scoping is kind of like nested origin, so should probably do the same thing

… Should override any contained scope

dbaron: Not sure that the rationale for the backwards thing for ua-user-author still holds

TabAtkins: I am surprised by that position, but not saying it's wrong.

plinss: But is there an objection to publishing?

TabAtkins: Sorry, didn't mean LC

dbaron: I'm ok with publsihing as long as we note the defaults thing as an issue

… and maybe note the scope thing as an issue

TabAtkins: Fine with that

… just want to get a new WD out, last is 7 years old

… people talk about TR version

<dbaron> default issue: http://lists.w3.org/Archives/Public/www-style/2012Dec/0270.html

RESOLUTION: Publish Cascade WD with issues dbaron mentioned (scoping and defaults)

Conditional syntax

<plinss> http://lists.w3.org/Archives/Public/www-style/2012Dec/0100.html

<dbaron> the scoping issue is the issue of whether !important should go in reverse for scopes

<plinss> http://lists.w3.org/Archives/Public/www-style/2012Dec/0142.html

dbaron: Before we get into it, we should discuss whether we want to make the change

…that's more important

TabAtkins: neutral. Understand the authoring hazards. But should make the change not just for @supports, but other boolean things, like MQ

… a global change

dbaron: I'm inclined to defer, because I haven't thought about the details

SimonSapin: We should also fix MQ, but not sure about compat

dbaron: Shouldn't be compat problem

… unless there's broken content out there that doesn't work now

… but pretty rare

… Worry is it might be bigger than just those two, but probably not

SimonSapin: I would prefer making this change everywhere

… but another solution is to require spaces inthe grammar

plinss: Any thoughts?

TabAtkins [too fast]

TabAtkins: Is SimonSapin's intent to avoid people typing spaces wrong from reading the spec?

dbaron: When suggesting requiring spaces, I meant also requiring a space on both sides of "and' and 'or'

SimonSapin: Consistency is good

TabAtkins: no problem with it

dbaron: Preference is requiring spaces after 'not' and on both sides of 'and' and 'or'

<dbaron> that's a weak preference, though

Bert: Agree with dbaron, but no strong opinion

… yet

SimonSapin: Requring spaces is an easy solution, but a better solution is to fix the grammar

<SimonSapin> spaces: easy solution; no spaces: better for authors

plinss: Requiring spaces allows us to introduce a 'not' function later

… doesn't require learning the difference between function tokens and other things

dbaron: Don't want to introduce a not function

<dbaron> ... later that's something different

plinss: If we never introduce a not function then spacing is optional

TabAtkins: Not willing to say never introduce not function

sylvaing: Form the calc experience, requiring spaces where people don't expect them is painful

… they will learn, for sure

dbaron: Words and symbols are differnt, though

SimonSapin: Remember that if we require spaces, anything invalid evaluates to false, and can later be negated

TabAtkins: Caught by the general invalid syntax

plinss: Consensus?

RESOLUTION: Spaces not optional in @supports

dbaron: I'll figure the wording out. It's an editorial question

Text-decoration LC

<SimonSapin> S* → S+ ?

<dbaron> SimonSapin, yeah, mostly, but there might need to be prose tooflorian I'll need to check

plinss: fantasai will write into

SteveZ: No objection, but strange to LC and document that's not done yet

plinss: Just has to write intro, wants resolution early because of holidays

SteveZ probably accidentally disconnected

SteveZ: I understand, but is it really not going to get published

plinss: dunno, but Bert will be away

Bert: Will be away until 8 Jan

TabAtkins: fantasai will be back at the end of the week, bu tno meeting for 2 weeks

RESOLUTION: Publish css3-text-decoration LC with intro from fantasai

EPUB liaison

plinss: glazou is willing to

sylvaing: He seems to be in a good spot to do that

RESOLUTION: glazou liaison to EPUB

<sylvaing> ..because he implements EPUB

plinss: I'm trying to get HP to join

CSS3 Color Errata

dbaron: Just added a test, needs review

… added errata in ED

TabAtkins: Thanks, we've been waiting for that

dbaron: Plan to raise an issue on the errata, but that's for later

Background-clip and origin order on shorthand

<darktears> Zakim: ??P5 is me

plinss: krit brought it up, but not here today

… anyone else can talk on this?

plinss: Defer this one

Should deal with case-sensitivity, fantasai and dbaron and have comments

oops

Case insensitivity

TabAtkins: 3 specs waiting for that, and fantasai and dbaron have comments

<dbaron> the most recent thread was http://lists.w3.org/Archives/Public/www-style/2012Dec/thread.html#msg239

dbaron: Can you state the issue?

TabAtkins: trying to, but can't right now

…let's do animations

Animations

<plinss> http://lists.w3.org/Archives/Public/www-style/2012Dec/0268.html

dbaron: In some cases I had trouble understanding what the resolution was

<Ms2ger> s/Publish css3-cascade LC with intro from fantasai/Publish css-text-decor-3 LC with intro from fantasai/

… but also some other things should be decided

… Simplest thing is animation-play-state not being in the shorthand

… on purpose

… Does that mean not specifiable in the shorthand, but it doesn't reset it, or does the shorthand reset it?

TabAtkins: I believe the former

<dbaron> https://www.w3.org/Bugs/Public/showbug.cgi?id=14787

… not specifiable, BUT reset by shorthand

dbaron: sylvaing and smfr agree?

smfr: I think the example of the shorthand, not including the property, could be surprising

dbaron: There are examples of that

… background does it

… font

<dbaron> border resets border-image

TabAtkins: I think so, unless we made it more complicated

plinss: Not an unreasonable behavior, there's precedent

… using a shorthand should reset everything in that type of property

smfr: Since this is fairly complicated stuff [missed]

… Since a new spec, we should go for least surprise

… not including play-state inthe shorthand

dbaron: You're taking back last week's resolution

smfr: yeah, we didn't consider the resettiong problem

plinss: What was the problem of having it in the shorthand?

TabAtkins: Ambiguaity with animation-name

dbaron: like everything!

TabAtkins: How are we not ambigiuos with the others?

dbaron: Lots of fun, spec doens't get into it, requires a lot of caer with serialization and parsing

… thread 6 months ago

TabAtkins: I see, There's a note in here, probably inpromprerly worded

… The first ident that appears is the animation-name

dbaron: wait, that's the opposite of what i expect

TabAtkins: The first time value is duration, the second delay

… [missed]

dbaron: Would not be web-compatible, I suspect

TabAtkins: in that case, spec is underdefined

… issue 3 about this

dbaron: Let's get back to earlier issue

… smfr says we should scratch last week's resolution

TabAtkins: agrees

dbaron: I'm fine with that.

… Given the 3 options, fine with 2 options where shorthand reset play-state

sylvaing: I think it's the more consistent option

… but trying to think of compat issues

dbaron: Gecko always implemented it

… have not heard of ocmpat issues

sylvaing: But it's only working there

… now if we chang ethe spec and other browsers support it…

smfr: I don't thiink including play-stae in the shorthand would case WebKit problems, becuase prefixed

florian: still large usage of unprefixed version

dbaron: Take back comment about Gecko… i followed the spec

sylvaing: In retrospect that should have been the definition, but with unprefixing, awkward to change

smfr: play-state is not used much in the wild

sylvaing: Our browser sticks around a bit longer than the average

… it will be invalid in IE 10, but not a huge risk at this stage

… seems silly to not have it there

sylvaing: Will open a bug and fix the spec

RESOLUTION: Put play-state back into the animation shorthand

dbaron: There was a reoslution about animation starting when not display: none

… two problems:

… Also applies to ancestor with dipslay: none

TabAtkins: animation of child starts when ancetsor gets box

sylvaing: I'll have to check what I put in there.

dbaron: I was just reading minutes, not the spec, so may be in there

sylvaing reads from spec

… should cover what dbaron said

dbaron: Spec is right
... Prose answered both of my issues

… third issue is hardest

… A resolution says animations only run with one at least one valid keyframe

… It would make sense to solve a different issue first

… and make this issue's solution match that one

… And that is what happens when some values in keyframes cannot be interpolated

TabAtkins: Doesn't exist anymore

… all values are interpolatable

dbaron: Also in level 3?

TabAtkins: Dunno, thought to do it quickly

dbaron: Even so, does a valid keyframe, mean something with a valid keyframe selector, or that and a property inside

sylvaing: Could be empty

dbaron: Reason I think it should have property is that keyframes get examine seapartatly for any property

… 25% keyframe meniotned top, and 100% mentions left

… you animate [missed]

… you animate props, and those props may be present in keyframes

… Depends on whether animation is animating any props.

<TabAtkins> @keyframes { 50% {} }

TabAtkins summarizes dbaron: keyframes rule iwth valid keyframes but no property in it

<dbaron> sorry, my parents don't actually have any non-cordless phones in the house

if you have that, would it be invalid

<TabAtkins> @keyframes foo { 50% {} }

sylvaing: If you mean does it fire animation if there's a duration on it

… we don't ignore it, it's valid

… even if nothing moves, i expect my events to fire

… even if you have props in there

<TabAtkins> @keyframes foo {}

TabAtkins: How does that jive with…

… not firing events

… this and the prev one looks the same to me.

sylvaing: good point

… we can't just look at the keyframes

TabAtkins: Are you objecting to what we agreed last week?

sylvaing: yes

… regardless of duration, if no props require animation, should we fire

… My question is more: does animation run if it has duration or has property in it

TabAtkins: Last week we agreed "prop"

sylvaing: we can do the same here

<tantek> is there new information?

TabAtkins: Yes, for the same reason as last week

sylvaing: Not sure last week's was valid

florian: So what does it mean for dbaron's issus?

dbaron: This is the primary issue

smfr: keyframe sets without properties inside, never seen that in the wild

TabAtkins: Motivation seems to be filling with script

florian: [can't hear]

… a UC would be an online animation editor

… starts an animation in a loop

… wants it to run even if it doesn't do anything

… before you start adding stuff in it, want events

… So may be worth firing events

… duration could be enough

plinss: Not sure we have a solid answer

… next year?

dbaron: Probably best

plinss: Enjoy your time off

plinss, should I do something in particular now?

as scribe, I mean

- DRAFT -

SV_MEETING_TITLE

19 Dec 2012

Attendees

Contents