- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 20 Feb 2013 22:02:44 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Animations
----------
- RESOLVED: Add Rossen as editor to Animations
- RESOLVED: Øyvind's clarification accepted for
http://lists.w3.org/Archives/Public/www-style/2011Sep/0392.html
- Discussed reversing timing functions. See follow-up thread at
http://lists.w3.org/Archives/Public/www-style/2013Feb/0524.html
- Discussed trigger for starting animations. It's not onload, but unclear what it is.
- RESOLVED: keyframe rules cascade
- RESOLVED: Keep pseudoElement on animation events. Mark at-risk. Revisit
in a few months if it's a web-compat problem.
Publications and Stage Transitions
----------------------------------
- RESOLVED: New WD for CSS3 Paged Media
- RESOLVED: Allow pseudo-class combinations for @page selectors
- RESOLVED: Publish css-print with fantasai as editor, updated changes section.
- RESOLVED: css3-conditional to CR
- RESOLVED: New WD counter-styles, expect LC in 2 weeks or so
Miscellaneous
-------------
- RESOLVED: Add percentages to column-gap, not to column-width (use
column-count for that, it's better)
- RESOLVED: Push font load events out to separate spec
- Goodbye to Sylvain! Leaving role as MSFT CSSWG rep to go to Adobe...
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos (via IRC)
Tantek Çelik
John Daggett
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Dael Jackson (observer)
Dean Jackson
John Jansen
Brad Kemper
Peter Linss
Alexis Menard
Ted O'Connor
Anton Prowse
Florian Rivoal (late)
Simon Sapin
Dirk Schulze
Nick Van den Bleeken
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/02/20-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Feb/0461.html
Scribe: fantasai
Administrative
--------------
glazou: Extra items?
krit: Edited Masking spec, would like to ask for review by email, is that ok?
SimonSapin: Proposal for adding percentages to column-width/column-gap
glazou: You wondered if doable in CR. Let's discuss that after animations
glazou: Anything else?
* dino agenda += moment of silence for sylvain
glazou: Start with Animations, b/c sylvain on call for last time
Animations
----------
-- Editorship --
sylvaing: Any objections to adding Rossen as editor to Animations?
RESOLVED: Add Rossen as editor to Animations
-- Case-sensitivity --
<glazou> LOL case sensitivity...
sylvaing: Clarification for me, case-sensitivity of user-defined idents
was resolved in Tucson. Is that in CSS3 Values yet?
TabAtkins: Don't think edit has made it in yet, but will do today.
sylvaing: Ok, will refer to that.
-- Multiple values --
<sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Sep/0392.html
sylvaing: Current wording ignores multiple values, multiple keyframes, etc.
sylvaing: Øyvind proposed some text.
[see email]
sylvaing: I think good idea to clarify that.
<dino> +1 to clarifying that text
dbaron: There was an interop issue with definition of valid @keyframes rule
dbaron: Previous decision on that, make sure it's clear too
RESOLVED: Øyvind's clarification accepted for
http://lists.w3.org/Archives/Public/www-style/2011Sep/0392.html
-- Reversing Timing Functions --
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14805
sylvaing: Question from dbaron on using timing functions inside keyframe
rules
sylvaing: Understood that if you have timing function on keyframe rule,
... next one
sylvaing: What if you're going in a different direction, e.g. reverse /
alternate?
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Mar/0744.html
sylvaing: When you go from N to N+1, you always use timing function
defined in frame N.
dino: Intended, but not written. Sorry. Yes.
TabAtkins: Timing function on a keyframe defines that particular gap,
regardless which way you're going.
dino: Maybe add to spec that animation literally runs in reverse.
dbaron: Except it doesn't
dbaron: I don't think it does.
dino: ?
dbaron: Do we reduce the math of the timing function, or use the appropriate
timing function?
dbaron: e.g. if you have ease-in(), then you ease-in() to that point
regardless of direction.
glazou: Right, so we are not reversing animation per se
[...]
sylvaing: What does Gecko do?
dbaron: Have to check
dino: we process value from 0 - 1, [...] so timing function does actually
play backwards when you go in a reverse order
dino: If you're 10% through reverse, we calculate as if 90% of going forwards
glazou: Ok, let's defer resolution of this issue until dino's email
sylvaing: Yes, and we should check implementations. I think we do what
Gecko does
<dbaron> you mean, you think IE does the same thing that I *think* Gecko
does? :-)
sylvaing: But don't think it's a major breaking change if we have to
swap it.
smfr: Think we don't what to change WebKit. And intent *is* that reverse
is a mirror image of the forward animation.
-- Start of Animation --
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15848
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0280.html
sylvaing: Prose in spec about defining start of animation
<sylvaing> # The start time of an animation is the latter of two moments:
<sylvaing> # the time at which the style is resolved that specifies the
<sylvaing> # animation, or the time the document's load event is fired.
sylvaing: Hard one to test, and not exactly what browsers do, really
sylvaing: I'm wondering, what is the point of this statement?
sylvaing: Or is it really, animation applies when the animation-name
property is resolved?
smfr: in WebKit we did start until document load, but that's no longer
true.
dbaron: Don't think it was true at the time I implemented animations
in Gecko
sylvaing: Also, hard to test. Interesting implementation details, not
sure how you'd test across browsers.
sylvaing: Should really say it applies at the time the animation-name
property is resolved.
sylvaing: Of course, we're getting to, we don't define when things are
computed.
sylvaing: But document load is bogus.
krit: Does that mean that document is loaded (onload), or all required
parts loaded (e.g. all style sheets)
krit: When you have document load, can you be sure style is resolved
for all parts of the document?
TabAtkins: [...]
sylvaing: Why does it matter?
krit: For SVG, when the document is read for complete rendering, that's
when animations start.
smfr: We specced that way for CSS originally, then changed our minds
krit: Might need to align SVG to this then
sylvaing: Sadly, don't think we have priority on when things are computed.
sylvaing: Don't want to leave statement in there that doesn't agree with
implementations.
dbaron: I think we need to fix this to match what everyone is doing,
b/c we all agree that this is wrong.
sylvaing: Think it goes back to resolution earlier, animation applies
when animation-name is computed, and have last valid @keyframe
in sorted order. That's it
krit: Suppose you have huge document, like HTML5 spec, animation on one
of first elements that get rendered.
krit: Do animations wait until whole document is loaded?
dbaron: we all implemented that they start before the whole document is
loaded
krit: Then how do you align animations?
sylvaing: When this is resolved is up to UA.
sylvaing: Whenever value computation occurs.
krit: Can we add a sentence that says this might be more precise in the
future?
dbaron: I would prefer to define it more precisely in this spec, even if
we don't have definitions for all terms
fantasai: krit's point wrt aligning animations?
dbaron: We don't align animations.
krit: That's the point of Web Animations, to align them.
TabAtkins: Might fix later
dbaron: Don't think it would be acceptable to fix it later, which is why
I think we should define it now.
sylvaing: Later on would be enough content that we would be unable to fix it.
ACTION: dbaron propose wording for
http://lists.w3.org/Archives/Public/www-style/2009Dec/0280.html
<trackbot> Created ACTION-543
-- Duplicated Keyframes --
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21018
sylvaing: Duplicated keyframes
sylvaing: If you have N for 50%, you drop previous ones, at least that's
what spec recommends.
sylvaing: dbaron suggested at the time maybe we should cascade them.
sylvaing: Not sure what it means wrt compat, if Gecko does that.
dbaron: Gecko does cascade them. Has not been a compat problem.
dbaron: I suspect that if we tried to change it in the other direction,
might be a compat problem. But this one not so much. Or at least,
we didn't hit any problems.
dbaron: I really feel that what the spec says is really just very unlike
everything CSS does.
* fantasai agrees
dbaron: It's the norm in CSS that if you have one declaration block, and
you have another that has one property, it just overrides that
one property, not throw out entire previous block. Reasonable
expectation of authors.
glazou: The OM for animations only returns one rule for the keyframe,
not multiple.
TabAtkins: The OM for keyframes is completely busted.
glazou: Whatever we decide on this topic, the OM should reflect that too.
glazou: If we allow multiple keyframes with same key to cascade, then
findRuleForKey should become findRulesForKey and return multiple
rules. Otherwise won't be editable.
sylvaing, TabAtkins: fair point
sylvaing: I agree with dbaron's point in generally, not very CSS-like
to have bunch of selector-like constructs, and last one cancels
previous ones instead of having cascade.
glazou: I agree
sylvaing: When you ask for 50% rule, you want all rules that are for 50%,
you want in order of course. maybe at some point, maybe not
in this level, give me computed/resolved rule for 50%?
glazou: Yes, I agree with that, we need that too.
glazou: You could retrieve that from the current findRule in the OM,
and if you have multiple keyframes, we need API for that.
sylvaing: Do we need that for this level?
TabAtkins: If you're looking for the value for width being animated at
50%, and specified in different keyframes, if you can get a
list, then it's easy to iterate the list and get that.
glazou: You said OM is busted. OM has to be consistent with the prose.
TabAtkins: We can do a minimum fix, and add to it later.
glazou: Minimum we could do is remove findRule and add findRules.
fantasai: You could maybe define findRule to return the cascaded result?
dbaron: No, it needs to return something you can edit.
sylvaing: Still need to figure out OM. Are we resolving on cascading
the keyframes?
sylvaing pokes dino
smfr: I think that's fine. Don't think any content has multiple keyframe
rules, except by mistake.
sylvaing: OK, so we'll update that. Then have open issue on updating OM
to give a list of rules.
sylvaing: and another issue on adding API for combined ruleset
ACTION: glazou send proposal for updated findRules API for animations
keyframe rules
<trackbot> Created ACTION-544
RESOLVED: keyframe rules cascade
sylvaing: That's it.
-- Animation Events on Pseudo-elements --
dino: Alexis has an issue
darktears: We do have a problem with the pseudoElement attribute on
animation events.
darktears: Someone asked on mailing list, how do I know when animation
finished on a pseudo-element?
darktears: You don't know today.
<darktears> http://lists.w3.org/Archives/Public/www-style/2013Feb/0062.html
<darktears> http://dev.w3.org/csswg/css3-transitions/#transition-events
sylvaing: Same problem for Transitions
darktears: Mozilla people bring issues wrt compatibility
<sylvaing> transition and animation events expose the same property
<darktears> right
TabAtkins: If you just fire plain animation issues with pseudoElement,
you might get unexpectedly more animation events.
<darktears> WebKit ships it on Transitions
dbaron: I think we should try implementing it and see if compatibility
problem.
<darktears> it's implemented
sylvaing: Yeah, there's not a lot of content out there that uses animations
on pseudo-elements. If only because it was not interoperable.
sylvaing: Event handler code, wouldn't need to filter for pseudo-elements
TabAtkins: If it didn't work on WebKit, nobody would have written code
for it, right.
+Florian
sylvaing: pseudoElement property on these events is pretty new, so no
real-world content with event-handling code that checks for it.
sylvaing: True that more events fired. Could be some breakage, but hard
to imagine it would be huge.
darktears: Use cases Boris brought on mailing list were rather exotic
darktears: Problems and use-cases he saw on real content, but to be very
honest, was very broken code.
darktears: Website would be broken if WebKit shipped unprefixed
sylvaing: ...
sylvaing: Later add animation on ::before
sylvaing: Your animation code is not checking for the pseudoElement on
that element.
sylvaing: Do your animation event processing too early, there is a risk
of breakage.
sylvaing: Not sure what we can do here.
sylvaing: Strategy of changing event name...
glazou: If we want the opportunity to change, we can consider that
real-life use cases are rare enough, still allows us to change.
glazou: Not necessarily true in near future. So it's right time to do this.
<darktears> I mean in WebKit we do have it implemented to Transitions
and will probably ship soon with Chrome. We'll get feedback
soon
<darktears> so far nothing showed up
glazou: Seems we running in circles.
glazou: Are we proposing to add pseudoElement? Yes/no?
sylvaing: It's already in there
glazou: Do we care to remove it?
TabAtkins: Since objections seem to come from Mozilla, but dbaron's ok
with trying it, think we keep it.
dbaron: Will come back with info on this, but takes awhile to ship,
so in a few months
<darktears> ok for me
fantasai: Can mark it at-risk, so won't hold up for CR.
<darktears> yes
fantasai: Also it's a "let's try and implement it" change, that's what
CR is for anyway.
RESOLVED: Keep pseudoElement on animation events. Mark at-risk. Revisit
in a few months if it's a web-compat problem.
Paged Media / Print Publications
--------------------------------
glazou: First one is Paged Media
SimonSapin: Since we requested new WD, some ppl have started reviewing
it, so I have some old issues I found that I had lost, and
some new issues too
SimonSapin: Some easy to fix, want to fix in next few days. Some I want
to defer after new WD.
glazou: Anything really critical that could block WD?
SimonSapin: Don't think so
glazou: What do ppl think of releasing new WD of css3-page?
<sylvaing> is always in favor of new drafts
RESOLVED: New WD for CSS3 Paged Media
SimonSapin: We just added new feature, having multiple pseudo-classes
in @page selectors. New in draft, but we have two
implementations already.
<fantasai> e.g. @page :first:left
glazou: Did you update specificity section?
SimonSapin: still need to do that, filed an issue
RESOLVED: Allow pseudo-class combinations for @page selectors
glazou: Next one, Print Profile.
fantasai: Needs to be published with Paged Media.
https://www.w3.org/Style/Group/css-print/
fantasai: Just switched it to WG Note, and updated references.
<dbaron> https://www.w3.org/Style/Group/css-print/#section-images
fantasai: Section on handling image-rendering properties, specifically
object-fit / object-position.
fantasai: Previous CSS Print profile included references to old versions
from css3-page WD. But was implemented by at least one printer
implementation. Added section to allow such implementations to
interpret old syntax if needed for content-compat.
glazou: Please add Changes from Previous Version section
fantasai: Ok, I can do that.
<dbaron> I think that (1) if we publish the document, it should have an
editor listed (fantasai, I think) who is an active member of
the working group and (2) it should probably also have a public
editor's draft if it's an active document
glazou: Any objection to publishing?
fantasai: I don't think it should be an active document. Think we just
publish this update, and then ignore the fact that it exists.
RESOLVED: Publish css-print with fantasai as editor, updated changes section.
Conditional Rules CR
--------------------
<dbaron> http://lists.w3.org/Archives/Public/www-archive/2013Feb/0040.html
dbaron: At F2F we had almost all issues resolved, a few left
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0229.html
dbaron: First one was proposal for issue 5, which is behavior of insertRule
dbaron: I looked at what implementations do, not quite consistent.
dbaron: Seem we like WebKit behavior best, so suggest we spec that.
I've already implemented it in Gecko.
dbaron: Question is basically what happens if you pass insertRule an
empty string, or multiple rules, or valid rule with other
garbage afterward.
dbaron: Proposal is they all throw SyntaxError exception b/c not a
valid single rule.
SimonSapin: Don't we have same on stylesheet object?
dbaron: I would expect same rules to apply there.
dbaron: Spec was equally unclear
ACTION: Glenn to update CSSOM to throw SyntaxError on insertRule with
above weirdness as argument
<trackbot> Created ACTION-545
<SimonSapin> should css3-syntax define what is valid?
dbaron: Others, one issue was unclear if had addressed; had been.
<dbaron> http://dev.w3.org/csswg/css3-conditional/doc-20121213-LCWD.txt
dbaron: Others were editorial, plus one resolution that was missing edits.
glazou: Colorized DoC?
glazou: Helps for the conf call with staff
glazou: If you don't have time, don't worry, but if do, that will help
glazou: Any objection to move to CR?
Florian: No, let's go!
RESOLVED: css3-conditional to CR
dbaron: Would like to link to test suite at time we publish CR.
dbaron: Have a bunch of tests, but no built test suite.
plinss: I'll take care of that.
florian: You're referring to tests contributed by Mozilla and by me?
dbaron: Yes, would prefer something that's more than a query in shepherd
to refer to
ACTION: Bert start process for CR for css3-conditional
<trackbot> Created ACTION-546
Counter Styles LC
-----------------
glazou: Tab, counter styles?
TabAtkins: Edited all issues based on F2F discussion
http://dev.w3.org/csswg/css-counter-styles/
TabAkins: Want LC
fantasai: we just added the new feature (for 0-filling), I think we
should publish a WD today or so
fantasai: and then give people a few weeks to review before LC
<glazou> fantasai, TabAtkins, missing Changes from Last Version here too
glazou: No objection to WD?
fantasai: Tab, please update the changes section, and I'll deal with
a quick publication request
RESOLVED: New WD counter-styles, expect LC in 2 weeks or so
Multi-col Percentages
---------------------
SimonSapin: We had proposal on mailing list to add percentages to
column-width or column-gap
SimonSapin: Do implementers want to do this?
SimonSapin: Should we do this in CR?
glazou: Have a use case for this. If you try to show an editing grid in
bg of document, using background is very useful
glazou: Setting columns to percentages will ensure columns map to the
grid.
glazou: If you try Adobe, does this.
fantasai: Why not use column-count?
glazou: I think it's not enough.
TabAtkins: Seems useful
dbaron: I think it'll confuse people into thinking it's the preferred
way to get certain number of columns
dbaron: It's not, because there's gaps, and things won't quite add up.
dbaron: They will get unexpected results.
SimonSapin: I think request was first for column-gap, then column-width
b/c looked easy, but maybe we don't need that.
TabAtkins: Given column-gap: <percent> use case is handled by column-count,
ok with me
dbaron: column-gap is fine with me, as long as we clearly say what it's
relative to
glazou: Ok with me too, as long as we have percent for column-gap..
glazou: Any objection to adding that to spec?
Florian: Which level?
fantasai: Have to go back to LC for other edits anyway
RESOLVED: Add percentages to column-gap, not to column-width (use
column-count for that, it's better)
Font Load Events Host Spec
--------------------------
Topic: Splitting font load events out of fonts spec
jdaggett: Think one issue we can resolve quickly, font load events in
fonts spec
jdaggett: font-load events, important issues about [?]
jdaggett: People leaving various comments ...
jdaggett: Potential for churn on this one portion of the spec, and seems
would make sense to push out to separate spec.
jdaggett: If ppl ok with that, will take out of spec, and put together
something else
jdaggett: Would like resolution on pushing out font load events.
glazou: I can live with that, no problem
<dbaron> fine with me
TabAtkins: I agree
<SteveZ> OK, with removal, would like quick progress on separate document
RESOLVED: Push font load events out to separate spec
Sylvain's Farewell
------------------
glazou: One last thing, let's all wave goodbye to Sylvain!
<smfr> bye sylvaing!
<darktears> sylvaing: good bye!
<dbaron> bye sylvaing, and thanks
glazou: I hope you'll be around for something else, another WG in
consortium...
glazou: If it's the case, see you at TPAC
<tantek> bye sylvaing! hope to see you soon.
<hober> sylvaing: don't go! :)
* SteveZ waving good-bye and welcome
<bradk> bye sylvaing
<sylvaing> bye everyone
* sylvaing and thanks SteveZ
<JohnJansen> boo SteveZ
Meeting closed.
[side discussion of using Presto as an implementation for CR qualification,
partially excerpted below]
<sylvaing> tantek, i think if users can't download it it's not shipping.
if they stop improving it but you can download it then it still
counts though not for much longer since nothing new will happen
there
<SteveZ> The point was that other can replicate tests using the "shipped"
implementation.
Received on Thursday, 21 February 2013 06:03:13 UTC