SV_MEETING_TITLE -- 10 Mar 2010

<glazou> plinss: arrrgl

<glazou> my phne does not work !!!!

<plinss> nice

<plinss> device problem or line problem?

<glazou> don't know yet

<glazou> give me a few seconds

<sylvaing> hadopi strikes again

<plinss> sure

<glazou> aaaah better

<glazou> ok TabAtkins

<glazou> no worries

<smfr> i might get called away too (construction people at the house)

<glazou> ahlala :)

<lstorset> same here

<scribe> ScribeNick: fantasai

Daniel: Extra agenda items?

Peter: If you're planning to come to F2F, please remember to fill out questionnaire so dsinger has an accurate count

<plinss> http://www.w3.org/2002/09/wbs/32061/css-wg-cupertino-2010/

Daniel: jdaggett was unable to make call, and so we will defer fonts discussion to next week

<glazou> http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html

Media Queries feature for widgets

Daniel: Used to detect view mode of widget: minimized, maximized, fullscreen, etc.

Chris: This should not be restricted to widgets, there are plenty of other cases you'd want this info

Daniel: That is my comment also. I think all these mode could apply generally
... Should live outside of widgets

dbaron: The all value doesn't seem especially useful, since it's always true

?: Like @media all

dbaron: Might as well not query on feature

<ChrisL> maybe all means "I don't know"

dbaron: Some of these have intersections
... e.g. I can see both fullscreen and application being true
... and fullscreen and not-application being true
... So it seems like there are two different axes here

<ChrisL> application+maximized, application+mini are sensible combinations

Daniel: yeah, application doesn't seem to be a view mode

discussion of various combinations

Chris: There's no value for a normal window, that's not fullscreen

Bert: I thought that was what 'application' meant

dbaron: Seems some of these definitions could be a little clearer

Brad: If they changed application to windowed, it would make more sense to me

Chris: They might be saying something about the presence of chrome

Bert: Not sure you can always tell the difference between application and floating
... Application may have chrome added itself, or chrome added by WM

smfr: Another difference is that for floating, the viewport background is transparent

Brad: Are Opera's widgets floating, then?

smfr: Haven't seen those, but dashboard on Mac is like that

?: THey're not transparent, but other criteria seem to fit

<lstorset> ? is lstorset

<ChrisL> floating seems to apply to things like the classic round clock widget

<sylvaing> how much chrome is chrome ?

<smfr> someone is on speakerphone

<lstorset> sorry that was me

Daniel: Ok, that's all about comments on values?

Steve: Looking at this thing, it seems to be a weird combination of CSS features
... Background seems it ought to come from content -- it's transparent or it isn't

<oyvind> opera widgets do have transparent backgrounds I think

Steve: in a CSS window it's normally transparent
... I find it hard to figure out besides maximize and mini what the other things are trying to say

<ChrisL> from their definitions, "The chrome comprises the visible parts of the user agent that do not depend on the content (e.g. tool bars, title bars, menus). " which seems to disallw pseudo-chrome drawn by the content itself (its own menus etc)

Steve: And wondering why these aren't CSS properties
... This discussion seems very similar to the one we were having on fit

smfr: These are media /queries/. You're not describing what the content looks like
... you're querying the environment

Sylvain: You can write media queries based on viewport space you have, but this is a little highger level

Daniel: You can write media queries to check size of viewport, but not that the size of viewport matches size of screen

howcome?: Do people want to query whether the window is visible?

Sylvain: You get into is my window visible, do I have focus, etc.
... I kinda like it, but it's not exactly querying the media

Daniel: We already discussed adding values that are more system-based to Media queries

Sylvain: I can see the value, but is it something solely through CSS?
... I can see you wnting to access this event-based

fantasai points out that Media Queries isn't a *CSS* spec per se, and it's used in HTMl5 and DOM apis etc too

Steve: The other thing I was hearing was the possible lack of orthogonality
... Of the distinctions between minimized and fullscreen vs. whether chrome is present or not

smfr: Another question -- are these orthogonal to the media type?
... E.g. if I'm in projection mode, do I assume i'm fullscreen?
... Is it possible to be floating but also have a media type of projection?
... I think the spec needs to say something about how those two interact

Daniel: I think projection could imply fullscreen, based on the definitions in CSS

Sylvain: Opera uses projection mode when fullscreened

Daniel: maximize also make sense, mini makes sense...
... The only one that doesn't make much sense in a browser woudl be floating

Chris: Unless you're a widget in Opera

Daniel: but then your'e a widget

Chris: THe browser is running, but instead of producing a normal window it's showing a widget

Bert: Web pages on the desktop don't have a background either

?: would be fullscreen

Bert: Not necessarily

Steve: Might make sense for someone from the widgets group to join our call

Chris: We're painting ourselves in a corner here, we're saying they're general and should be applied everywher,e then saying they're not quite general...

Steve: maybe the answer is to work with them to come upw ith values that are general enough to use in the general case but still answer their needs

Daniel: I will make a response to WepApps group summarizing what we just said.
... Any other comments?

<scribe> ACTION: Daniel Respond to WAF [recorded in http://www.w3.org/2010/03/10-CSS-minutes.html#action01]

<trackbot> Created ACTION-207 - Respond to WAF [on Daniel Glazman - due 2010-03-17].

Steve: one other comment -- there's a possible feedback group
... To the extent CSS can control what the OS thinks it's doing.. could get a feedback loop

Chris: The value is not maintained live

dbaron: It is maintained live

Daniel: If you query the background, and set it in CSS

fantasai: I think if you are querying the background, you would be checking the background of the canvas itself, not the background assigned to be painted (or not painted) on the canvas

<oyvind> "To avoid circular dependencies, it is never necessary to apply the style sheet in order to evaluate expressions" --MQ

Steve: Need to define interaction of CSS settings and the queries

Daniel: Next item

vendor prefixes

<glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0235.html

Daniel: I did not follow the whole thread on that
... I think the way we handle vendor prefixes in CSS is too monolithic
... We only remove them when one complete spec moves to CR

<ChrisL> rounded corners!!

Daniel: While some properties could remove prefix long before that
... I think it should be decision of the group

Bert: I don't think we should not create an extra process in addition to what's provided by W3C

Daniel: We have many examples of live properties shipped in browsers that web authors must manipulate in four or five flavors
... What we did with border-radius, border-radius was at least partially interoperable in most browsers but people had to use five variants

<ChrisL> we have combinations of ultra-stable and rapidly changing properties in the same spec. We don't want to split into smaller and smaller specs all the time

Daniel: When the group decides that a property is stable and interoperable enough, then the prefix can be removed

Bert: Then you need another WD

smfr: That would be an annotation in the existing draft

Daniel: Or have a prefix for the WG, but something for all browsers

Chris: That would allow you to change the name

<ChrisL> stability annotations in the draft. like ednotes point out areas of instability; mark certain properties as very stable and unlikely to be changed

Smfr: Could allow changes in syntax then

Steve: Would make one comment -- point of CR is that a) you've had significant public review, not just wg review, and b) you're ready for implementation

Daniel: But in some cases implementations precede CR by years
...

Steve: If you change the syntax, you'll need to change the prefix

Sylvain: My concern is that you're trying to eliminate the prefixes, but might wind up increasing prefixes.
... If implementations start under their own prefixes for very experimental things, you'll wind up with a prefix on top of all the others.

Smfr: I don't think the browser ship cycle is fast enough to make this useful. We don't drop prefixes as soon as we got to CR

Sylvain: border-radius is a good example ...

Daniel: Users tend to use the most recent browser versions
... border-radius is not the only example
... 2D Transformations is only 2 years old, but has a lot of implementations

Sylvain: The author has to remember which browsers are -vendor-, -w3c-, or no prefix
... They have to track versioning to get the right result

<dbaron> Yeah, it's not clear to me that this proposal will make things less complicated for authors rather than more.

Sylvain: We're just adding this uber prefix to the mix, but it's not going to remove other ones at least not soon

Brad: Yeah, I'll wind up with -moz, -ms, and -w3c

Sylvain: What I'm trying to point out that the goal is to replace what is out there today.
... And if that's the goal, then we have to also remove vendor-specific properties

Daniel: If i listent to Brad, he has to support vendor prefixes no matter what we do
... I think that's all we have to say for now on this topic.
... Is it something we want to discuss again at the F2F?
... Ok, no consensus. Let's move on

Namespace rule in object model

<glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0006.html

Daniel: I think Anne answered my points

Peter: The way we do numbering scheme in rule types in the object model is very fragile
... Having sequential integer values... looking at WebKit's implementation, they add values for their experimental stuff

<anne> I guess in theory we could do away with .type altogether

Peter: Paged Media adds many new at-rules
... We need some way of compartmentalizing modules

<anne> You could just do typeof...

Daniel: Does it require dicussion at Hypertext coordination group?

