[CSSWG] Minutes and Resolutions 2010-03-10


   - Reviewed WAF draft for media queries features for widgets
     Comments include that these features should be scoped more broadly
     since they are generally applicable; that the 'all' value seems
     redundant and unnecessary; that the names and descriptions are
     unclear; that there seem to be multiple feature axes covered by the
     same query; and that 'mini' and 'maximize' are grammatically
     inconsistent. Daniel will send comments on behalf of the WG:

   - Discussed suggestion for vendor-neutral draft prefix. No agreement
     to introduce one.

   - Discussed namespace rule in object model. Noted that current method
     of handling at-rules is likely to introduce accidental conflicts.

   - Reviewed Simon's animation-fill-rule proposal:
     The property name is confusing, but the proposal seems otherwise
     good, and will be added to the Animations draft with a note about
     possible renaming.

====== Full minutes below ======

   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Chris Lilley
   Peter Linss
   Leif Arne Storset
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/03/10-CSS-irc
Scribe: 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

Review of WAF draft Media Queries feature for widgets

   <glazou> http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html
   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
   Daniel: 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
   dbaron: e.g. I can see both fullscreen and application being true
   dbaron: and fullscreen and not-application being true
   dbaron: 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
   Bert: Application may have chrome added itself, or chrome added by WM
   Simon: Another difference is that for floating, the viewport background
          is transparent
   Brad: Are Opera's widgets floating, then?
   Simon: Haven't seen those, but dashboard on Mac is like that
   Leif: They're not transparent, but other criteria seem to fit
   <ChrisL> floating seems to apply to things like the classic round
            clock widget
   <sylvaing> how much chrome is chrome ?
   Daniel: Ok, that's all about comments on values?

   Steve: Looking at this thing, it seems to be a weird combination of
          CSS features
   Steve: 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
   Steve: 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
   Steve: This discussion seems very similar to the one we were having on fit
   Simon: These are media /queries/. You're not describing what the content
          looks like
   Simon: 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
   ?: Do people want to query whether the window is visible?
   Sylvain: You get into is my window visible, do I have focus, etc.
   Sylvain: 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?
   Sylvain: 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
   Steve: Of the distinctions between minimized and fullscreen vs. whether
          chrome is present or not
   Simon: Another question -- are these orthogonal to the media type?
   Simon: E.g. if I'm in projection mode, do I assume i'm fullscreen?
   Simon: Is it possible to be floating but also have a media type of projection?
   Simon: 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...
   Daniel: The only one that doesn't make much sense in a browser would be
   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 everywhere, then saying they're not
          quite general...
   Steve: maybe the answer is to work with them to come up with 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.
   Daniel: Any other comments?
   ACTION: Daniel Respond to WAF
   Steve: one other comment --
   Steve: 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 color 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
   Daniel: I think the way we handle vendor prefixes in CSS is too monolithic
   Daniel: We only remove them when one complete spec moves to CR
   <ChrisL> rounded corners!!
   Daniel: While some properties could remove prefix long before that
   Daniel: 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
   Daniel: 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
   Simon: It 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
   Simon: 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.
   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.
   Simon: 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
   Daniel: border-radius is not the only example
   Daniel: 2D Transformations is only 2 years old, but has a lot of
   Sylvain: The author has to remember which browsers are -vendor-, -w3c-,
            or no prefix
   Sylvain: 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.
   Sylvain: And if that's the goal, then we have to also remove vendor-specific
   Daniel: If I listen to Brad, he has to support vendor prefixes no matter
           what we do
   Daniel: I think that's all we have to say for now on this topic.
   Daniel: Is it something we want to discuss again at the F2F?
   Daniel: 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
   Peter: 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
   Peter: We need some way of compartmentalizing modules
   <anne> You could just do typeof...
   Daniel: Does it require dicussion at Hypertext coordination group?
   <anne> glazou, I don't think so; since the CSS WG mints new at-rules we
          can also hand out numbers for them
   <anne> glazou, implementors should just use values >1000 or some such
   <glazou> anne: still, coordination is needed to avoid collisions

Animations fill modes follow-up

   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Mar/0010.html
   Simon: I sent out a revised proposal
   Simon: Little bit of feedback, but people seem happy with it generally
   Simon: Anybody have comments on that?
   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
   Simon: So what happens here is that during the animation, the animation
          rules override
   Simon: The animation is active when the animation name property is in scope
   Simon: The animation is active for the duration ....
   Simon: The effect of the animation goes away when the animation ends
   Simon: With fill-mode, you are extending the effect of the animation into
          the future until you remove the animation name property
   Simon: 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
   Simon: 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
   Simon: 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
   Simon: It ... an API that let's you know where the style is coming from
   Simon: It's not really obvious where those styles are coming from
   Simon: 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?
   Simon: Add animation-fill-mode to the animations draft.
   Simon: 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?
   Simon: You might have an animation that repeats 3 times of 1 second each.
   Simon: 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
   Simon: 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.
   dbaron: 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,
   Simon: Yes
   Sylvain: Yeah, the naming threw me off too
   Chris: SVG would love a better name
   Simon: suggestions?
   <ChrisL> endmode
   <ChrisL> persistence
   Simon: It also has a backwards-extend ability
   ... [missed explanation] ...
   <Simon> 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
   Steve: 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?

Administrative Part II

   Daniel: We have only five remaining minutes
   Daniel: 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
   dbaron: depends whether you travel Saturday or Sunday
   Steve: you should warn jdaggett
   Daniel: F2F is approaching, still gathering agenda items
   Daniel: Please send proposals and fill in the wiki page
   Chris: Wrt SVG joint meeting -- there was a DOM event that some people
          were planning to come out for
   Chris: but it has been cancelled, so we will not be able to do a joint SVG meeting
   Chris: We should look to TPAC for joint discussions

Meeting closed.
<RRSAgent> http://www.w3.org/2010/03/10-CSS-minutes.html

Received on Thursday, 11 March 2010 20:14:07 UTC