16:06:25 <RRSAgent> RRSAgent has joined #CSS
16:06:25 <RRSAgent> logging to http://www.w3.org/2010/03/10-CSS-irc
16:07:32 <plinss> rrsagent, make logs public
16:07:39 <plinss> zakim, this will be style
16:07:39 <Zakim> ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 53 minutes
16:12:19 <anne> anne has joined #CSS
16:18:10 <Lachy> Lachy has joined #css
16:22:48 <anne> anne has joined #CSS
16:29:26 <glazou> glazou has joined #css
16:29:35 <glazou> Zakim, this will be Style
16:29:35 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 31 minutes
16:29:42 <glazou> RRSAgent, make logs public
16:36:07 <Lachy> Lachy has joined #css
16:37:03 <sylvaing> sylvaing has joined #css
16:45:16 <Lachy> Lachy has joined #css
16:56:10 <bradk> bradk has joined #css
16:58:04 <Zakim> Style_CSS FP()12:00PM has now started
16:58:11 <Zakim> +plinss
16:58:24 <glazou> plinss: arrrgl 
16:58:31 <glazou> my phne does not work !!!!
16:58:38 <plinss> nice
16:58:52 <TabAtkins> TabAtkins has joined #css
16:59:13 <plinss> device problem or line problem?
16:59:15 <smfr> smfr has joined #css
16:59:22 <glazou> don't know yet
16:59:26 <ChrisL> ChrisL has joined #css
16:59:28 <glazou> give me a few seconds
16:59:29 <sylvaing> hadopi strikes again
16:59:32 <plinss> sure
16:59:59 <Zakim> +sylvaing
17:00:08 <glazou> aaaah better
17:00:14 <Zakim> +bradk
17:00:21 <Zakim> +glazou
17:00:53 <Zakim> +Bert
17:01:10 <Zakim> +smfr
17:01:53 <Zakim> +[Microsoft]
17:02:08 <arronei> zakim, microsoft is me
17:02:08 <Zakim> +arronei; got it
17:02:53 <lstorset> lstorset has joined #css
17:03:27 <glazou> ok TabAtkins 
17:03:33 <glazou> no worries
17:03:42 <smfr> i might get called away too (construction people at the house)
17:03:48 <Zakim> + +39.524.9.aaaa
17:03:50 <glazou> ahlala :)
17:03:51 <lstorset> same here
17:03:59 <ChrisL> zakim, aa is me
17:03:59 <Zakim> sorry, ChrisL, I do not recognize a party named 'aa'
17:04:07 <ChrisL> zakim, +aa is me
17:04:07 <Zakim> sorry, ChrisL, I do not recognize a party named '+aa'
17:04:14 <TabAtkins> zakim, aaaa is ChrisL
17:04:16 <Zakim> +ChrisL; got it
17:04:17 <Zakim> +SteveZ
17:04:18 <ChrisL> zakim, +39 s me
17:04:18 <Zakim> I don't understand '+39 s me', ChrisL
17:04:36 <glazou> Zakim, aaaa is ChrisL 
17:04:36 <Zakim> sorry, glazou, I do not recognize a party named 'aaaa'
17:04:44 <Zakim> +[Mozilla]
17:04:44 <ChrisL> zakim, +39 is me
17:04:45 <Zakim> sorry, ChrisL, I do not recognize a party named '+39'
17:04:51 <Zakim> +??P22
17:05:07 <ChrisL> zakim, ++39 is me
17:05:07 <Zakim> sorry, ChrisL, I do not recognize a party named '++39'
17:05:31 <plinss> zakim, ??P22 is lstorset
17:05:31 <Zakim> +lstorset; got it
17:05:43 <dbaron> dbaron has joined #css
17:06:09 <Zakim> +??P26
17:06:28 <fantasai> ScribeNick: fantasai
17:06:47 <fantasai> Daniel: Extra agenda items?
17:07:05 <fantasai> Peter: If you're planning to come to F2F, please remember to fill out questionnaire so dsinger has an accurate count
17:07:09 <plinss> http://www.w3.org/2002/09/wbs/32061/css-wg-cupertino-2010/
17:07:50 <fantasai> Daniel: jdaggett was unable to make call, and so we will defer fonts discussion to next week
17:08:07 <glazou> http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html
17:08:22 <fantasai> Topic: Media Queries feature for widgets
17:08:48 <fantasai> Daniel: Used to detect view mode of widget: minimized, maximized, fullscreen, etc.
17:09:03 <fantasai> Chris: This should not be restricted to widgets, there are plenty of other cases you'd want this info
17:09:30 <fantasai> Daniel: That is my comment also. I think all these mode could apply generally
17:09:36 <fantasai> Daniel: Should live outside of widgets
17:09:49 <fantasai> dbaron: The all value doesn't seem especially useful, since it's always true
17:09:58 <fantasai> ?: Like @media all
17:10:04 <fantasai> dbaron: Might as well not query on feature
17:10:07 <ChrisL> maybe all means "I don't know"
17:10:20 <fantasai> dbaron: Some of these have intersections
17:10:43 <fantasai> dbaron: e.g. I can see both fullscreen and application being true
17:10:50 <fantasai> dbaron: and fullscreen and not-application being true
17:10:58 <fantasai> dbaron: So it seems like there are two different axes here
17:10:58 <ChrisL> application+maximized, application+mini are sensible combinations
17:11:12 <fantasai> Daniel: yeah, application doesn't seem to be a view mode
17:11:34 <fantasai> discussion of various combinations
17:11:50 <fantasai> Chris: There's no value for a normal window, that's not fullscreen
17:11:58 <fantasai> Bert: I thought that was what 'application' meant
17:12:05 <fantasai> dbaron: Seems some of these definitions could be a little clearer
17:12:16 <fantasai> Brad: If they changed application to windowed, it would make more sense to me
17:12:29 <fantasai> Chris: They might be saying something about the presence of chrome
17:13:04 <fantasai> Bert: Not sure you can always tell the difference between application and floating
17:13:20 <fantasai> Bert: Application may have chrome added itself, or chrome added by WM
17:13:50 <fantasai> smfr: Another difference is that for floating, the viewport background is transparent
17:13:57 <fantasai> Brad: Are Opera's widgets floating, then?
17:14:08 <fantasai> smfr: Haven't seen those, but dashboard on Mac is like that
17:14:25 <fantasai> ?: THey're not transparent, but other criteria seem to fit
17:14:41 <lstorset> ? is lstorset
17:14:47 <ChrisL> floating seems to apply to things like the classic round clock widget
17:14:49 <sylvaing> how much chrome is chrome ?
17:14:52 <smfr> someone is on speakerphone
17:15:02 <lstorset> sorry that was me
17:15:14 <fantasai> Daniel: Ok, that's all about comments on values?
17:15:25 <fantasai> Steve: Looking at this thing, it seems to be a weird combination of CSS features 
17:15:35 <fantasai> Steve: Background seems it ought to come from content -- it's transparent or it isn't
17:15:36 <oyvind> opera widgets do have transparent backgrounds I think
17:15:43 <fantasai> Steve: in a CSS window it's normally transparent
17:15:59 <fantasai> Steve: I find it hard to figure out besides maximize and mini what the other things are trying to say
17:16:06 <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)
17:16:06 <fantasai> Steve: And wondering why these aren't CSS properties
17:16:20 <fantasai> Steve: This discussion seems very similar to the one we were having on fit
17:16:33 <fantasai> smfr: These are media /queries/. You're not describing what the content looks like
17:16:40 <fantasai> smfr: you're querying the environment
17:16:52 <fantasai> Sylvain: You can write media queries based on viewport space you have, but this is a little highger level
17:17:33 <fantasai> Daniel: You can write media queries to check size of viewport, but not that the size of viewport matches size of screen
17:17:44 <fantasai> howcome?: Do people want to query whether the window is visible?
17:18:05 <fantasai> Sylvain: You get into is my window visible, do I have focus, etc. 
17:18:13 <fantasai> Sylvain: I kinda like it, but it's not exactly querying the media
17:18:25 <fantasai> Daniel: We already discussed adding values that are more system-based to Media queries
17:19:04 <fantasai> Sylvain: I can see the value, but is it something solely through CSS?
17:19:14 <fantasai> Sylvain: I can see you wnting to access this event-based
17:19:33 <fantasai> fantasai points out that Media Queries isn't a *CSS* spec per se, and it's used in HTMl5 and DOM apis etc too
17:19:59 <fantasai> Steve: The other thing I was hearing was the possible lack of orthogonality
17:20:17 <fantasai> Steve: Of the distinctions between minimized and fullscreen vs. whether chrome is present or not
17:20:37 <fantasai> smfr: Another question -- are these orthogonal to the media type?
17:20:47 <fantasai> smfr: E.g. if I'm in projection mode, do I assume i'm fullscreen?
17:20:59 <fantasai> smfr: Is it possible to be floating but also have a media type of projection?
17:21:08 <fantasai> smfr: I think the spec needs to say something about how those two interact
17:21:28 <fantasai> Daniel: I think projection could imply fullscreen, based on the definitions in CSS
17:21:46 <fantasai> Sylvain: Opera uses projection mode when fullscreened
17:22:04 <fantasai> Daniel: maximize also make sense, mini makes sense...
17:22:17 <fantasai> Daniel: The only one that doesn't make much sense in a browser woudl be floating
17:22:25 <fantasai> Chris: Unless you're a widget in Opera
17:22:33 <fantasai> Daniel: but then your'e a widget
17:22:46 <fantasai> Chris: THe browser is running, but instead of producing a normal window it's showing a widget
17:22:57 <fantasai> Bert: Web pages on the desktop don't have a background either
17:23:01 <fantasai> ?: would be fullscreen
17:23:06 <fantasai> Bert: Not necessarily
17:23:16 <fantasai> Steve: Might make sense for someone from the widgets group to join our call
17:23:45 <fantasai> 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...
17:24:05 <fantasai> 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
17:24:19 <fantasai> Daniel: I will make a response to WepApps group summarizing what we just said.
17:24:23 <fantasai> Daniel: Any other comments?
17:24:43 <fantasai> ACTION: Daniel Respond to WAF
17:24:43 <trackbot> Created ACTION-207 - Respond to WAF [on Daniel Glazman - due 2010-03-17].
17:25:10 <fantasai> Steve: one other comment -- there's a possible feedback group
17:25:28 <fantasai> Steve: To the extent CSS can control what the OS thinks it's doing.. could get a feedback loop
17:25:56 <fantasai> Chris: The value is not maintained live
17:26:02 <fantasai> dbaron: It is maintained live
17:26:42 <fantasai> Daniel: If you query the background, and set it in CSS
17:27:13 <fantasai> 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
17:27:35 <oyvind> "To avoid circular dependencies, it is never necessary to apply the style sheet in order to evaluate expressions" --MQ
17:27:37 <fantasai> Steve: Need to define interaction of CSS settings and the queries
17:28:15 <fantasai> Daniel: Next item
17:28:19 <fantasai> Topic: vendor prefixes
17:28:24 <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0235.html
17:28:48 <fantasai> Daniel: I did not follow the whole thread on that
17:28:59 <fantasai> Daniel: I think the way we handle vendor prefixes in CSS is too monolithic
17:29:08 <fantasai> Daniel: We only remove them when one complete spec moves to CR
17:29:25 <ChrisL> rounded corners!!
17:29:26 <fantasai> Daniel: While some properties could remove prefix long before that
17:29:35 <fantasai> Daniel: I think it should be decision of the group
17:30:07 <fantasai> Bert: I don't think we should not create an extra process in addition to what's provided by W3C
17:30:36 <fantasai> Daniel: We have many examples of live properties shipped in browsers that web authors must manipulate in four or five flavors
17:31:04 <fantasai> Daniel: What we did with border-radius, border-radius was at least partially interoperable in most browsers but people had to use five variants
17:31:11 <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
17:31:48 <fantasai> Daniel: When the group decides that a property is stable and interoperable enough, then the prefix can be removed
17:31:59 <fantasai> Bert: Then you need another WD
17:32:08 <fantasai> smfr: That would be an annotation in the draft
17:32:13 <fantasai> s/draft/existing/
17:32:15 <fantasai> er
17:32:22 <fantasai> s/existing/existing draft/
17:32:32 <fantasai> Daniel: Or have a prefix for the WG, but something for all browsers
17:32:58 <fantasai> Chris: That would allow you to change the name
17:33:02 <ChrisL> stability annotations in the draft. like ednotes point out areas of instability; mark certain properties as very stable and unlikely to be changed
17:33:17 <fantasai> Smfr: Could allow changes in syntax then
17:33:42 <fantasai> 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
17:33:59 <fantasai> Daniel: But in some cases implementations precede CR by years
17:34:31 <fantasai> ...
17:34:54 <fantasai> Steve: If you change the syntax, you'll need to change the prefix
17:35:21 <fantasai> Sylvain: My concern is that you're trying to eliminate the prefixes, but might wind up increasing prefixes.
17:35:55 <fantasai> Sylvain: If implementations start under their own prefixes for very experimental things, you'll wind up with a prefix on top of all the others.
17:36:19 <fantasai> 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
17:36:38 <fantasai> Sylvain: border-radius is a good example ...
17:37:06 <fantasai> Daniel: Users tend to use the most recent browser versions
17:37:13 <fantasai> Daniel: border-radius is not the only example
17:37:26 <fantasai> Daniel: 2D Transformations is only 2 years old, but has a lot of implementations
17:37:43 <fantasai> Sylvain: The author has to remember which browsers are -vendor-, -w3c-, or no prefix
17:37:52 <fantasai> Sylvain: They have to track versioning to get the right result
17:38:04 <dbaron> Yeah, it's not clear to me that this proposal will make things less complicated for authors rather than more.
17:38:04 <fantasai> Sylvain: We're just adding this uber prefix to the mix, but it's not going to remove other ones at least not soon
17:38:37 <fantasai> Brad: Yeah, I'll wind up with -moz, -ms, and -w3c
17:38:50 <Zakim> +SteveZ.a
17:38:56 <Zakim> -SteveZ
17:38:59 <fantasai> Sylvain: What I'm trying to point out that the goal is to replace what is out there today.
17:39:18 <fantasai> Sylvain: And if that's the goal, then we have to also remove vendor-specific properties
17:39:41 <fantasai> Daniel: If i listent to Brad, he has to support vendor prefixes no matter what we do
17:40:20 <fantasai> Daniel: I think that's all we have to say for now on this topic.
17:40:28 <fantasai> Daniel: Is it something we want to discuss again at the F2F?
17:40:36 <fantasai> Daniel: Ok, no consensus. Let's move on
17:40:52 <fantasai> Topic: Namespace rule in object model
17:40:58 <glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0006.html
17:41:00 <fantasai> Daniel: I think Anne answered my points
17:41:46 <fantasai> Peter: The way we do numbering scheme in rule types in the object model is very fragile
17:42:00 <ChrisL> zakim, mute me
17:42:00 <Zakim> ChrisL should now be muted
17:42:17 <fantasai> Peter: Having sequential integer values... looking at WebKit's implementation, they add values for their experimental stuff
17:42:20 <anne> I guess in theory we could do away with .type altogether
17:42:24 <fantasai> Peter: Paged Media adds many new at-rules
17:42:31 <fantasai> Peter: We need some way of compartmentalizing modules
17:42:34 <anne> You could just do typeof...
17:42:49 <fantasai> Daniel: Does it require dicussion at Hypertext coordination group?
17:43:21 <fantasai> Topic: Animations fill modes follow-up
17:43:22 <glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0010.html
17:43:31 <fantasai> Smfr: I sent out a revised proposal
17:43:42 <fantasai> Smfr: Little bit of feedback, but people seem happy with it generally
17:43:45 <anne> glazou, I don't think so; since the CSS WG mints new at-rules we can also hand out numbers for them
17:43:53 <fantasai> Smfr: Anybody have comments on that?
17:43:55 <anne> glazou, implementors should just use values >1000 or some such
17:44:11 <glazou> anne: still, coordination is needed to avoid collisions
17:44:14 <fantasai> 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
17:44:33 <fantasai> Smfr: So what happens here is that during the animation, the animation rules override
17:44:44 <fantasai> Smfr: The animation is active when the animation name property is in scope
17:44:54 <fantasai> Smfr: The animation is active for the duration ....
17:45:06 <fantasai> Smfr: The effect of the animation goes away when the animation ends
17:45:24 <fantasai> Smfr: With fill-mode, you are extending the effect of the animation into the future until you remove the animation name property
17:45:27 <fantasai> Smfr: Does that make sense?
17:45:48 <fantasai> 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
17:46:10 <fantasai> 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
17:46:12 <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
17:46:18 <fantasai> Daniel: I had this problem when I wrote an animation
17:47:02 <fantasai> 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
17:47:05 <ChrisL> zakim, unmute me
17:47:05 <Zakim> ChrisL should no longer be muted
17:47:12 <fantasai> Smfr: It ... an API that let's you know where the style is coming from
17:47:24 <fantasai> Smfr: It's not really obvious where those styles are coming from
17:47:40 <fantasai> Smfr: So an API like currentStyle might have problems with this
17:47:54 <fantasai> dbaron: There's also API requests to say which rules match
17:48:05 <fantasai> Chris: How do you identify the rules?
17:48:14 <fantasai> dbaron: by object: there are rule objects in the OM
17:48:58 <fantasai> Daniel: Ok, what's the next step?
17:49:07 <fantasai> Smfr: Add animation-fill-mode to the animations draft. 
17:49:20 <fantasai> Smfr: Then at some point look at that draft and decide if we want to move forward on that
17:49:44 <fantasai> Steve: If I understand the meaning, it is extending the animation. Why is it called fill-mode and not something related to duration?
17:49:57 <fantasai> Smfr: You might have an animation that repeats 3 times of 1 second each.
17:50:09 <fantasai> Smfr: Fill-mode doesn't say what the duration is, it says how you finish (?)
17:50:30 <fantasai> Steve: I'm just concerned about fill having a completely different meaning in the rest of CSS and SVG
17:50:40 <fantasai> Smfr: That's a fair comment, we cna try to think of alternate names
17:50:53 <fantasai> dbaron: I think I had a similar confusion when I first read the spec.
17:51:00 <fantasai> dbaron: I thought it had something to do with repetition
17:51:07 <ChrisL> yes, SVG has to distinguish 2 attrs (on different elements) both  called fill. fill is an awful name for the extended duration.
17:51:08 <fantasai> dbaron: Maybe the spec text could explain it better?
17:51:24 <fantasai> Sylvain: Basically it persiststs the DOM in the state of its last keyframe, right?
17:51:27 <fantasai> Smfr: Yes
17:51:36 <fantasai> Sylvain: Yeah, the naming threw me off too
17:51:59 <fantasai> Chris: SVG would love a better name
17:52:27 <fantasai> Smfr: suggestions?
17:52:30 <fantasai> animation-finish-mode?
17:52:47 <fantasai> animation-persist
17:52:51 <ChrisL> endmode
17:53:00 <ChrisL> persistence
17:53:29 <fantasai> Smfr: It also has a backwards-extend ability
17:53:46 <fantasai> .. missed explanation
17:54:10 <smfr> fill-mode: backwards will cause the first keyframe to be applied when animation-delay is non-zero
17:54:14 <fantasai> 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
17:54:38 <fantasai> fantasai: could add an issue not to the spec
17:54:52 <fantasai> Steve: I think if you follow dbaron's suggestion to improve the text, you might find the name falls out of that process
17:55:01 <fantasai> Steve: It does sound like a duration envelope
17:55:08 <ChrisL> http://www.w3.org/TR/SMIL/smil-timing.html#adef-fill
17:55:12 <fantasai> Steve: Some examples with the delays, etc. would help
17:55:27 <fantasai> Daniel: Anything else on this topic?
17:55:35 <fantasai> Daniel: We have only five remaining minutes
17:55:55 <fantasai> Daniel: Not enough time for other agenda items. Other suggestions?
17:56:02 <fantasai> dbaron: Reminder about time change next week? :)
17:56:20 <fantasai> Daniel: People based in Europe will have to call one hour early
17:56:40 <fantasai> dbaron: The other thing is the travel time change might be one hour smaller as well
17:56:55 <fantasai> dbaron: depends whether you travel Saturday or Sunday
17:57:22 <fantasai> Steve: you should warn jdaggett
17:57:40 <fantasai> Daniel: F2F is approaching, still gathering agenda items
17:57:49 <fantasai> Daniel: Please send proposals and ifll in the wiki page
17:57:52 <smfr> paste link to wiki page?
17:58:16 <fantasai> http://wiki.csswg.org/planning/cupertino-2010
17:58:24 <smfr> thanks fantasai 
17:58:37 <fantasai> Chris: Wrt SVG joint meeting -- there was a DOM event that some people were planning to come out for
17:58:49 <fantasai> Chris: but it has been cancelled, so we will not be able to do a joint SVG meeting
17:59:00 <fantasai> Chris: We should look to TPAC for joint discussions
17:59:11 <fantasai> Meeting closed.
17:59:11 <Zakim> -SteveZ.a
17:59:12 <Zakim> -smfr
17:59:14 <Zakim> -sylvaing
17:59:14 <Zakim> -plinss
17:59:16 <Zakim> -ChrisL
17:59:17 <Zakim> -arronei
17:59:17 <Zakim> -dbaron
17:59:18 <Zakim> -fantasai
17:59:20 <Zakim> -glazou
17:59:22 <Zakim> -Bert
17:59:22 <fantasai> RRSAgent: make logs public
17:59:25 <Zakim> -lstorset
17:59:26 <Zakim> -bradk
17:59:26 <fantasai> RRSAgent: make minutes
17:59:26 <RRSAgent> I have made the request to generate http://www.w3.org/2010/03/10-CSS-minutes.html fantasai
17:59:28 <Zakim> Style_CSS FP()12:00PM has ended
17:59:30 <Zakim> Attendees were plinss, sylvaing, bradk, glazou, Bert, smfr, arronei, +39.524.9.aaaa, ChrisL, SteveZ, lstorset, dbaron, fantasai
18:00:16 <glazou> glazou has left #css
18:19:47 <smfr> smfr has left #css
19:56:47 <Zakim> Zakim has left #CSS
20:26:24 <jdaggett> jdaggett has joined #css