Animations fill modes follow-up

<glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0010.html

Smfr: I sent out a revised proposal
... Little bit of feedback, but people seem happy with it generally

<anne> glazou, I don't think so; since the CSS WG mints new at-rules we can also hand out numbers for them

Smfr: Anybody have comments on that?

<anne> glazou, implementors should just use values >1000 or some such

<glazou> anne: still, coordination is needed to avoid collisions

Bert: I haven't understood it well, but it seems to me that before and after the animation there are other properties that say what style it has

Smfr: So what happens here is that during the animation, the animation rules override
... The animation is active when the animation name property is in scope
... The animation is active for the duration ....
... The effect of the animation goes away when the animation ends
... With fill-mode, you are extending the effect of the animation into the future until you remove the animation name property
... Does that make sense?

Bert: I don't know if it's really necessary. It sounds like there's now two ways to specify the style of something, that's one way too many

Smfr: Authors often use JS to add and remove animations, and without this it's hard for them to know that they've avoided visual glitches

<dbaron> I think this sounds fine, modulo the revisions we discussed to fix it so that it defines the correct keyframe to be extended in the presence of some of the other properties

Daniel: I had this problem when I wrote an animation

Smfr: Would like to say one othe rthing about htis. If you're using a fill-mode to extend the animation, and your'e using computedStyle, you'll get the style from those key frames
... It ... an API that let's you know where the style is coming from
... It's not really obvious where those styles are coming from
... So an API like currentStyle might have problems with this

dbaron: There's also API requests to say which rules match

Chris: How do you identify the rules?

dbaron: by object: there are rule objects in the OM

Daniel: Ok, what's the next step?

Smfr: Add animation-fill-mode to the animations draft.
... Then at some point look at that draft and decide if we want to move forward on that

Steve: If I understand the meaning, it is extending the animation. Why is it called fill-mode and not something related to duration?

Smfr: You might have an animation that repeats 3 times of 1 second each.
... Fill-mode doesn't say what the duration is, it says how you finish (?)

Steve: I'm just concerned about fill having a completely different meaning in the rest of CSS and SVG

Smfr: That's a fair comment, we cna try to think of alternate names

dbaron: I think I had a similar confusion when I first read the spec.
... I thought it had something to do with repetition

<ChrisL> yes, SVG has to distinguish 2 attrs (on different elements) both called fill. fill is an awful name for the extended duration.

dbaron: Maybe the spec text could explain it better?

Sylvain: Basically it persiststs the DOM in the state of its last keyframe, right?

Smfr: Yes

Sylvain: Yeah, the naming threw me off too

Chris: SVG would love a better name

Smfr: suggestions?

animation-finish-mode?

animation-persist

<ChrisL> endmode

<ChrisL> persistence

Smfr: It also has a backwards-extend ability
... missed explanation

<smfr> fill-mode: backwards will cause the first keyframe to be applied when animation-delay is non-zero

Daniel: We seem to agree on the revised proposal, so let's add that to the spec and leave the research for a better name in the background

fantasai: could add an issue not to the spec

Steve: I think if you follow dbaron's suggestion to improve the text, you might find the name falls out of that process
... It does sound like a duration envelope

<ChrisL> http://www.w3.org/TR/SMIL/smil-timing.html#adef-fill

Steve: Some examples with the delays, etc. would help

Daniel: Anything else on this topic?
... We have only five remaining minutes
... Not enough time for other agenda items. Other suggestions?

dbaron: Reminder about time change next week? :)

Daniel: People based in Europe will have to call one hour early

dbaron: The other thing is the travel time change might be one hour smaller as well
... depends whether you travel Saturday or Sunday

Steve: you should warn jdaggett

Daniel: F2F is approaching, still gathering agenda items
... Please send proposals and ifll in the wiki page

<smfr> paste link to wiki page?

http://wiki.csswg.org/planning/cupertino-2010

<smfr> thanks fantasai

Chris: Wrt SVG joint meeting -- there was a DOM event that some people were planning to come out for
... but it has been cancelled, so we will not be able to do a joint SVG meeting
... We should look to TPAC for joint discussions

Meeting closed.

RRSAgent: make logs public

RRSAgent: make minutes

- DRAFT -

SV_MEETING_TITLE

10 Mar 2010

Attendees

Contents

Media Queries feature for widgets

vendor prefixes

Namespace rule in object model

Animations fill modes follow-up

Summary of Action Items

Scribe.perl diagnostic output