W3C home > Mailing lists > Public > www-style@w3.org > January 2013

[CSSWG] Minutes Telecon 2013-01-09

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 09 Jan 2013 19:33:21 -0800
Message-ID: <50EE3681.9000900@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT