W3C home > Mailing lists > Public > www-style@w3.org > August 2009

[CSSWG] Minutes and Resolutions 2009-08-12

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 12 Aug 2009 15:40:29 -0700
Message-ID: <4A8344DD.9040308@inkedblade.net>
To: www-style@w3.org
Summary:

   - Discussed adding gradients to css3-images. Straw poll indicates yes,
     there is support for this in the WG. Several people sympathized with
     Bert's argument argument against expanding the scope of CSS too much,
     but none except Bert went so far as to object to the proposal for
     gradients. Hyatt and roc will draft a combined proposal. fantasai
     suggests simplifying the syntax.

   - RESOLVED: Accept Bert's proposal to change the Media Queries and
               CSS2.1 Appendix G grammars to use a new media_list
               production so that Media Queries can easily swap out the
               relevant part of CSS2.1's syntax.
               http://lists.w3.org/Archives/Public/www-style/2009Aug/0124.html

   - RE-RESOLVED: @media { ... } is invalid.

   - RESOLVED: Publish updated CR draft of Media Queries with these changes.

   - Discussed effect of drop-shadows on layout. No resolution, but
     css3-background will include wording on both border-image and box-shadow
     not affecting layout, and the CSS3 module covering overflow will need
     to discuss in detail the differences between overflow that affects layout,
     overflow that triggers scrolling, and overflow that does not.

   - Brad Kemper added as co-editor of css3-background.

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

Present:

   César Acebal
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Dave Hyatt
   Brad Kemper
   Hĺkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer

<RRSAgent> Logging to http://www.w3.org/2009/08/12-CSS-irc
Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0054.html

