- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 24 Dec 2012 18:59:18 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Special thanks to Leif for preparing the summary~
Summary:
- Sign up for Tucson F2F now, or risk not getting a hotel!
- RESOLVED: Rossen Atanassov replaces Alex Mogilevsky and Phil Cupp
as editor of Flexbox and Grid.
- Discussed Flexbox interaction with multicol and writing mode
- RESOLVED: Publish Working Draft of CSS Cascade Level 3 to replace
the 7-year old one, mentioning dbaron's issues about
scoping and defaults
- RESOLVED: Spaces not optional around 'and', 'or' and 'not' in @supports
- RESOLVED: Publish css3-text-decoration LC with intro from fantasai
- RESOLVED: Daniel Glazman is our new liaison with EPUB
- Discussed Animations issues: animation-play-state in shorthand;
animations starting in descendant when no longer 'display: none';
what counts as valid keyframes
- RESOLVED: Put animation-play-state back into the animation shorthand,
and let the shorthand reset it if not mentioned
====== Full minutes below ======
Present:
Peter Linss
Leif Arne Storset
Simon Sapin
Rebecca Hauck
Edward O'Connor
Alan Stearns
John Jansen
Steve Zilles
Simon Fraser
Anton Prowse
Bert Bos
Tab Atkins
David Baron
John Jansen
Arron Eicholz
Rossen Atanassov
Alexis Menard
Florian Rivoal
Tantek Çelik
Scribe: Leif
Administrivia
-------------
plinss: agenda additions? Did get note from sylvaing.
dbaron: Did you see my comments on animations?
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0268.html
plinss: no
dbaron: I replied to the minutes
plinss: If we have time, otherwise defer to next time
plinss: molly has been reminding people to sign up for Tucson on wiki
plinss: still probably people missing. Sign up now! Or risk not having hotel
plinss: She also sent a hotel booking number
plinss: Microsoft asked for Rossen to take over editing from Alex and Phil
plinss: for Grid and Flexbox
plinss: no objections
RESOLVED: Rossen new editor of Grid and Flexbox, taking over for Alex
and Phil
Flexbox
-------
plinss: We've been kicking a few issues down the curb.
TabAtkins: Still not ready to talk about them.
Rossen: the multiline issue?
Rossen: basically two issues
Rossen: reposted a couple of days ago
http://lists.w3.org/Archives/Public/www-style/2012Dec/0251.html
Rossen: has to do with what do we consider orthogonal
Rossen: Will vertical writing mode treat flexbox as vertical
<dbaron> are we now discussing the issue that TabAtkins said he wasn't
ready to discuss?
<TabAtkins> Yes.
Rossen: I don't see why we shouldn't allow multicol with a horizontal
writing mode behave like a vertical writing mode 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
TabAtkins: willing to look into something similar here
Rossen: Are you talking about the algorithm you gave to fantasai to
resolve auto-width columns
TabAtkins: No, something recent a mozilla dev brought up to make
multicol and flexbox work consistently
<dbaron> (Daniel Holbert)
TabAtkins: We worked on the multicol sizing algorithm so would respond
better to wrapping in a flexbox, could do something similar
for flexbox in flexbox
TabAtkins: current naive solution doesn't always give good results
TabAtkins: not ready to discuss just yet
TabAtkins: 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
Publish update to css3-cascade
------------------------------
TabAtkins: See summary e-mail
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2012Dec/0199.html
dbaron: Raised a bunch of issues yesterday
dbaron: Might be worth getting it a little more stable
TabAtkins: Can we not just address them quickly in LC?
dbaron: We should be mostly alright
dbaron: In your reply you said that scoping for !important and scope
goes backwards through the scopes rather than forward
dbaron: that seems backwards to me, and I didn't see it in the spec
TabAtkins: In the paragraph before we talk about the style attribute,
to match the behavior of non-!important origins go UA-author
rather than author-UA
TabAtkins: Scoping is kind of like nested origin, so should probably
do the same thing
TabAtkins: 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 WD?
dbaron: I'm ok with publishing as long as we note the defaults thing
as an issue
<dbaron> default issue: http://lists.w3.org/Archives/Public/www-style/2012Dec/0270.html
dbaron: and maybe note the scope thing as an issue
<dbaron> the scoping issue is the issue of whether !important should
go in reverse for scopes
TabAtkins: Fine with that
TabAtkins: just want to get a new WD out, last is 7 years old
TabAtkins: people talk about TR version
RESOLVED: Publish Cascade WD with issues dbaron mentioned (scoping and
defaults)
Conditional syntax
------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2012Dec/0100.html
<plinss> http://lists.w3.org/Archives/Public/www-style/2012Dec/0142.html
dbaron: Before we get into details, we should discuss whether we want to
make the change
dbaron: that's more important
TabAtkins: neutral. Understand the authoring hazards. But should make
the change not just for @supports, but other boolean things,
like Media Queries
TabAtkins: 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
dbaron: unless there's broken content out there that doesn't work now
dbaron: but pretty rare
dbaron: Worry is it might be bigger than just those two, but probably not
SimonSapin: I would prefer making this change everywhere
SimonSapin: but another solution is to require spaces in the grammar
plinss: Any thoughts?
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: Requiring 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
plinss: doesn't require learning the difference between function tokens
and other things
dbaron: Don't want to introduce a not function later that's something
different
plinss: If we never introduce a not function then spacing is optional
TabAtkins: Not willing to say never introduce a 'not' function
sylvaing: From the calc experience, requiring spaces where people don't
expect them is painful
sylvaing: they will learn, for sure
dbaron: Words and symbols are different, 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?
dbaron: I'll figure the wording out. It's an editorial question
<SimonSapin> S* → S+ ?
<dbaron> SimonSapin, yeah, mostly, but there might need to be prose
too... I'll need to check
RESOLVED: Spaces not optional in @supports
Text-decoration LC
------------------
plinss: fantasai will write intro
SteveZ: No objection, but strange to send to LC a document that's not
done yet
plinss: Just has to write intro, wants resolution early because of
holidays
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, but no
meeting for 2 weeks
RESOLVED: 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
sylvaing: because he implements EPUB
plinss: I'm trying to get HP to join
RESOLVED: glazou liaison to EPUB
CSS3 Color Errata
-----------------
dbaron: Just added a test, needs review
dbaron: 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
---------------------------------------------
plinss: krit brought it up, but not here today
plinss: Can anyone else talk about this?
plinss: Defer this one
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
TabAtkins: 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
dbaron: but also some other things should be decided
dbaron: Simplest thing is animation-play-state not being in the shorthand
dbaron: on purpose
dbaron: 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
TabAtkins: 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
dbaron: background does it
dbaron: font
<dbaron> border resets border-image
TabAtkins: I think so, unless we made it more complicated
plinss: Not an unreasonable behavior, there's precedent
plinss: using a shorthand should reset everything in that type of property
smfr: Since this is a new spec and fairly complicated stuff, we should
go for least surprise
smfr: not including play-state in the shorthand
dbaron: You're taking back last week's resolution
smfr: yeah, we didn't consider the resetting problem
plinss: What was the problem of having it in the shorthand?
TabAtkins: Ambiguity with animation-name
dbaron: like everything!
TabAtkins: How are we not ambiguous with the others?
dbaron: Lots of fun, spec doesn't get into it, requires a lot of care
with serialization and parsing
dbaron: thread 6 months ago
TabAtkins: I see, There's a note in here, probably improperly worded
TabAtkins: 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
TabAtkins: [missed]
dbaron: Would not be web-compatible, I suspect
TabAtkins: in that case, spec is underdefined
TabAtkins: issue 3 about this
dbaron: Let's get back to earlier issue
dbaron: smfr says we should scratch last week's resolution
TabAtkins: agrees
dbaron: I'm fine with that.
dbaron: Given the 3 options, fine with 2 options where shorthand resets
play-state
sylvaing: I think it's the more consistent option
sylvaing: but trying to think of compat issues
dbaron: Gecko always implemented it
dbaron: have not heard of compat issues
sylvaing: But it's only working there
sylvaing: now if we change the spec and other browsers support it…
smfr: I don't think including play-state in the shorthand would cause
WebKit problems, because 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
sylvaing: it will be invalid in IE 10, but not a huge risk at this stage
sylvaing: seems silly to not have it there
sylvaing: Will open a bug and fix the spec
RESOLVED: Put play-state back into the animation shorthand
dbaron: There was a resolution about animation starting when not
display: none
dbaron: two problems:
dbaron: Also applies to ancestor with display: none
TabAtkins: animation of child starts when ancestor 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
florian: should cover what dbaron said
dbaron: Spec is right
dbaron: Prose answered both of my issues
dbaron: third issue is hardest
dbaron: A resolution says animations only run with one at least one
valid keyframe
dbaron: It would make sense to solve a different issue first
dbaron: and make this issue's solution match that one
dbaron: And that is what happens when some values in keyframes cannot
be interpolated
TabAtkins: Doesn't exist anymore
TabAtkins: 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
examined separately for any property
dbaron: 25% keyframe mentioned top, and 100% mentions left
dbaron: you animate props, and those props may be present in keyframes
dbaron: Depends on whether animation is animating any props.
<TabAtkins> @keyframes { 50% {} }
TabAtkins summarizes what dbaron said and scribe couldn't hear:
keyframes rule with valid keyframes but no property in it
TabAtkins: 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
sylvaing: we don't ignore it, it's valid
sylvaing: even if nothing moves, I expect my events to fire
sylvaing: even if you have props in there
TabAtkins: How does that jive with not firing events?
<TabAtkins> @keyframes foo {}
TabAtkins: this and the previous one looks the same to me.
sylvaing: good point
sylvaing: we can't just look at the keyframes
TabAtkins: Are you objecting to what we agreed last week?
sylvaing: yes
sylvaing: regardless of duration, if no props require animation, should
we fire
sylvaing: My question is more: does animation run if it has duration
or has property in it
<tantek> is there new information?
TabAtkins: Last week we agreed "prop"
sylvaing: we can do the same here
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: A use case would be an online animation editor
florian: starts an animation in a loop
florian: wants it to run even if it doesn't do anything
florian: before you start adding stuff in it, want events
florian: So may be worth firing events
florian: duration could be enough
plinss: Not sure we have a solid answer
plinss: Defer to next year?
dbaron: Probably best
plinss: Enjoy your time off
Meeting closed.
Received on Tuesday, 25 December 2012 02:59:47 UTC