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

[CSSWG] Minutes and Resolutions 2012-02-23

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 23 Feb 2012 19:50:52 +0100
Message-ID: <4F468A8C.1070308@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:51 GMT