- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 09 Jan 2013 19:33:21 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: publish new WDs of css3-transitions and css3-animations
- RESOLVED: the url() function can be escaped, update CSS2.1 errata
and css3-syntax
- RESOLVED: allow background-clip and background-origin to be specified
separately in the background shorthand
- RESOLVED: currentColor still computes to a color when used as a color
property value; clarify css3-color erratum
- Discussed case-sensitivity issue again.
- RESOLVED: If animation name repeated, last instance wins
- RESOLVED: Not adding time units selectors for animations for this level
- RESOLVED: Empty keyframes with positive duration still "animate" and
fire events
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
David Baron
Ryan Betts
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
John Jansen
Brad Kemper
Alexis Menard
Anton Prowse
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
<RRSAgent> logging to http://www.w3.org/2013/01/09-css-irc
Regrets: plinss, danielweck, lea, leif
Scribe: Sylvain Galineau
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jan/0072.html
glazou: extra agenda items?
Publishing
----------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0015.html
topic: publish a new draft of css3-transitions
glazou: I have no objections. Others?
dbaron: sounds fine. Should we update css3-animations as well?
sylvaing: no objections; many updates since the last time.
<darktears> I support the publication. One major change (except the
cleanups) is that transition-duration with a negative
value is invalid in the editor draft but on the TR it is
considered that a negative value is 0s
RESOLVED: publish new WDs of css3-transitions and css3-animations
Escaping of url()
-----------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012May/0329.html
dbaron: it just seems odd that of all the functions in CSS you can't
escape u, r and l in url()
dbaron: it seems we added a test to support its escaping but never
updated the spec
dbaron: I'd support making the errata edit in 2.1
antonp: this has a long history and we agreed a long time ago to make
this change
antonp: for some reason this change was backed out.
florian: did we think the change caused issues?
antonp: no, it was edited in one place but not the other i.e. Appending G
and section 4.4.
<antonp> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17514
(history in bug above)
antonp: this seems just a mistake
antonp: it just needs to be re-edited in both places
glenn: I was wondering why it was backed out
dbaron: it sounds like it was backed out because we had two sections
that were inconsistent with each other
glenn: I was wondering if there was a reason it was backed out vs.
just an editorial inconsistency that fell through
florian: from UA behavior I see no reason not to do it
<SimonSapin> +1 on doing the edit
RESOLVED: the url() function can be escaped, update CSS2.1 errata and
css3-syntax
Flexbox
-------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012OctDec/0265.html
no quorum, deferring topic
CSS3 Backgrounds
----------------
topic: background-clip/origin order in the background shorthand
krit: Firefox follows the spec and assumes the order specified in the spec
krit: should we settle on the interoperable behavior?
dbaron: it seems that separating those values is detrimental to readability
dbaron: if it works to write them separately then there can be arbitrary
other stuff in between
* smfr would like to see some examples
* fantasai thinks what dbaron says makes sense
krit does not agree readability is a priority
glazou: some people find readability very important
krit: I don't disagree. I just don't think this particular issue really
affects readability that much
fantasai: if the two values were independently processed I wouldn't mind
their separation. But given that if one is missing then the
other is copied from it then it makes sense to keep them together
sylvaing: not much incentive for the flexible parser implementations
to do anything. it sounds like we prefer to leave the spec
alone and do nothing?
krit: would the flexible browsers fix their code?
sylvaing: it will be fixed, just not a very high priority
krit: WebKit probably won't change either
dbaron: it sounds like we'd have compat problems if we don't follow so
change the spec
ted: I'd be fine with the spec matching webkit in this case...
sylvaing: same here
+BradK
+Koji
+Rossen
bradk: I don't have an issue with allowing them separate. If authors
think they're more readable together they can still write
them together
RESOLVED: allow background-clip and background-origin to be specified
separately in the background shorthand
CSS3 Color
----------
topic: currentColor on 'color'
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Dec/0286.html
dbaron: we have an erratum to css3-color to make currentColor a computed
value rather than that something that computes to a color as part
of value computation
dbaron: for the color property though, currentColor must match inherit
i.e. it must compute to a color
<fantasai> There was also a proposal on the mailing list to just not
allow currentColor as a value of the 'color' property
dbaron: I think it might be too late for that
glazou: if it is then the change proposed by David makes sense
sylvaing: what's the impact of this change?
<SimonSapin> dbaron’s proposal makes sense, IMO
* antonp prefers disallowing, but if it's too late then so be it.
dbaron: I think it's too late to not allow currentColor in color
dbaron: I propose undoing the change we agreed for color: currentColor
glazou: it's mostly a clarification for a case we never considered
RESOLVED: currentColor still computes to a color when used as a color
property value; clarify css3-color erratum
Case-sensitivity
----------------
* Ms2ger wonders if there's any new information that warrants discussing again
* dbaron notes r12a sent out some new tests a bit over an hour ago
* dbaron hasn't had a chance to look at them
* fantasai neither
fantasai: the key question to me is: can an author working in a language
that isn't ASCII-only pretend that CSS is case-sensitive and
use the same case for his identifiers all over - CSS, JS... -
and have that work?
fantasai: if we normalize things somewhere for matching that requires
them to know details about our case transformation then I
think this is problematic, esp. for ascii-folding
fantasai: Don't want authors to have to know that these letters in my
ident will be lowercased, but others won't
florian: does this issue actually show up?
sylvaing: what do we need to answer the question?
fantasai: for static stylesheets, we know things work. The issue is
around integration with JS APIs
florian: we want to figure out whether all DOM APIs who handle these
identifiers do it in such a way that ASCII case-sensitive is OK
glazou: it also depends on the language; casing transforms won't mess
up French but once you have Vietnamese and its complex diacritics
it could be problematic
* fantasai suspects Vietnamese would be less problematic than German
fantasai: Say I use my own counter style in CSS using mixed cased.
When I check the property value through JS, do I need to
know about CSS casing rules to get a match?
florian: you would not have to know if we provide a DOM API to do this
matching
?: Yeah, but that's still inconvenient
glazou: we need to review richard's tests to make sure they are correct
fantasai: I just want an answer to my question. Are there any JS apis
that will case-normalize CSS keyword values in their output?
<dbaron> the answer is yes
<florian> if the answer to fantasai is yes, or "not currently, but
they may appear", then we probably want full case-insensitivity,
otherwise authors need to know the case normalization rules
to use these APIs, and that's not something we should impose
on authors.
Animations
----------
Scribe: fantasai
<dbaron> dino, did you send email describing what WebKit does re
animations/transitions and cascading?
<dino> dbaron, no :( it's been on my list for a while. I will do
it this week.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20609
sylvaing: dbaron wanted clarification of prose wrt [...] animation
shorthand
sylvaing: currently ambiguous
sylvaing: some prose in animations wrt what it means for multiple animations
in the shorthand animating same property -- in such case,
last one wins
sylvaing: dbaron asked what happens if you have same animation name
repeated in the shorthand
sylvaing: in that case, think we want the last animation name to win
sylvaing: if you animate foo for 1s, foo for 2s, 2s wins
sylvaing: proposal is to run the last one
RESOLVED: If animation name repeated, last instance wins
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20461
sylvaing: This is about allowing keyframe selectors to use time units,
not just percentages
sylvaing: Think that's clearly postponed to next level
glazou: totally agree
glazou: Not sure I want it in next level either
<SimonSapin> next level for sure vs. not in this level
<smfr> agreed
RESOLVED: Not adding time units selectors for this level
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15251
<glazou> http://lists.w3.org/Archives/Public/www-style/2011Dec/0144.html
sylvaing: In December, telecon on 19th we agreed that an empty keyframe
rule, either no rule, or rule results in nothing, does not run.
Specifically, does not fire start/end events.
sylvaing: Since then some on mailing list think, should it really be
about whether has interpolable properties, or should be wrt
whether it has a duration?
sylvaing: Have an animation that starts, ends, does nothing
sylvaing: In the future, if you're using a tool or whatever, might want
to have empty animations.
glazou: I agree with that change
sylvaing: So empty keyframe with positive duration should run?
glazou: Yes, should trigger animation.
sylvaing: I'm ok with that, but change from what we resolved last time.
fantasai: sounds reasonable to me
<dbaron> I'm fine with that.
dino: I'm ok with either way on this
dbaron: Basically saying animations always fire events as long as they
have positive duration
dino: As long as keyframes rule is valid, exists
sylvaing: I'm happy with this, makes more sense to devs
RESOLVED: Empty keyframes with positive duration still "animate" and
fire events
glazou: Reminder to book your hotel in Tucson
Meeting closed.
Received on Thursday, 10 January 2013 03:33:50 UTC