W3C home > Mailing lists > Public > www-style@w3.org > March 2012

[CSSWG] Minutes and Resolutions Telecon 2012-03-08

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 08 Mar 2012 00:06:27 -0800
Message-ID: <4F586883.6010200@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - RESOLVED: no change to background-position or transform-origin syntaxes
   - RESOLVED: publish Media Queries as a Proposed Rec
   - RESOLVED: round font-weight to nearest multiple of 100 when animating
   - RESOLVED: visibility transition between hidden/visible and collapse/visible
               treated as visible; between hidden/collapse treated as hidden
   - RESOLVED: add a field to the transition event saying which pseudo-element
               it's for (if any)
   - RESOLVED: keep the 'to' syntax for linear-gradient(), and only that
               syntax, because this has been tweaked too much. It's a
               reasonable compromise and changing it is not OK any more.

====== Full minutes below ======

   Glenn Adams
   David Baron
   Bert Bos
   Tantek Çelik (partial, via IRC)
   Arron Eicholz
   Katie Ellison
   Elika Etemad (late)
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   John Jansen
   Brad Kemper
   Chris Lilley
   Divya Manian
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Dirk Schulze
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/03/07-css-irc
* tantek is in SFO awaiting a sequence of flights to SXSW.
Scribe: Anton

CSS3 Transforms

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0117.html
   krit: 2 related issues: transform-origin vs background-position syntax
   krit: should we try to achieve a common syntax, ie use background-position syntax
   sylvaing: would the change break compat?
   sylvaing: don't want to break interop
   florianr: keep interop
   * Bert thinks the easiest solution is to remove 'transform-origin' from
          the spec. :-)
   krit: 1-value or 2-value doesn't really matter
   sylvaing: would a new conforming implementation force authors to rewrite
             existing code?
   sylvaing: don't want to revisit gradiants debacle
   smfr: don't know if there would be breakage; but it's unlikely
   dbaron: not clear how the change would work
   smfr: first option: use a new property, transform-origin-z
   * ChrisL everything can be solved by forever tweaking the syntax
   smfr: second option: [...]
   smfr: alternately, separate 2-d part from 3-d part by a slash
   florianr: if we have support for calc(), whatever works right now could
             continue working, and we open new possiblities
   <sylvaing> My ask is that existing content works unchanged since authors
              have already 'future-proofed' their code with unprefixed
              transform-origin. As long as that's preserved to the largest
              possible extent, I'm good
   <krit> background-position and transform-orgin share the same behavior.
          So why not harmonize the syntax of both
   florian: my position is the same as sylvaing's
   various: whatever we do, existing content should not break
   <sylvaing> krit: why not would be if the change broke content. given
              that we aim to standardize what is already interoperable it
              would be undesirable.
   smfr: some but not very much
   <krit> is there content that uses transform-origin for translationg on z-axis
   smfr: some but not very much
   kirt: no conclusion on www-style
   krit: smfr, would change break content?
   smfr: I'm not sure. I'd have to see
   florianr: What I hear you saying is that changing would not break anything
             on 2d, and may break 3d, but there is not much content relying on
   dbaron: no concrete proposal; can't check if things break, without a proposal
   sylvaing: don't want to break 2d, but some 3d breakage might be acceptable
   dbaron: 1 option is to say not bother with concrete proposal, just keep
           things as they are
   ChrisL: what's the disadvantage from keeping things as is?
   dbaron: it doesn't work like background-position
   Bert: problem is that it's different but similar; confusing
   ChrisL: we're not designing from scratch, so we can live with it
   <dbaron> I'm also inclined to just leave it as it is (i.e., matching CSS2
            background-position but not css3-background background-position)
   1st value means translation on horizontal axis, 2nd value is vert translation,
   3rd value is z
   <ChrisL> I am not hearing a really high value to changing from the current syntax
   krit: calc isn't yet implemented everywhere; it could solve problem in future
   hober: if we keep transform-origin as is, could we change background-position
   krit: no way to change background-position; it's already in use
   florianr: it's too late for this discussion
   florianr: could live with a change if it doesn't break 2d, but neutral about it
   <ChrisL> +1 to not changing
   glazou: people are saying it's not worth the hassle of changing
   sylvaing?: there's already content using the current stuff, no-one is
              complaining. not a problem in real world
   ChrisL: let's drop change and move on
   glazou: no objections
   RESOLVED: no change to syntaxes

Media Queries

   florianr: 2 implementations pass test suite: Opera and Firefox
   <ChrisL> pointer to impl reports?
   florianr: not many changes, just editorial. Let's publish!
   ChrisL: excellent!
   florianr: I've sent an impl report to www-style
   <oyvind> http://lists.w3.org/Archives/Public/www-style/2012Mar/0083.html
   <dbaron> changes list is http://dev.w3.org/csswg/css3-mediaqueries/#changes-2010
   florianr: do I have to do anything as an editor?  Or does Bert do it
   <dbaron> implementation reports at
   ChrisL: transition call to Director... point to test results
   * glazou loves GREEN :-)
   ChrisL: next thing: transition call
   ChrisL: But you, the editor, don't need to do that.
   RESOLVED: publish Media Queries as a Proposed Rec

Transitions Issues

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
   dbaron: last time: no transition when duration and delay are both zero
   dbaron: Next one: rules for interpolating font-weight
   dbaron: current ED says font-weight is interpolated as a number
   dbaron: it's not quite right since 100 - 900 that are multiples of 100
   dbaron: [something about rounding]
   dbaron: it's an ordered series of keywords.  In Gecko, implemented
           interpolation of font-stretch
   sylvaing: ordered sequence of keywords that could be animated
   dbaron: Question is: who implements what?  Gecko implementes interpolation
           as mentioned above.  What do others do
   florianr: I don't know what we do, but I don't have anything against it
   <bradk> How about font-size keywords?
   smfr: webkit does not interpolate font-weight
   dbaron: I think you /do/ interpolate font-weight
   ChrisL: unclear whether font-weight varies continuously, or is it just
           keywords that happen to be numeric
   florianr: but they are ordered
   ChrisL: makes sense to interpolate and snap to nearest 100
   szilles: defined in font match algorithm?
   szilles: there are fonts with a weight of 250
   <Bert> q+ to say that the font algo may make the transition less than
   dbaron: that doesn't match to CSS tho
   ChrisL: what OpenType abnd CSS do are related but not identical
   szilles: we should use the same mapping here
   Bert: even though they are ordered, font matching algorithm means that
         the steps are not uniform
   Bert: not sure we want to animate font-weight
   szilles: gonna have strange effects in any case, since few fonts have a
            continuous range
   glazou: authors will check transitions anyway; if they like it, they'll
           do it
   szilles: costs effort to implement.  Is there any use in this?
   Bert: authors won't see problems, because their fonts are not the same
         as other peoples'
   ChrisL: nowadays, people provide fonts with the pages, and better ways
           of specifying weights, so authors will feel more confident to
           use this
   sylvaing: it's definitely possible to author with this; there are examples
   [missed stuff]
   expression of worries about equivalence with font matching algorithm
   florianr: start with 100, then you go match things
   szilles: ah, you're saying that the animation is continuous but it
            switches when it crosses the rounding point
   sylvaing: really, we're animating through a bunch of keywords
   objections to : round to nearest multiple of 100?
   RESOLVED: round font-weight to nearest multiple of 100 when animating

   dbaron: Next: rules for transitioning visibility
   dbaron: spec says it can be interpolated
   dbaron: but what do we do about 'collapse'
   one possibility: not allowed
   dbaron: I don't have any other proposals
   dbaron: what's in Gecko probably isn't what's wanted
   smfr: rules were set up so that we could make something appear and
         change its appearance in the same transition
   smfr: if we were to do something similar for collapse, we should look
         at the pairs of values
   dbaron: one way: make collapse/visible work like hidden/visible
   dbaron: but say that collapse/hidden doesn't interpolate
   smfr: webkit doesn't implement hidden-to-collapse
   dbaron: table-row: at some point you'd switch at some point (indeed
           like all these rules)
   <sylvaing> not sure I understand what happens when going from collapse
              to visible
   dbaron: summary: proposal right now is: interpolating between hidden/visible
           or collapse/visible then all of the intermediate points act as
   glazou: the transition is immediate?
   dbaron: the transition is immediate at some point, the question is
           whether it happens at the beginning or the end
   sylvaing: what's the use case for going from collapse to visible
   dbaron: new option: collapse/hidden transition behaves as hidden, rather
           than interpolate.  I don't really care, and doubt anyone will
   <Bert> (I like david's proposal.)
   <smfr> no
   glazou: any objection?
   RESOLVED: accept david's proposal:
   <bradk> 'collapse' and 'hidden' appear to have identical results in webkit.
   <dbaron> collapse/hidden isn't interpolable; visible/hidden and
            visible/collapse interpolate so the intermediate states are
            all visible

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0311.html
   dbaron: last issue: pseudo-elements
   dbaron: transition events fire, what should happen when a transition
           ends on a pseudo-element?
   dbaron: one possiblity: fire an event at the element
   dbaron: another possibility: no event at all
   dbaron: another: add a field to the transition event saying which pseudo
           it's for
   dbaron: maybe there are more?
   glazou: want consistency with getComputedStyle
   glazou: first element is the event, second is the pseudo
   dbaron: compat issues?  maybe not many people use pseudos
   florianr: the new field doesn't bother anyone not looking at them
   glazou: few people are transitioning on pseudos
   dbaron: gecko doesn't fire the events
   glazou: safe change then?
   dbaron: people happy with adding a field to the event saying which pseudo
           it's for
   florianr: provided no evidence that it breaks something
   RESOLVED: add a field to the event saying which pseudo-element it's for

   glazou: four issues remaining in dbaron's list, but need wider discussion
   dbaron: let's not discuss now, more productive for editors to figure out
           how to get proposals for them first

css3-images issues needing WG review

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0006.html
   <fantasai> http://dev.w3.org/csswg/css3-images/issues-lc-2012
   * sylvaing wonders if we can go CR with known issues against at-risk features?
   * sylvaing we seem to have no issues against gradients which is the one
              we want to standardize...
   * Bert to sylvain: CR requires an *answer* to all open issue. But, the
          answer may be that the behavior is undefined...

   fantasai: issue number 2
   fantasai: syntax issue
   fantasai: 2 options: keep syntax, give consideration to the mailing list
             comment, reply with rationale
   fantasai: other option is to revert to old syntax
   florianr: we've changed gradients too much
   florianr: can't tell if a revert makes things less changed or more changed!!
   sylvaing: I don't want to change anything again about gradients
   glazou: seems we don't want to change
   fantasai: should evaluate what gradient generators are outputting
   glazou: it won't change our decision
   fantasai: it makes a difference on the compat issue
   florianr: i don't want to reopen the topic but i agree
   florianr: we need to know what grandients generators produce
   ChrisL: the issue is browser support
   florianr: Opera and Moz support both syntaxes
   glazou: it's not a large issue; online generators have updated their code
           various times in past, they'll do it again cos it's a cool feature
   glazou: it's not that hard
   <bradk> http://www.colorzilla.com/gradient-editor/
   fantasai: another option is to support both options
   fantasai: that's what Moz is doing
   florianr: Opera does the same
   szilles: given that we aren't running unprefixed, i don't see the need
            to support both options
   florianr: authors are already using unprefixed, but it doesn't kick in
   szilles: how can they use unprefixed if syntax is unknown
   * smfr doesn't see prepositions in output for -moz- in any of the gradient
           generators that google finds
   florianr: you know what the answer is ;-)
   szilles: they're breaking the system
   Bert: if they use it, it's their risk not ours
   florianr: i'm not interested in dropping support for the 'to' syntax
   florianr: why should both syntaxes exists?
   sylvaing: when are we going to stop tweaking this syntax
   sylvaing:  stop this madness! we don't need to keep changing this
   Bert: people out there don't think it's good enough
   sylvaing: got to stop sometime and let it be
   proposal: keep the 'to' syntax, and only that syntax, because this has
             been tweaked too much. It's a reasonable compromise and
             changing it is not OK any more
   <SteveZ> +1 for Florian's statement
   RESOLVED: keep the 'to' syntax, and only that syntax, because this has
             been tweaked too much. It's a reasonable compromise and
             changing it is not OK any more
   glazou: 3 mins left, let's keep remaining issues for next time

   glazou: many people away next week for SXSW
   * dbaron will probably not be able to attend next week
   * nimbu neither.
   * fantasai can be on the call next week
   <SteveZ> steve sends regrets for next week
   glazou: should we have call next week? ... probably not
   glazou: OK. Next week's call is cancelled
   glazou: Is there anything needed for Fragment identifiers in URLs?
   (above comment was in relation to a different topic, which i missed)

   sylvaing: there are issues against gradients, and issues against other
              at risk things.  Can we move forward somehow?
   sylvaing: how can we get Gradients to CR?  When?
   fantasai: features in document are mostly 'element' and 'object-fit'.
   fantasai: to get Gradients to CR, we should drop 'element'
   fantasai: need lots of reviewers to review the recent changes and
             current discussions
   sylvaing: if we want it to get to CR in the next week or 2, move
             'element' to CR
   fantasai: it's currently at risk anyway
   glazou: should we move element to level 4?
   dbaron: I'd prefer not to
   Bert: what's the use case for 'element'?
   <smfr> none in webkit
   sylvaing: do we have use cases
   sylvaing: if we don't have 2 implementations...
   glazou: do others plan to implement this?
   ??: not in coming weeks
   florianr: it's a nice feature but not high priority
   smfr: same for webkit
   glazou: seems that it won't be implemented level 3
   sylvaing: so we only have 1 implementation
   dbaron: but various other things only have 1 implementation
   fantasai: yes, but they don't have issues
   sylvaing: do we hold up gradients for this?
   glazou: it'll be harder and harder to move on if we get held up on this
   szilles: why is it important to get 'element' in level 3 and not 4?
   dbaron: consensus on this concept, been around for a while.  I don't
           want the group to only ship features that there are already
           dependencies on
   glazou: web authors are using it a lot, that's the essential reason
   sylvaing: well, a year ago but that was before big changes
   glazou: we discussed extracting things from specs to increase REC
           speed, but now we're doing the opposite
   dbaron: I think we should also drop object-fit and object-position then
   dbaron: we shoould drop everything with issues
   <smfr> we should just have css3-gradients
   florianr: if it takes more than 1 telecon to resolve, then drop it?
   szilles: what's the likelihood of implementations? Judging this on
            issues is not the right way
   smfr: split out spec
   glazou: don't want to enter border-radius hell. We need to move fast
   <ChrisL> +1 to css3-gradients spec
   <sylvaing> ChrisL as long as having a new document doesn't create
              another n weeks of LC period etc
   glazou: that property stayed on the radar for ever before we moved on
   fantasai: bunch of issues for element() don't even have a proposal
   fantasai: one issue on object-fit, shouldn't require much discussion
   fantasai: and check with smfr about whether the wording is good for
             EXIF data
   <sylvaing> i.e. ok with a rename. I don't want to go through another
              month of process if we can just as easily move things to
              level 4 and publish what we have
   <dbaron> I agree we should just have css3-gradients.
   fantasai: just need WG to review
   glazou: proposal: just have css3-gradients
   fantasai: don't want to drop /everything/ that has issues
   dbaron: will have to drop them anyway to enter PR
   glazou: I want PR asap
   florianr: move ?? out and leave the rest
   sylvaing: don't want new LC period
   fantasai: that proposal doesn't save anybody any time
   <Bert> (People have been asking for images slices for longer than they
           have been asking for gradients...)
   <glenn> notes we are out of time...
   szilles: if you've got the impls and reports, you can go from PR to LC
   fantasai: can't drop everything without issues
   glazou: we must stop the call now
   glazou: resolve on the mailing list
   <sylvaing> My bad for taking the call over...

