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

[CSSWG] Minutes and Resolutions 2008-02-18

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 23 Feb 2009 15:04:50 -0800
Message-ID: <49A32B92.5000304@inkedblade.net>
To: www-style@w3.org

   - Peter Linss will not make it to Tokyo. Chris Lilley will chair
     if Daniel Glazman cannot make it either.

   - Discussed Apple's proposals for Transitions, Animations, and Transforms
     Steve Zilles raised an objection to Transforms because it doesn't include
     transforms that affect layout (i.e. surrounding content recognizes the
     shape of the box after transformation, not the shape before the transform).
     Steve Zilles and David Singer will draft a placeholder note about the

   - Discussed Selectors. Informally agreed to publish Last Call in 2 weeks,
     either incorporating i18n feedback if Unicode Normalization is easily
     resolved for Selectors, or leaving it out to handle as an LC comment if
     i18n is not ready or the issue is determined to require more time to

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


   David Baron
   Bert Bos
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Chris Lilley
   Håkon Wium Lie
   Anne van Kesteren
   David Singer

Tokyo F2F

   Daniel: Peter did not get budget approval
   Daniel: I'm still unsure myself
   Daniel: I will know by the end of the week
   <dsinger> I have a conflict for the f2f, sorry
   Daniel: Chris Lilley will be chair if I cannot make it
   Daniel: anything else?