Gradients
---------

   Hyatt: Now that we have css3-image module, it seems like gradients
          work that is implemented in Mozilla and WebKit would fit
          well in there
   Hyatt: Both Robert and I saw that draft and thought it would be a
          logical fit
   Brad: Think it's a good idea
   fantasai: I had a blank Gradients section in there before publication
   Hyatt: Mozilla and WebKit's syntax are very different
   Hyatt: So Robert and I need to start working on text for it
   ChrisL: Looking at Mozilla page, can't see it.
   dbaron: Need to use 3.6 alpha
   howcome: You can also do gradients with inset box-shadows, but this is
            a better solution
   <dsinger_> Hm. If Chris can't see it, what is the fallback?
   fantasai: I think the syntax is very verbose. Is it verbose because
             we need room for extensions, or is it verbose because no
             one's bothered to simplify it yet
   Bert: I'm strongly opposed to gradients in CSS. you can do this with
         background images
   Hyatt: It gives a chance to reduce bandwidth greatly.
   hyatt: Web inspector was able to remove 40 images
   Bert: Next people are going to reimplement SVG in CSS, I don't want to
         get there
   Sylvain: IE has proved that people go through great lengths to reproduce
            features, and they hate it
   howcome: It's reducing use of images, CSS is good at that
   Bert: ... [couldn't catch it]
   <ChrisL> I don't think this is reimplementing the whole of SVG. Its a
            fairly limited piece of functionality
   <dsinger_> Hm. Would Bert prefer an image 'codec' that is a generator?
   howcome: I agree with the sentiment, but I don't think gradients are
            that far out there
   Bert: Next people want circles and ovals etc. Each one takes 5 minutes,
         but it takes a long time to learn the whole thing
   <ChrisL> It doesn't seem to be particularly complex to me
   ChrisL: The boat has already sailed, CSS is no longer simple. It takes
           a lot of effort to understand real-world style sheets
   ChrisL: you could do this with images or data URIs
   ChrisL: But the syntax gets very verbose
   ChrisL: So I can see the motivation for this
   howcome: Need vector representations for this
   ChrisL: And in Opera you have SVG support so you can do vector versions
           of complicated things
   ChrisL: This seems like low-hanging fruit, if you just want a simple
           gradient
   Brad: I think gradients are a common design element and to be able to
         specify one ... has a lot of merit
   * dbaron thinks bradk broke up even more the second time
   * ChrisL cannot hear brad well at all. really breaking up
   * fantasai too
   * sgalineau must not point out that gradients is probably easier to
               specify than, um, text-replace :)
   * ChrisL chuckles at sgalineau
   Hyatt: They're in the same category as shadows and rounded corners
   Hyatt: It's a common effect

   Peter: I think gradients should be usable anywhere you can use a color
   fantasai: That won't work. Colors are 0D, gradients are 2D
   ChrisL: Yes, some places that don't have a geometric region, these need
           to have colors not gradients
   dbaron: Also, e.g. 'color' is inherited
   * sgalineau can definitely see gradients used for border-image
   Peter: Agreed, don't need to expand it everywhere now, but will want
          to apply it other places e.g. text
   Hyatt: You can do that in webkit by specifying a clip for the text
   dbaron: In Gecko you can probably do it with filters or clip-path.
   ChrisL: I would be concerned if we add syntax for gradients 3 ways for
           3 different use cases.. if we add it differently for backgrounds
           and foreground
   Hyatt: That's why we want it as an image type, you can use it for many
          different things
   <bradk> my phone connection keeps dropping. sorry.
   <dbaron> Ah right... 'mask' was the third of those SVG properties
            ('clip-path', 'filter', 'mask')
   ChrisL: Hard to use with border-image.
   ChrisL: Can't say, e.g. use this gradient for the top border, this for
           the bottom, etc.
   Hyatt: Also, mozilla applies 'background-repeat' to gradients in terms
          of repeating the gradient rather than just tiling an image.
   Hyatt: With gradients in CSS you can also animate them

   fantasai: The problem with that is that it's specific to backgrounds,
             hard to make it generic if it's not a rectangular region
   * sgalineau notes that one can create pretty crazy gradient patterns
               with canvas today and turns them into a data URI
   Peter: Straw poll on adding gradients?
   dsinger: Would like proposers to come up with an exact proposal
   fantasai: Should have a resolution on whether or not we are receptive
             to gradients
   fantasai: That way they know the whole thing won't get thrown out
             because we decide its out of scope or something
   <ChrisL> +1 to add to images module. "So what exactly is a gradient
            in CSS? It is an image, usable anywhere that image URLs
            were used before. That's right anywhere"
   Sylvain: You could create gradient patterns with Canvas, turn it
            into a data URI. Probably how people would do it today
   Hyatt wants to copy language from HTML5(?)
   ChrisL: Can you get elliptical gradients?
   <dbaron> ChrisL, well, the non-background uses actually need to
            define a size better...
   Peter: Straw poll
   Sylvain: yes
   Arron: yes
   Bert: no
   dbaron: yes
   Hyatt: in favor
   <bradk> in favor
   fantasai: abstain
   <anne> in favor
   howcome: We should be careful not to do too much, but I think this
            is one of the things we should do
   Chris: in favor
   dsinger: abstain in deference to Hyatt. Think we should look at
            what we're doing and find the edges of where we want to
            go, but I think we should go forward here
   Peter: in favor
   Peter: Only seeing one objection, so I'd say go ahead and draft a proposal
   * ChrisL isn't getting this to work in Safari 4.0.2/win ... should it?
   * fantasai need webkit syntax?
   <hyatt> yes it should, but we use different syntax from mozilla
   * ChrisL stupid -foo-whatever -syntax -vendor stuff
   <hyatt> yeah :)
   * fantasai in this case they're actually quite different internally as well
   <hyatt> -zomg-dont-implement-me-yet-gradient(...)
   * ChrisL so that is a benefit to getting the syntax standardised then
   <Bert> (I want to put my H2 vertically, I want to hyphenate words,
          I want to rotate the F as in Finnegan's Wake, I want the
          OBJECT element to be as high as it s content... so many
          things that you need CSS for. Gradients is frivolous and
          thus harmful. :-( )
   * ChrisL counts the number of web pages that use gradients vs
            the number that have rotated initial letters .....
   <Cesar> Oops, I'm afraid I had my microphone mute when I answered
           the poll, sorry  (it's the first time I use it). ;)
           Anyway, my position about gradients was "abstain", since
           I mostly agree with Bert, but I have no a clear position
           about what to keep and what to get rid of.
   * fantasai also agrees with Bert here, but there's too much demand for
              gradients for UAs to resist and we need to standardize here.


Media Queries
-------------

   <hyatt> don't everyone talk at once... ;)
   * anne2 (the reason I cannot dial in btw is that Skype on Ubuntu
           sucks and I didn't take my Macbook to France)
   * sgalineau anne, you can be in France or have no Macbook. Both is criminal :)

   <plinss> http://lists.w3.org/Archives/Public/www-style/2009Jun/0536.html
   Bert: Original question was that Media Queries spec replaces part
         of the CSS2.1 grammar
   Bert: But the "this part" doesn't refer to something correct. Can't
         just replace that production
   Bert: one proposal I made, that Anne agrees with, is to rewrite the
         grammar in Appendix G of CSS2.1 so that it contains a single
         token that Media Queries can easily replace
   <plinss> http://lists.w3.org/Archives/Public/www-style/2009Aug/0124.html
   Bert: Proposal is to add a new media_query_list token in Appendix G
   <dbaron> This proposal sounds good to me, except I wonder if it might
            be clearer if the CSS 2.1 production had a different name
            so that it wouldn't look like CSS 2.1 had media queries.
   Bert: That is the only thing that needs to be changed, in 2 places:
         Media Queries Module and CSS2.1 Appendix G

   Bert: Also dbaron raised another issue in response to this one
   Bert: Whether @media should allow no media query at all, e.g. @media { }
   Bert: That I don't think we should do
   fantasai: I'm pretty sure we discussed this already and decided we
             don't want to allow @media { }
   Bert: In response to dbaron's comment on IRC, maybe we should have
         media_list instead of media_query_list
   Peter: So two items, one changing the grammar for this fix
   Peter: Any objections?
   * bradk has no opinion about the grammar change to media queries
   Bert: Changing to this grammar is not substantive for 2.1, btw, it
         just makes the grammar a little verbose but it defines exactly
         the same language
   fantasai: I agree with the change
   RESOLVED: Accept Bert's proposal to change grammar, using media_list
             instead of media_query_list
   <oyvinds> I remember finding the terminology "production A: B replaces C: D"
             slightly confusing, but with the right wording media_list
             probably makes more sense
   Peter: Second item, allowing @media { } ... fantasai says we have a
          previous resolution not to accept that, is everyone ok with that?
   ChrisL: yeah, seems good
   RESOLVED: @media { } invalid

   dbaron: Still a question as to whether other uses of media queries
           make an empty media query list invalid
   dbaron: Right now it defines emtpy media query list as matching everything
   dbaron: So I think that's relevant for things like
             <link rel="stylesheet" media="">
   Bert: That's currently an error
   <anne> My suggestion is to remove that from Media Queries, make it an
          error, and require UAs to treat media="" as media="all"
   dbaron: If you combine Media Queries with HTML5 that says media attr
           takes media queries, that's no longer true
   <anne> (the latter would require a change to HTML5, that Ian is willing
          to make)
   <dbaron> anne, ok, that's fine with me
   <dbaron> anne, as long as somebody tells me if there are any other cases
            that should have the same behavior as media="" in HTML (on link
            and style, I presume)
   RESOLVED: Publish updated CR draft of Media Queries with these changes
   <anne> dbaron, <?xml-stylesheet?> and presumably <svg:style>
   <dbaron> Of course, I think I have a whole bunch of tests that depended
            on the other behavior...
   <anne> dbaron, the behavior for <style media> should not change,
          just conformance

Shadow vs Layout
----------------

   fantasai: I think we have agreement that shadows not affect layout
             for box-shadow
   fantasai: I know Hyatt wanted some comprehensive text on overflow,
             but can't fit it into css3-background
   Hyatt: Also, should say that it applies to border-image
   Hyatt: Brad had an example where the border-image was used to create shadows
   Hyatt: Don't want scrollbars, especially horizontal scrollbars
   Brad: It's not just the scrollbar appearing, but also extra whitespace
         appearing b/c shadow is pushing out the edge of the container
   Hyatt: I was the only one on the list that objected to this, but I
          think mostly I was being a lazy implementor
   * sgalineau prefers lazy implementation
   ChrisL: Particularly for horizontal scrollbars, it would be fairly easy
           to arrange things so they fit but now you add a drop-shadow
           and it doesn't fit anymore
   fantasai: Just wanted to understand reasoning, not objecting
   fantasai: Are margins included in scrollable area?
   Hyatt: Varies from browser to browser, whether child margins are included
          in scrollable area
   Peter: Have a higher-level concern about this
   Peter: Agree that visual effects should never affect layout
   Peter: Concern is that presence or absence of scrollbar afffects layout
   Peter: What about scrolling mechanism that doesn't affect layout?
   Hyatt: Webkit has that, scrollbars that appear over content
   <Bert> (We have marquee for overflow, too.)
   fantasai: Discussion on www-style said that even if you already have
             scrollbars, don't want to be able to scroll further to be
             able to see these effects
   Peter: Don't see why not
   * sgalineau is puzzled by the need to scroll to non-content
   <bradk> my connection sucks
   <oyvinds> animating/pulsating shadows would cause the scrollbar "thumb"
             to animate too
   fantasai attempts to summarize the discussion on www-style
   fantasai: It's not about whether scrollbars appear or disappear,
             shadows should just be clipped
   fantasai: they should not increase the size of the scrollable area
   Peter: I think whether it increase the scrollable area should be a UA decision
   Hyatt: Want these two concepts of overflow documented in a spec
   fantasai: Has to be in CSS3 module e.g. css3-box, too much for 2.1
   Hyatt: add a sentence for border-image

Other Topics
------------

   fantasai: I propose adding Brad Kemper as co-editor of css3-background
   Agreed.

Meeting closed

<dbaron> anne, so if empty media lists are supposed to be valid for
          every known use of media queries except @media... maybe
          @media should be the one where the spec makes an exception,
          rather than making exceptions for all the others?
<anne> the idea was to make them invalid (like in HTML4) but require
        UAs to treat them as all because of compat
<anne> I don't feel strongly either way
<dbaron> ah, ok
<dbaron> well, code-wise, I might make the @media case the exception
Received on Wednesday, 12 August 2009 22:41:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT