- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 08 Mar 2012 00:06:27 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
it.
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
http://www.w3.org/Style/CSS/Test/MediaQueries/20120229/reports/implement-report.html
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
smooth...
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?
no
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
visible
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
notice
<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
anywhere
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