- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 23 Feb 2012 19:50:52 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed how much overlap to have in Hamburg with SVG
- RESOLVED: Publish CSS Variables as First Public Working Draft
- RESOLVED: Publish CSS Speech as Candidate Recommendation
- RESOLVED: Publish CSS Grid Layout as Working Draft
- RESOLVED: Single hg repository for all CSSWG specs (not repo-per-spec)
- RESOLVED: Add Aryeh as editor for CSS Transforms
- RESOLVED: Publish CSS Transforms as First Public Working Draft
- Discussed synchronization of transform-origin and background-position
http://lists.w3.org/Archives/Public/www-style/2012Feb/1135.html
- Discussed intersection behavior of transforms
- ACTION all: review dbaron's list of Transitions issues for next week
http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins (via IRC)
David Baron
Bert Bos
Kimberly Blessing
Tantek Çelik
Arron Eicholz
Katie Ellison (Microsoft)
Elika Etemad
Simon Fraser
Sylvain Galineau
Koji Ishii
Brad Kemper
Håkon Wium Lie
Peter Linss
Divya Manian
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
David Storey
Daniel Weck
Steve Zilles
plus multiple unidentified people, about which fantasai will complain
on the administrivia list :)
<RRSAgent> logging to http://www.w3.org/2012/02/22-css-irc
Scribe: Divya Manian
Administrative
--------------
plinss: anything to add to agenda?
sylvaing: WAIPF asked for extension and we haven't heard back
sylvaing: Would like to publish Grid Layout
dbaron: there are css3-transitions issues worth discussing
* sylvaing very much likes dbaron's list. must do the same for animations
plinss: request from SVG for face to face currently scheduled for
half a day, request for full day.
dbaron: not clear to me what is covered under that, and what is
covered under our own meeting
vhardy: under FX we have transforms, filters, compositing
dbaron: we have an awful lot of stuff we need to cover too
florianr: transforms, I agree, we need to talk about that. Rest of
them, is there anything urgent.
plinss: any other logistical updates for the F2F?
<dbaron> http://wiki.csswg.org/planning/hamburg-2012
vhardy: if people need hotels let us know as soon as possible.
Also want to know if we can release the holds we had on
the hotels.
vhardy: by end of week we would release the hold.
<stearns> one possibility is to meet together for transforms, then
split into two groups for the rest of the day
<stearns> where some CSS people could continue to meet with the FX group
Publishing Specs
----------------
<dbaron> http://dev.w3.org/csswg/css-variables/
plinss: requests to publish specs, Variables FPWD
florianr: worth mentioning as an issue in the draft, naming of these
things is still under debate.
florianr: other than that I am all for it.
plinss: anyone else?
RESOLVED: Publish variables as First Public Working Draft
ACTION Tab ensure variables is published as FPWD, noting an isue about
whether variables should be named data- or var- or
something else.
<trackbot> Created ACTION-447
<danielweck> http://dev.w3.org/csswg/css3-speech/
plinss: speech - danielweck wants to take that to CR
<danielweck> http://wiki.csswg.org/spec/css3-speech
<danielweck> http://dev.w3.org/csswg/css3-speech/
RESOLVED: take CSS Speech to CR
<danielweck> thank you!
* sylvaing likes the smell of CRs in the morning
plinss: any objections to publish another update to Grid Layout?
fantasai: Not from me.
RESOLVED: Publish an updated working draft of the grid specification
http://dev.w3.org/csswg/css3-grid-align/
Switching to Mercurial
----------------------
florianr: I think it would be better to have everything under the same repo
florianr: because we share some files, and because we split and move and
merge specs
<danielweck> +1
<smfr> +1
plinss: agree
<TabAtkins> +1
plinss: would be useful for us to switch en-masse
plinss: so far moving piecemeal
fantasai: glenn is the pioneer in this respect, otherwise it would be
better to co-ordinate if we move all at once.
fantasai: put a black out for 5 or 24 or whatever hours stating no check-ins
during the transition, so we don't lose anything in the process
fantasai: we need to get a couple of things set up on our server and make
sure the documentation is all there.
florianr: we should block check-ins permanently in CVS
fantasai: files should be deleted in cvs
florianr: keep them in read-only mode.
fantasai: the cvs repo will be out of date, files should be deleted and
old dev.w3.org URLs be redirected.
fantasai: if you go back to the revisions you will find them.
dbaron: using cvs remove, not delting repository
<glenn> system team says they're looking into auto checkout but no
schedule yet
fantasai: need to resolve on doing either one per spec or one per file.
plinss: easier if we have one repo rather than n repositories
<glenn> +1
plinss: I just want agreement that we are going to do this.
<smfr> +1
florianr: I am good.
plinss: anyone going to freakout if we are moving from cvs to mercurial
<sylvaing> i'm in favor
[discussion about where to serve files from]
??: the issue seems to be if we can set up a checkout anytime soon,
there is no ETA from the systems team for what that involves
florianr: eventually current urls will redirect or move to new urls
permanently
fantasai: urls on dev.w3.org will stop working, they will redirect
fantasai: We can easily set up a checkout on csswg.org
fantasai: if the systems team sets up a checkout on dvcs, we can
redirect from csswg to there.
<Ms2ger> Note that the auto-checkout works fine for webapps
<Ms2ger> What's wrong with http://dvcs.w3.org/hg/css/raw-file/tip/values/Overview.html, say?
<fantasai> Ms2ger, doesn't serve files over Apache, which means we're
missing configs like DirectoryIndex, Redirect, etc.
tantek: could we ask the sytems team what is necessary to make it work?
it doesn't seem to be an issue for other groups to create repo
and get it served.
plinss: I think somebody asked them and they said they don't know when
they can do it
??: the problem is 3 different published urls for editorial drafts
plinss: we can maintain mirror on csswg definitely, regardless of it
existing elsewhere or not.
tantek: seems like extra admin for csswg.org
plinss: I'm the admin, and I don't mind. I can set up a cron job and
keep it going forever.
florianr: can we have a script hook so it can get updated whenever
any chage gets pushed?
<Ms2ger> That exists for the test repos, fwiw
plinss: if we can get it set up on dvcs server yes.
<glenn> until the new uber-repo is set up, i'll continue using my new
cssom repos, then will merge into the uber-repo
RESOLVED: Have one repository for all our specs
CSS Transforms
--------------
plinss: svg group resolved to publish first WD, we should also resolve
on that
<smfr> http://dev.w3.org/csswg/css3-transforms/
plinss: should be a no brainer.
<Ms2ger> How much will this delay getting 2D Transforms to CR?
plinss: any objections?
fantasai: I object to publishing unless the issues list is linked from
the draft
tantek: I think if we resolve on accepting Aryeh as co-editor we can
accept that action.
dbaron: you can copy the one I put in transitions and animations
plinss: agreement to publish with an update to the issues list?
plinss: anyone object to adding aryeh as editor?
RESOLVED: Add Aryeh as editor
RESOLVED: Publish first WD of transforms with link to issues list.
(any actions?)
<Bert> (As it is listed as a CSS WD, I guess the action is on me to
procure the Director's approval and publish...)
ACTION: ChrisL Publish css3-transforms
<trackbot> Created ACTION-448
<tantek> I'd like to request that the CSS Transforms FPWD also link to
the Editor's draft in addition to the issues list.
<fantasai> tantek, agreed. Should update to the module template overall
<Ms2ger> tantek, fantasai, hasn't that been resolved ages ago?
<tantek> fantasai - updating to the module template overall is potentially
a lot more work
<tantek> (having just done that myself for CSS3-UI)
<fantasai> tantek, grabbing just the header though shouldn't be
<tantek> I would be ok with updating just the header portion (the stuff
that comes before "Abstract") to the module template for FPWD,
and the rest after
<tantek> fantasai - sounds like we are agreed
<tantek> PROPOSAL: Require CSS3 Transforms FPWD header (portion before
"Abstract") update to CSS module template before publication.
vhardy: aryeh sent an issue with a description.
<dbaron> Gecko has a patch implementing the new background-position syntax
<dbaron> (but it keeps transform-origin the same as it was)
smfr: the issue is the transforms spec has two properties transform-origin
and perspective-origin, intention was to match the spec on bg position.
The syntax has changed relatively recently, not many browsers have
implemented it yet.
smfr: transforms has z position. With new bg position, there is ambiguity
between the new syntax. Aryeh suggested a number of possibilities
smfr: 1. should transform-o and perspective-o follow bg-position?
smfr: 2. how do we deal with z-offset issue? have an additional property transform-origin-z
<vhardy> http://lists.w3.org/Archives/Public/www-style/2012Feb/1135.html
smfr: keep z-offset separate to avoid ambiguity
smfr: add a slash syntax to keep z separate from x,y.
smfr: Aryeh has more in the email.
smfr: decide if transform-o matches bg-o. fundamental decision to make.
smfr: I think dbaron you suggested that originally.
dbaron: I wasn't considering 3d case.
dbaron: how useful is the z component of transform-o to begin with
smfr: it is useful in some cases, we have used it in demos and stuff.
smfr: aligning with bg-position adds an additional burden.
smfr: AryehGregor pointed out some of bg-pos can be done with calc.
smfr: or change bg-pos syntax to align with it.
smfr: you think with z as separate property, transform would be a shorthand.
smfr: maybe we should just leave this to the mailing list.
plinss: anyone has any opinions?
fantasai: only concern is if we are not matching bg-pos it would be
confusing to authors
smfr: agree on that point
sylvaing: the author is already using it, why is it confusing
sylvaing: authors are already using transforms
* tantek agrees with sylvaing
smfr: figure out if we should track it or not
dbaron: tracking is basically impossible
sylvaing: yes
smfr: it is unfortunate we have 2 different ways of describing similar
behavior in 2 different properties
plinss: is it too late to change bg-pos behavior
dbaron: I have not been too crazy about new bg-pos syntax but we had an
intern spend a significant time implementing it.
fantasai: it has not changed since 2008. confused by people saying it was
updated recently
smfr: original transform spec was done before that change so we used the
old syntax, I am guessing.
sylvaing: the goal is to unprefix as much interop we have, I am not in
favour of changing syntax at this point
sylvaing: if the goal is consistency, last time we did this was for
gradients and I don't have a good memory of that
<Ms2ger> Hear, hear
smfr: the syntax in the transform spec is compatible with bg-pos syntax
<oyvind> (the background-position thing has been in CR for years, and in
draft before transforms afaik)
dbaron: excluding the z part it's a subset of the syntax.
smfr: were we to move to bg-pos syntax would the content break.
smfr: I would be willing to forgo compat with transform-o that has
z position specified
fantasai: I don't have any feedback on it as I haven't looked at this issue
smfr: I think we should continue this on mailing list
ACTION fantasai review transform-origin
<trackbot> Created ACTION-449
smfr: one of the other issues for 3d transforms is requirement for rendering
intersecting elements
<smfr> http://dev.w3.org/csswg/css3-transforms/
smfr: example 7.
smfr: question is whether we should make intersection behaviour normative
in the spec or not.
smfr: we didn't make it normative is that implementing this is difficult.
dbaron: authors are hitting the lack of interop here and we need to pick
an answer
smfr: yes definitely
plinss: I am presuming we have no interop currently
<TabAtkins> We are definitely opposed to leaving it non-normative.
smfr: I don't know what chrome and firefox's behaviour is.
dbaron: chrome & firefox do it one way and safari another.
<TabAtkins> Yes, no real interop. Chrome has different behavior even
between HW-accelerated and non.
dbaron: I think what people said is that roc would know.
smfr: I would like to hear input from other implementers, whether it's
something they would consider implementing.
smfr: you have planes in 3d space, if you transform planes they intersect
smfr: to get correct rendering you need to subdivide planes along the lines
of intersection
smfr: if you look at the spec, it points to a wikipedia page and tells you
how to resolve rendering ambiguities
smfr: alternative is you don't render intersecting space. and that won't
show the intersection correctly
ACTION dbaron ask roc on how/whether to make intersecting elements normative
<trackbot> Created ACTION-450
<TabAtkins> Chrome is willing to work on good intersecting behavior, both
for rendering and picking. We *definitely* want normative
requirements here.
ACTION florianr ask opera how/whether to make intersecting elements normative
ACTION florian ask opera how/whether to make intersecting elements normative
<trackbot> Created ACTION-451
smfr: webkit has a mode where you can turn off hw accell and thats not a
config that a user should run into.
plinss: I thought I heard chrome and safari have different behaviours here?
<TabAtkins> We do, yes.
<TabAtkins> (I don't know details, but I was talking with our implementors
a few days ago.)
smfr: thats possible, chrome uses openGL backend for rendering, safari uses
CoreAnimation framework for the rendering
plinss: safari is basically doing the intersection.
plinss: if we define this normatively in the spec, would anyone else be able
to implement it?
florianr: we might run into cases where it might be different as we do ports
for wide variety of platforms
plinss: we specify this behaviour but we say 'should' for now.
florianr: the resulting apperance is very different
<TabAtkins> We are willing to implement.
vhardy: that is my concern, if its not consistent it kinda falls apart.
plinss: I am not sure if its worth holding the spec for.
florianr: if it turns out to be too hard, normatively state that we should
not do intersections. lets go check with implementers
dbaron: this is the biggest interop complaint I have heard about transforms.
plinss: we will come back to next week to revisit
plinss: any other issues?
smfr: that's all the transform issues I want to talk about today.
plinss: when we think we can take transforms to last call
florianr: we have to be reasonably sure we have identified the issues
plinss: last call is to get everybody's issues in
tantek: there is simply a requirement, if we know of any issues, we
document and link to them.
tantek: linking issues in the header is sufficient for that
fantasai: are there any significant issues - major ones - that we haven't
resolved for the last call?
tantek: specific item on that is dependencies. speaking with AB they
clarified that
tantek: that requirement is there so groups rely on those dependencies
are notified during the LC
tantek: there could always be new issues someone finds tomorrow
sylvaing: ones that have been identified are major tho.
fantasai: one of the purposes of LC is to review whats going to CR.
If you make major changes between LC and CR, those changes
don't go through review
fantasai: we must be pretty sure we don't make major changes before
we go to LC, otherwise we'll be publishing multiple last calls
tantek: html wg publishes multiple last calls
stearns: you will end up going to last call again
* sylvaing doesn't understand how we go to LC with a missing normative
definition of something known to be a major interop issue
stevez: the belief that you won't have major issues show up in LC is
not reliable either
<fantasai> can we stop talking about process, PLEASE?
<stearns> +1 fantasai
<sylvaing> and we asked to not talk about this today
florianr: tantek I know your intent is to speed up process, but seems
like we keep talking more about process
tantek: if you want to take clarifications to email I am fine with that.
plinss: I am not sure we are ready to take it to LC today.
plinss: I don't like to take this to LC 10 times, I would like to do 1
LC if possible. I don't want to wait to post all of our issues
to do that.
plinss: as long as we have all of the issues identified, I am fine with
going to LC with open issues
* fantasai thinks the *editors* should decide whether they want to do
multiple LCs, not Tantek, since it's the *editors* who are
going to have to do the extra work in drawing up multiple DoCs,
not Tantek.
sylvaing: it is weird to have people review something without having a
resolution on something significant that lacks interop
plinss: only intend to take it to LC soon.
plinss: we will come back to transforms next week, hopefully editors
will have feedback on issues raised this week
<dbaron> fantasai, btw, didn't we agree to add a test suite link to the template too?
<dbaron> fantasai, is it ok if I add that to css-module?
<fantasai> dbaron, don't recall, but sure, go ahead
Image Values
------------
sylvaing: any word on what happens to image values when people who asked
for extensions don't provide feedback
fantasai: we compile list of comments without their comments.
Bert: I have not heard anything, if its too late, they have to go to
director to ask. but they have had their chance I think
plinss: shall we push on then?
Bert: I think so.
plinss: ready to take Image Values to CR?
fantasai: we need to finish disposition of comments and then review it
plinss: when do you think you can have that ready?
fantasai: next week
<TabAtkins> I'm doing the last cleanup for DoC.
<TabAtkins> Yeah, next week I'll be fully finished.
plinss: do we need to formally ping WAIPF that we are moving ahead without them?
Bert: I think a message would be polite
florianr: the message should include the fact that we are not waiting.
Bert: something has to be really quick, there is no more deadline.
ACTION Bert tell WAIPF that they need to give feedback asap for image values
<trackbot> Created ACTION-452
3 minutes left
Transitions
-----------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
fantasai: Maybe we can agree to defer all the issues dbaron suggests to
defer?
fantasai: Basically anything that is hard to define or not defined yet,
we say don't animate.
sylvaing: we are not defining gradient transitions until image values L4
dbaron: the prose was never removed from transitions, I am proposing we
remove it.
florianr: as long as we we allow ourselves to do it later. Don't want
implementing it later to make us non-conforming to this spec
fantasai: Should be able to wordsmith that. Done that kind of thing
before.
sylvaing: yes.
plinss: ask everyone to review david's list and get to it next week.
Meeting closed.
Received on Thursday, 23 February 2012 18:51:28 UTC