- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 12 Aug 2009 15:40:29 -0700
- 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 UTC