See also: IRC log
<tantek> good morning
<nimbu> Zakim: aaff is me
<katie> rookie moves. :)
<nimbu> :)
<glazou> ScribeNick: antonp
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0117.html
krit: 2 related issues :
transform-origin vs background-position syntax
scribe: should we try to achieve a common syntax, ie use background-position syntax
sylvaing: would the change break
compat?
... don't want to break interop
florianr: keep interop
krit: 1-value or 2-value doesn't really matter
??: would a new conforming implementation force authors to rewrite existing code?
<glazou> s//??/sylvaing
scribe: 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 'z'
... second option: [...]
... 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-postion and trtansform orgin share the same behavior. So why not harmonize the syntax of both
<glazou> 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
... 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
RESOLUTION: no change to syntaxes
florianr: 2 imps pass test suite: Op and Fx
<ChrisL> pointer to imp reports?
florianr: not many changes, jhust
editorial
... let's publish!
ChrisL: excellent!
<oyvind> http://lists.w3.org/Archives/Public/www-style/2012Mar/0083.html
florianr: i've sent an imp report to www-style
<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
... next thing: transition call
<dbaron> ChrisL: But you, the editor, don't need to do that.
RESOLUTION: publish Media Queries as a Proposed Rec
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
dbaron: last time: no transition
when duration and delay are both zero
... Next one: rules for interpolating font-weight
... current ED says font-weight is interpolated as a
number
... it's not quite right since 100 - 900 that are multiples of
1000
... [something about rounding]
... 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: 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?
... there are fonts with a weight of 250
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, algorithm means that the steps are not uniform
... 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 confdent 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
RESOLUTION: round to nearest multiple of 100
dbaron: Next: rules for
transitioning visibility
... spec says it can be interpolated
... but what do we do about 'collapse'
one possibility: not allowed
dbaron: I don't have any other
proposals
... 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
... if we were to do something similar for collapse, we should
look at the pairs of values
dbaron: one way: make
collaps/visible work like hidden'/visisble
... 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?
RESOLUTION: 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
... transition events fire, what should happen when a
transition ends on a pseudo-element?
... one possiblity: fire an event at the element
... another possibility: no event at all
... another: add a field to the transition event saying which
pseudo it's for
... maybe there are more?
glazou: want consistency with
getComputedStyle
... 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
RESOLUTION: 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
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0006.html
<fantasai> http://dev.w3.org/csswg/css3-images/issues-lc-2012
fantasai: issue number 2
... syntax issue
... 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
... 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
... we need to know what grandients generators produce
ChrisL: the issue is browser support
florianr: Op 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
<bradk> http://www.colorzilla.com/gradient-editor/
glazou: it's not that hard
fantasai: should be support both
options?
... 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
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
... why should both syntaxes exists?
??: when are we going to stop tweaking this syntax
scribe: 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
RESOLUTION: 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
... many people away next week for SXSW
<SteveZ> steve sends regrets for next week
glazou: should we have call next
week?
... probably not
... OK. Next week's call is cancelled
... Is there anything needed for Fragment identifiers in
URLs?
sylvaing: there are issues against gradients, and issues against other at risk things. Can we move forward somehow?
(above comment was in relation to a different topic, which i missed)
<hober> thursday at the same time is the html call
fantasai: can we move telecon to Thursday?
sylvaing: how can we get Gradients to CR? When?
fantasai: features in document
are mostly 'element' and 'object-fit'.
... to get Gradients to CR, we should drop 'element'
... 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
...: 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 obejct-fit and object-position then
... 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
glazou: that property stayed on the radar for ever before we moved on
fantasai: bunch of issues in gradients that don't even have proposal
<sylvaing> ChrisL as long as having a new document doesn't create another n weeks of LC period etc
fantasai: one issue on
object-fit, wont' require much discussion
... just 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 imps and reports, you can go from PR to LC
fantasai: can't drop everything without issues
glazou: we must stop the call
now
... resolve on the mailing list
<sylvaing> My bad for taking the call over...
glazou: next week is cancelled!
<fantasai> glazou, dbaron: Next time... please call me if I'm not on the call and I should be!
<fantasai> :(
anything I have to do to end the meeting on here?
<glazou> antonp: now you understand why minuting is hard ? :-)
haha
<glazou> antonp: ask fantasai
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/??/krit/ Succeeded: s/??/sylvaing/ Succeeded: s/??/krit/ WARNING: Bad s/// command: s//??/sylvaing Succeeded: s/param/property, transform-origin-z/ Succeeded: s/[...]/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./ Succeeded: s/??/hober/ Succeeded: s/100/1000/ Succeeded: s/1000/100/ Succeeded: s/??/sylvaing/ Succeeded: s/algo/algorithm/ Succeeded: s/??/sylvaing/ Succeeded: s/??/sylvaing/ Succeeded: s/???/going from collapse to visible/ Succeeded: s/first(??)/to/ Succeeded: s/??/sylvaing/ Succeeded: s/with/without/ Found ScribeNick: antonp Inferring Scribes: antonp WARNING: No "Present: ... " found! Possibly Present: Bert Cathy ChrisL JohnJansen Microsoft Mozilla Ms2ger P18 P39 P65 P7 P74 ScribeNick SimonSapin SteveZ aaaa aabb aadd aaee aaff aagg aahh antonp arronei_ bradk dbaron fantasai florian florianr glazou glenn hober katie kirt kojiish__ kojiishi kojiishi_ krit ksweeney nimbu oyvind proposal smfr sylvaing szilles tantek various You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 07 Mar 2012 Guessing minutes URL: http://www.w3.org/2012/03/07-css-minutes.html People with action items:[End of scribe.perl diagnostic output]