- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 23 Feb 2009 15:04:50 -0800
- To: www-style@w3.org
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:05:31 UTC