Apple CSS proposals: Transitions, Animations, Transforms

   Daniel: I saw only Bert's e-mail
   Daniel: please state your opinion
   Chris Lilley was not clear about the transform-style and backface culling.
   where would a back geometry come from?
   Daniel: at this point we are more interested in whether we should publish
           these documents or not
   dbaron: I'm in favor of releasing them
   <dbaron> ... though they may progress at different rates after this point.
   <dsinger> Steve also had a comment
   szilles: I'm clearly not in favor
   szilles: it is in direct conflict with the stuff we discussed earlier
   szilles: it seemed to be that discussion we had in Beijing went in one
            direction and the Apple proposal went in another
   szilles: how transforms affect formatting
   * sylvaing wonders how 3D margins collapse
   * annevk slaps sylvaing
   Bert: there is a small note in the transforms draft about affecting layout
   howcome: what is the concern here?
   szilles: the essence is that the approach outlined in the Apple draft is in
            direct conflict with use cases we outlined earlier
   szilles: we ought to agree on what problem we try to solve before we set out
            a solution
   dsinger: The documents have been out there for a long time in the wild and
            could have been discussed for months so putting the breaks on them
            now is not nice
   Daniel: we have these proposals on the table for a long time
   Daniel: there has been plenty of time for comments
   Daniel: important comments will still have to be answered by the editors
   szilles: the record of the previous discussion predated the publication of
            the Apple documents
   szilles: I'm concerned about 2D Transforms
   szilles: which were recently split out
   dbaron: Steve is talking about transforms that affect layout if my memory
           serves me. That's the harder part. It might be better to get the
           easier part out there first.
   dbaron: I definitely support publication and might support working on
           transforms that affect layout as well.
   howcome: I prefer transforms that do not affect layout
   howcome: can we address your concern with a note?
   szilles: there is a note in there
   szilles: the note would require turning around because the normal default
            would be the one that affects layout (normal flow)
   szilles: if a note is added that this only works for relative positioning
            that might work better
   szilles: not sure if that is acceptable to Apple
   Daniel: lets have a straw poll
   szilles: to simplify your life, I'm happy to raise a Formal Objection...
   dbaron: do we really want transforms to do vertical text? I see them as
   <dsinger> sure, or the 45 degree case
   ChrisL: you could use them for table headings and such, not Japanese
           text layout
   <ChrisL> I think, if it covered layout, it could be used for rotated or
            stacked text - in table headings for example
   Daniel: it seems you ask for a clarification, not something that should
   <dsinger> it sounds like we need a paragraph at the top, stating this
             as an open issue, and it might (?) cause technical changes
   szilles: it's not a clarification, it's a complete switch
   <dsinger> architectural changes
   * annevk notes that Opera is working on an implementation too
   * annevk ... of the Apple proposal
   dsinger: just to get this straight, you are worrying about the
            architectural issue?
   szilles: yes
   howcome: we should just mark it as an issue
   szilles: the issue is what triggers which behavior
   szilles: as specified, putting transforms on makes them not affect layout;
            that's the issue
   howcome: which part of the document is this in?
   szilles: the document does not consider this case
   <dsinger> http://dev.w3.org/csswg/css3-2d-transforms/
   <ChrisL> "Transforms should perhaps be allowed to affect layout. Using
            the position property to do this seems to be the logical choice,
            but there are lots of questions about how this would work."
   dsinger: maybe we should change that paragraph to make it clear this is
            an architectural issue
   szilles: I think I can have a paragraph for next week's meeting

   howcome: why should we allow transforms to affect layout?
   szilles: to rotate text
   * annevk wonders if the only use cases is text?
   dbaron: it is pretty complicated
   szilles: you don't want writing-mode to also deal with rotated text
   szilles: if you overload writing-mode it gets really complicated
   <dsinger> "Resolving this issue might result in architectural changes to
              the rest of this document; this is not (merely) a missing
              technical detail." ??
   <ChrisL> q+ to say actually its not clear that this would you 45 degree
            stacked table headers
   Daniel: what can we do to make it publishable?
   Daniel: removing the section?
   szilles: no
   dsinger: would the sentence above work?
   szilles: no... I guess I would sort of point to the use case document
            on www-style ...
   <dsinger> uri coming?
   <szilles> Use cases for transformation:
   szilles: my request is that people look at the use cases
   szilles: I cannot attend next week's meeting unfortunately
   Daniel: the use cases are clear
   howcome: should the use cases be in the spec?
   [discussion about the use cases]
   * Bert is aware that the most important case is also the most difficult one:
          the diagonal table headers :-(
   * glazou yes Bert
   * annevk notes 3 parties are implementing "simple" transforms

   Daniel: we have two choices now: work this out or drop it
   Daniel: we still have 3d transforms, animations and transitions
   <sylvaing> can we publish the properties implemented by Apple, Mozilla
              and Safari and allay SZ's objection ?
   szilles: I do not understand your two choices; we could discuss it at
            the F2F
   dsinger: I cannot be at the F2F
   dbaron: it has been discussed a lot on the mailing list too; I do not
           think everything needs to be decided during F2F meetings
   Chris Lilley it is a modal thing, you do not have to have both
   <dsinger> and both cases are worth pursuing
   * dbaron thinks the diagonal table headers case should be solved with its
            own property rather than as a special case of a general property
   dsinger: SZ and I can work out a paragraph
   dsinger: to address this issue

   Daniel: objections from BB to animations and 3d transforms
   Anne: In favor of publishing
   * Bert thinks dbaron may be right: it's both simpler (only rotation,
          no other transforms) and more complex (non-rectangular boxes
          and borders).
   Daniel: In favor of publishing everything
   Daniel: it seems there is consensus for these documents except that
           Steve and dsinger need to work out a paragraph
   szilles: the animation stuff does not seem to fit with SMIL
   Daniel: again it's only a WD
   Daniel: it's probably going to be changed drastically based on comments
   szilles: ok
   Daniel: Bert can you summarize your comments?
   Bert: transitions I like after we've done more important stuff
   Bert: 2d transforms is fine as well, again no priority
   Bert: 3d transforms is outside my world, I don't want to think about
         that at all
   Bert: animations seems really way too complex
   Bert: this WD with this syntax is not worth publishing
   Bert: I agree with Steve that 2D transforms that affect layout are better
   dsinger: we did settle on the new charter, right?
   Several: yes
   <ChrisL> charter http://www.w3.org/Style/2008/css-charter.html linked
            from http://www.w3.org/Member/Mail/
   Daniel: most people agree with publishing the new documents; 2 comments
           on 2D Transforms; and Bert is not in favor of publishing one document
   Daniel: dsinger and Steve work out the issue and we're going to publish
           these four documents as soon as possible
   <dbaron> (Note that when I said I think they'll progress at different
            rates... my guess would be fastest-to-slowest as 2D transforms,
            transitions, animations, 3D transforms)
   * ChrisL demoes transforms at a conference around 10 years ago ....
   Daniel: at a conference people were really happy with transforms by the way
   * Bert : new charter now linked. Sorry for not noticing that earlier.


   fantasai: I would like to discuss Selectors
   <dbaron> The hypertext CG seems like the wrong place to discuss that.
   Daniel: We discussed this during the HCG and the Unicode Normalization
           issue needs to be resolved first.
   Daniel: The i18n WG will come up with something in two weeks time
   <ChrisL> a coordination issue between two wgs seems a reasonable thing
            for a coordination group to discuss
   fantasai: I do not want to wait for the i18n WG, XML WG, etc.
   fantasai: I do not want to wait three months to publishLast Call
   dbaron: I would probably raise a Formal Objection to any change to the
           Selectors document that involves Unicode Normalization
   dbaron: on the grounds that it is way too complicated
   <dbaron> to any solution to the unicode normalization issue that involves
            a change to the selectors document
   Daniel: We raised an architectural issue to the HCG and TAG and asked
           the experts what they think about this.
   Daniel: They do their best to reply in a reasonable time
   <ChrisL> they said two weeks
   dbaron: I think that having the discussion on a private HCG mailing list
           is the wrong place to do this
   Daniel: That's a separate issue and we cannot discuss that here
   szilles: I'm confused. I think two separate discussions are going on.
   szilles: 1) Do we need to do something about Unicode Normalization in CSS?
            I think the general feeling is "yes". 2) Can we figure out the
            Selectors issue without figuring out what to do with CSS as a whole?
   szilles: I'm not sure what the i18n WG is tasked to do
   szilles: I agree with DB that a solution that just affects Selectors is
            not the right answer to the broader question
   szilles: In Tokyo we might be able to reach a resolution.
   fantasai: I think this involves a lot of WGs
   dbaron: This involves ECMA TC39, HTML WG, and maybe the XML Core WG
   dbaron: I think what should be up for discussion is a different stage in
           the processing model
   szilles: I agree with DB
   szilles: When does Unicode Normalization gets done
   dsinger: 1) Can you do simple comparison because normalization has been
            done. 2) Does the comparison need to be more complicated?
   szilles: This blocks because at LC you are supposed to be rid of issues
   Daniel: I'm fine with waiting because somebody is dealing with this
   ChrisL: Either you discuss the proposed solution. If it doesn't come,
           you can move ahead anyway and not address it.
   [that might not be entirely accurate, sorry]
   szilles: One technique we used where we can't agree is to move the solution
            to Selectors N+1 and say in Selectors N that is not defined in
            the specification.
   szilles: I propose that as a fallback in case we cannot reach a solution
            in two weeks
   Daniel: I do not want to release the document now and modify it based on
           feedback from the i18n WG later.
   fantasai: I can wait two weeks, but not five months; we have dependencies
             [e.g. Selectors API, XBL 2.0, ...]
   <fantasai> We need to update the draft
   dbaron: I think we should still go to LC
   dbaron: in two weeks
Received on Monday, 23 February 2009 23:05:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:24 UTC