- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 12 Nov 2009 15:06:07 -0800
- To: www-style@w3.org
Administrative
--------------
- Introductions, scheduling agenda items
- Review our Last Call comments for MathML for CSS
http://www.w3.org/TR/2009/WD-mathml-for-css-20091006/
Bert didn't find much to comment on. Stretchable characters
is something we might need to look at in the future.
jdaggett has some comments on font variations vs Unicode
- Discussed modularization and profiles; the questions raised
are all answered by the Snapshot. The only complaint was that
it's not visible enough, which will be solved when the Snapshot
enters CR.
Transitions, Transformations, and Animations
--------------------------------------------
- Apple would like a few sample tests in an appropriate format
to begin writing test suites. dbaron offered to help with that.
- Reviewed behavior of inherited properties and how inherited
transitions don't trigger new transitions
- Discussed effects of batched layout updates and flushing on
transitions, and the resulting unpredictability in behavior.
- Expecting another WD soon, then LC afterward for Transitions
and possibly for 2D Transformations; 3D Transforms and
Animations both need more work
====== Full minutes below ======
<RRSAgent> logging to http://www.w3.org/2009/11/02-CSS-irc
See also http://krijnhoetmer.nl/irc-logs/css/20091102
Present:
Tab Atkins (Invited Expert)
David Baron (Mozilla)
Bert Bos (W3C Staff)
Tantek Çelik (Invited Expert)
Beth Dakin (Apple)
John Daggett (Mozilla)
Arron Eicholz (Microsoft)
Elika Etemad (Invited Expert)
Simon Fraser (Apple)
Sylvain Galineau (Microsoft)
Daniel Glazman (Disruptive Innovations / co-chair)
Brad Kemper (Invited Expert)
Chris Lilley (W3C Staff)
Peter Linss (HP / co-chair)
Pierre Saslawsky (formerly Netscape / observer)
David Singer (Apple)
Steve Zilles (Adobe)
Scribe: Sylvain
Introductions
-------------
We go around the table and introduce everyone
Peter Linss, HP.
Sylvain Galineau, Microsoft, IE team
Arron Eicholz, Microsoft, IE Team
Beth and Simon, Apple, WebKit
David Baron, Mozilla
<glazou> Pierre Saslawsky
John Daggett, Mozilla Japan, CSS3 Fonts editor
Chris Lilley, W3C
Alex Mogilevsky, Microsoft
Tab Atkins, Invited Expert
Brad Kemper, Invited Expert
fantasai Etemad (fantasai), Invited Expert
Daniel Glazman, csswg co-chair
Bert Bos, W3C
(scribe missed a couple of observers)
Meeting Agenda
--------------
http://wiki.csswg.org/planning/tpac-2009
Discussing timing of various items, adding CSS test suite to agenda
LC comments for Math-ML for CSS profile
---------------------------------------
bert: largely CSS2.1 to render MathML
bert: I didn't find anything I would comment on
http://www.w3.org/TR/2009/WD-mathml-for-css-20091006/
bert: in section 12 (default stylesheet), a general comment says 'it would
be appropriate to extend CSS3 with a few math-specific properties'
glazou: it would be helpful to know what is intended
bert: one approach involves additions to the box model for math layout.
then stretchable characters such as a parenthesis stretching to
the size of the box next to it
dbaron: stretchable characters require knowledge of what's being contained
bert: the stretching character is bound to something; but an additional
issue is that stretching the height of a character may also impacts
its width
bert: these are the general issues that were discussed in the past
jdaggett: notices variant properties under the math variants section and
forecasts comments...
jdaggett: there are Unicode characters for maths outside the BMP
jdaggett: when you use math characters, things like italics may have a
semantic meaning i.e. they're not presentation
<dbaron> Funky Chars
jdaggett: section 3.3: stretchar ?
<smfr> http://www.w3.org/TR/MathML2/chapter6.html#chars.BMP-SMP
<bradk> stretchar is spelled consistently throughout at least.
<ChrisL> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter7.html#chars.BMP-SMP
<ChrisL> 7.5 Mathematical Alphanumeric Symbols
TabAtkins: this section describes both Unicode and alternatives ways to
specify math characters
<ChrisL> "Mathematical Alphanumeric Symbol characters should not be used
for styled text. For example, Mathematical Fraktur A must not be
used to just select a blackletter font for an uppercase A. Doing
this sort of thing would create problems for searching, restyling
(e.g. for accessibility), and many other kinds of processing."
jdaggett will send comments on document tonight
Bert will share the WG's answer with MathML
<ChrisL> also http://www.unicode.org/reports/tr25/tr25-8.html Unicode
Technical Report #25
<ChrisL> Unicode Support for Mathematics
Transitions/Transformations/Animations
--------------------------------------
glazou: there are large expectations from the web design community around
these features
* plh-webapps wonders if Dave Singer woke up this morning
glazou: we'd like to move these specifications along: edit the specs,
test suites...
smfr: we're committed to moving the specs forward, specifically 2D
Transforms and Transitions
smfr: 3D Transforms and Animations will likely take longer
+David Singer (Apple)
smfr: we have tests we need to move to the W3C format
fantasai: we have both stand-alone testcases and reftests
fantasai: if we need another test format for transitions, that's
understandable
dbaron: some of these tests will have to scripted and we should be ok
with that
smfr: some of the functionality needed to test transitions may need
to be specified as well
dsinger: if we had agreement on a template testcase, it would help get
us going
dbaron: I'd be willing to help edit Transitions
dbaron: for the inheritance processing model issue, I think we decided
that if you have 4 elements A, B, C in an ancestor-descendant
relationship
dbaron: and you specify a transition on color in B and C and a dynamic
color property change occurs, what happens to C's transition ?
dbaron: we decided that C's transition does not happen but it doesn't
inherit B's animated values
<ChrisL> its just a case of being clear when the values are grabbed to
compute the transition, and whether they can be changed during
a transition.
dbaron: C's transition would only be triggered when C is updated
dbaron: if C was already in a transition, that would not be affected
smfr: Webkit does not currently handle transitions on inherited properties
and we haven't seen any issues from it
glazou: are web designers going to understand this ?
szilles: this is the most understandable solution yet
<TabAtkins> a { transition: none; color: blue; }
a:hover { color: red; }
b { transition: color 1s; }
<-- If I hover <a>, should <b> transition? Does it currently?
<bradk> A>B
<TabAtkins> b>c { transition: color 2s } <-- Given the previous rules,
now <c> does *not* transition when I hover <a>, but it does
inherit <b>'s colors as <b> transitions.
dbaron: the answer to Tab's first case was that B does transition as the
inherited color value is not animated
smfr: transitioning visibility is an area we have thought of making changes
to create fading effects vs. the current specified behavior where all
non-1 values result in visibility:hidden
pierres: regarding the inheritance discussion, does this mean that the
result will be different depending on the sequence in which I
trigger my transitions through script ?
<TabAtkins> Example: <script> $foo.css("color","red");
$foo.css("transition","color 1s");</script>
<-- Does the color transition? Does it not?
Is this impl-dependent currently?
dbaron: transitions do complicate the model in that dynamic property updates
were effectively simultaneous but now we still have residual effects
from older values
<fantasai> smfr describes a case where the author turns off transitions,
sets an intermediate value, sets transitions back on, and then
sets another value
<fantasai> various browser optimizations may cause that intermediate value
to not be used, in which case the transition transitions from
the wrong start point
TabAtkins: there was talk about grouping transitions together to happen as
an atomic unit i.e. setting a number of transitions together
without any one starting ahead of the others
dbaron: we already batch these things
plinss: the point is that the author can control when the batching start
and stops
dbaron: the problem with such an API is that we will do more frequent flushing
dbaron: the browser has to flush right before the "don't flush here" call
dbaron: as well as at the "flush here" call
dbaron: and if someone calls "don't flush here" in a loop to try to optimize,
it'll cause lots of flushes and actually degrade perf
smfr: I think this issue requires a note in the spec
ACTION smfr Add implementation note in the spec about style update batches
and their effect on transitions
sgalineau: pseudo-elements and transitions ?
smfr: Dean Jackson updated the spec so that they can transition
dbaron: only :before and :after transition.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html
and http://lists.w3.org/Archives/Public/www-style/2009Jul/0050.html
are the messages about the inheritance issue we discussed earlier
ChrisL: are we aiming to move this specification to LC ?
glazou: it depends on the editorial stability of the document
<TabAtkins> a { color: yellow; }
<script>a.color="red"; a.transition="color 1s";
a.color="blue";</script>
<-- So the proposal is just to say "Hey authors, watch out
for this!"?
smfr: the spec has been edited over the w-e
fantasai: you will have less to do during LC if you put out another WD
first with all your changes
Bert: I agree this is a likely path for transitions; I disagree that 2D
transforms is as close to LC
<dbaron> I probably need to send a bunch of comments on the "Animation
of property types" section...
<tantek> greetings everyone
tantek suggests an FAQ to answer 'When do we add a property?
' following a long discussion of this topic around 2D Transforms and all
the other things we are adding to CSS
glazou agrees
ACTION Bert Draft an FAQ on when the CSS WG adds a new property
<TabAtkins> Got a transition issue. Check out
http://www.xanthir.com/etc/transitions.html
First, the transitions trigger on *pageload*, which is weird.
Second, "baz" doesn't start transitioning until after "bar" is
done, when it *should* just inherit "bar"'s color as "bar"
transitions.
<br />
<smfr> TabAtkins, your testcase looks like a webkit bug with transitions
of inherited properties
<smfr> TabAtkins, what does FF do?
<TabAtkins> smfr, Notice also that it transitions on page load from black
to red. That doesn't seem to make sense.
<smfr> sounds like a bug
smfr: transitions: we will publish another WD then aim for LC in early 2010
glazou: 2D transforms; what about the rotated table header scenario esp.
not overlapping preceding content ?
fantasai: this is difficult as the table header borders also need to be
properly rotated
dbaron: there was a long discussion and proposal around this topic in
the past (Beijing)
CSS3 Animations
---------------
smfr: we think animations are useful. There are things you can do with
animations you can't with transitions such as moving objects
through intermediate points
smfr: 3D Tranforms needs more work e.g. detailing the 3D hiearchy of elements
glazou: let's move transitions and 2d transforms forward
dbaron: I think transform-origin is interesting as in 3d the value requires
extra input vs. 2d. (the latter is exactly like background-position)
sylvaing: what about the note at the top of 2d transforms re: transforming
fixed positioned descendants ?
smfr: dave hyatt made this note; we think this is the most desirable behavior
dbaron: we do this as well
smfr: for fixed backgrounds, we have already noted that the transformed
element will act like a porthole. we don't do this yet but will fix it
<smfr> i didn't say we'll fix it :)
* sylvaing oops
* fantasai sylvaing, if you want a break let me know
* fantasai thinks you have been doing a lot of minuting today :)
* sylvaing i like to make up apple claims though
Modularization and how to write a CSS profile
---------------------------------------------
szilles: ideally profiles should refer to RECs. if not, breaking circularity
can be achieved by referring to a snapshot
fantasai: or a module such as CSS3 Multicolumn can refer to CSS2.1 but if
an implementor supports CSS3 Color, the latter's definition of
<color> then applies
szilles: then the profile should state this
fantasai reads from http://www.w3.org/TR/css-beijing/#css3 + the next section
quick discussion of when one can be conformant with no vendor prefix;
answer: one a module reaches CR
szilles: we hope that conformance would be claimed against the snapshot
szilles: if I don't know what a snapshot is, I won't find the information
I need
fantasai: the /TR reference for CSS3 will point to the snapshot
fantasai: Also the css3-roadmap URL will redirect to the snapshot
fantasai: we can update the snapshot as soon as Selectors moves to CR or PR
<szilles> Note, that under current rules, an implementation is still
conforming if it implements features, like CSS3 color, that
are in CR, using the CSS property names rather than having
a vendor prefix
Received on Thursday, 12 November 2009 23:06:58 UTC