Re: [CSSWG] Minutes and Resolutions 2009-02-18

Make that *2009*-02-018

fantasai wrote:
> Summary:
> 
>   - 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
>     issue.
> 
>   - 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
>     resolve.
> 
> ====== Full minutes below ======
> 
> Attendees:
> 
>   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?
>   [silence]
> 
> 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
>           orthogonal
>   <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
>           block
>   <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:
>             http://lists.w3.org/Archives/Public/www-style/2007Oct/0209
>   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.
> 
> Selectors
> ---------
> 
>   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
>   [agreement]
> 
>

Received on Monday, 23 February 2009 23:09:37 UTC