glazou: next week is cancelled!

<fantasai> glazou: Would it be possible to replace the cancelled telecon
            with 3 resolutions by email?
<Bert> Yes, resolution by e-mail is possible. It's the chairs' responsibility
        to declare consensus.
<Bert> Whether they feel comfortable declaring consensus after just a few
        days of e-mail is another matter...
<fantasai> glazou: Dropping element(), approving issue 24 edits and/or
            dropping object-fit/position (btw, SVG wants those to map their
            preserveAspectRatio attribute), and go to CR.
<fantasai> glazou: I can summarize those for the mailing list.
<glazou> cool
<glazou> do it
<fantasai> Bert: probably a week would be enough?
<fantasai> Bert: esp. if we replace the ocnf call announcement with a
            "You must spend the next hour reading and deciding on this" :)
<glazou> fantasai: ok for email resolutions
<glazou> I'll monitor that
<fantasai> Ok
<Bert> As long as enough people chime in...
<glazou> sure
<fantasai> Bert: yes, let's get explicit yay/nay responses
<glazou> we still need a minimal quorum
<Bert> Especially those who are travelling, because otherwise we don't
        know if they even read the question.
<fantasai> glazou: will send you email
<glazou> ok
Received on Thursday, 8 March 2012 08:07:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:13 UTC