- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 30 Sep 2009 18:04:25 -0700
- To: www-style@w3.org
Summary:
- RESOLVED: add gradients to css3-images
(Also: Tab will add SVG equivalents for all the examples.)
- RESOLVED: Drop box-shadow from css3-background: work on box-shadow outside
css3-background for the time being, possibly re-merge with draft
later.
RATIONALE: drop-shadows seem to need a lot more discussion, but the rest
of the draft is ready to move on
- RESOLVED: border-image resizes to small boxes the same way as border-radius
- Discussed Doug's message about extensions to DOM mouse events and whether
they belong in the CSSOM View module or in DOM3 Events
http://lists.w3.org/Archives/Public/www-style/2009Sep/0180.html
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Elika Etemad
Sylvain Galineau
Daniel Glazman
Dave Hyatt
Brad Kemper
Peter Linss
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2009/09/30-CSS-irc
Gradients
---------
<TabAtkins> http://www.xanthir.com/:4bhipd
Daniel: Two proposals for gradients; consideration of adding to css3-images.
Daniel: Proposal from apple, new proposal from Tab.
Daniel: Still feasible to add to css3-images?
Bert doesn't think this should be in CSS at all
Steve: I went back and checked SVG, and gradients are really a content object
Steve: So why would they be defined in CSS?
Steve: We don't define images, do we?
Tab: In SVG they're content objects, but not in CSS+HTML documents
dbaron: In SVG, everything is a content object
Steve: The reason they are content in SVG is so you can use in any of
your graphics (?)
Steve: ... why are we defining this in CSS?
Daniel: 1st, SVG and HTML4 dont live well together
Daniel: 2nd, creating an SVG object for this is overkill
hyatt: You can use them anywhere there's an image: background-image,
list-style-image, etc.
Tab: In my proposal they're an abstraction as an image in css3-images
hyatt: Yes, that's why we're proposing to put them in css3-images
Sylvain: What Steve is saying is that we're defining an image inline in CSS,
we don't do that anywhere else
Tab: Gradients are very easy to linearize, much smaller when given as
text description than as an image
hyatt: We cut out over 40 images when we converted ?product? to gradients
hyatt: Very dramatic savings because these images are not that small
Sylvain: ...
Steve: My comment wasn't so much that I thought we should use images
for gradients, I don't think that
Steve: I just found it strange in some sense that we were creating CSS
syntax for content objects
Daniel: I disgree with "content object"
hyatt: Don't know where you're getting "content object". Everything in
SVG is a "content object", doesn't mean it's not presentational
<sylvaing> I buy that this use-case is so common and beneficial that
it deserves a 'promotion' to a compact CSS syntax; but as
this is an exception, this is a case we may have to explain
in the specification.
Steve: Where I'm really going is, given that SVG has gradients, what
happens with just doing an SVG-like syntax in CSS?
Steve: Is that totally impossible?
Tab: I suspect that would be really heavy-weight for what we're trying
to do here
Tab: It's good for a general solution, for doing everything. But
gradients are so simple that we'll get a lot of benefit by doing
it in a CSS syntax
Steve: I didn't say use SVG. I said use SVG as the model for what the
gradient is, and convert that in to CSS syntax
hyatt: That's what we're doing. All the gradients in SVG, Canvas, and
CSS.. they're all implemented the same way, just different syntax
hyatt: I think already the syntax is close enough that what you're
getting is what you'd get in SVG
Steve: ... creates a problem down the road when the mapping is subtly
different
hyatt: It's similar enough that I don't think people will be confused.
Especially for linear gradients
Steve: You keep answering in ways that cause me to be concerned e.g.
"especially linear gradients, but not radial ones"
Steve: I would be much happier with something that was really really
close to what SVG did
Tab: I would be much happier with something that was much simpler and
easier to understand for authors
Sylvain: ... from the examples he has in there, show the SVG then we
can see how close or far they are
Tab: I'll need help authoring the SVG, I don't know enough
Bert: Just use a tool
<fantasai> Tab, I suggest asking shepazu for help :)
* fantasai is not minuting this argument between Bert and Glazou
Bert is arguing that people should just us SVG
* sylvaing wonders if one could transform an SVG gradient into Tab's
declarations; if so, we have a mapping
* fantasai thinks it's easier to go the other way
* fantasai which is what we reallly need
hyatt: I don't think it's reasonable to ask authors to use XHTML in
order to use gradients
Bert: I would keep the SVG in a separate file
<TabAtkins> yeah, going from mine->SVG is probably simpler. Though I'm
not sure quite how to make it respond properly to all the
box information that my proposal has.
<fantasai> ask shepazu, he's an SVG person
Bert complains that CSS has too many features
Tab: I don't know how well SVG responds to resizing
Tab: My proposal explicitly went out of its way to make it simple to
hit all the common cases
Sylvain: I agree, and if there's something complicated you want go to
SVG there's no argument there
Sylvain: Are asking whether we want gradients as images, or whether
we want gradients in CSS at all?
Bert: Let's see what people do with background module, then see if
it's necessary
<hyatt> gradients aren't just a fad or phase. they'll be around in
years still. :)
<hyatt> they've been in use for years
Sylvain: They've been using gradients with background images for years
Glazou: I will be speaking at web conference in France. I wanted to
tell them that we will have gradients in CSS. If we won't have
it for 4 years, they are going to shout
...
<shepazu> I'm happy to help if I can see the proposal
<TabAtkins> shepazu, http://www.xanthir.com/:4bhipd
dbaron: Doing a gradient at 45deg that resizes appropriately with the
box... I don't know how to do that
dbaron: There are a whole bunch of use cases that the proposal handles
that you can't do with SVG
dbaron: The problem with resizing SVG is that you'll get a distortion
Steve: That's not how it works, SVG gradients don't get distorted
clarification: SVG images will get distorted, but if you access the SVG
gradient directly and ask it to fill the CSS box then there is no problem
glazou: We already discussed whether to have gradients in CSS in the past.
We were supposed to discuss the syntax of them today
* sylvaing thought we had agreed to have gradients in CSS
* hyatt thought we had too
Steve: I asked why we were defining CSS syntax for gradients
Steve: The answer was that we wanted something simpler to use in the
most common cases.
Steve: I would like to have the document updated to show the SVG so I
can see the syntax.
Glazou: To do that we need to harmonize hyatt and Tab's proposals
hyatt: That's easy. I like Tab's proposal.
hyatt: I like splitting the single gradient() into linear-gradient()
and radial-gradient()
hyatt: instead of switching argument syntax based on the first argument
<hyatt> tab's proposal needs to deal with background-repeat
<hyatt> seems to not mention that
<hyatt> and we do need to talk about how the gradient is "tiled"
<hyatt> if we're doing what robert o'callahan proposed
glazou: So let's have a formal proposal in css3-images and then discuss
fantasai: Tab's proposal is practically spec-ready. Why do we need to
put off until another discussion?
hyatt: I liked roc's proposal to tile gradients by having them repeat,
rather than repeating rectangles of the gradient
...
Steve: I'm opposed until there are SVG equivalents in the draft so that
I can understand the claims that are being made
Sylvain: So you're not opposed to this being included, you just want
the draft clarified
Bert: I'm opposed either way
RESOLVED: add gradients to css3-images
ACTION: Tab add SVG equivalents to gradients proposal.
* Bert has half a dozen other CSS implementations, not even counting
the browsers, that haven't even finished CSS 2.1 yet. I want my
floats to work before I even think of gradients...
<sylvaing> Bert, the perfect should not be the enemy of the good
<Bert> exactly. Especially if the perfect is only usable by perfect
users (or: at least professionals)
<ChrisL> Tab, if you need a hand on the SVG equivalents, give me a
shout. i know a couple of things about SVG :)
<TabAtkins> ChrisL, shepazu: I'll get with both of you today.
<TabAtkins> My examples are already there in the draft, I just need
SVG equivalents for them.
<shepazu> looks like it should be easy
<TabAtkins> Then I need to generate some difficult examples. ^_^
* TabAtkins notes that he found it easier to write a moderate-level CSS
parser and image generator, than to make those examples in GIMP.
drop-shadows and Publishing css3-background
-------------------------------------------
<glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0100.html
* fantasai pastes the content of that email
==================================================================
It seems like there's a lot left to discuss with drop-shadows,
and given the cascading tangle we'll wind up with if we have
two properties that do drop-shadows, I think we should not
rush through this discussion.
However, the rest of css3-background is ready for Last Call,
and, given that we have multiple implementations already, I
think we should not let the shadow discussion hold us up on
the way to CR.
My proposal is to drop box-shadow from the css3-background
draft, publish a Last Call, and move forward with that module.
If we resolve the shadows discussion within the Last Call
period, we can reincorporate it into the draft and publish
another Last Call before pushing out to CR. If we don't wrap
up by then, then I think we should publish the CR and continue
to develop a cohesive solution for CSS shadows separately. If
necessary we can recombine shadows and the css3-background
module once CSS drop-shadows has also (independently) reached
the CR phase.
This way we can give CSS drop-shadows the time it deserves,
have a way for it to catch up with the rest of the draft, and
also not block the other css3-background features which
authors are very anxious to start using.
~fantasai
==================================================================
Tab: It does seem we have a lot of things to discuss and I'd like
to see what Brad's proposal can do
Hyatt: I think box-shadow is an important feature, and I don't want
to drop it from the draft
fantasai: I think it's more important for us to finish off the other features
in css3-background this year. We have 3 implementations ready
to go, we just need the draft in CR for them to drop prefixes and
interoperate
<hyatt> we had dropped the prefix from box-shadow already (in nightly builds)
<hyatt> guess it has to get put back!
fantasai: I'm fine with re-merging it back in once it's ready, but I
don't want to hold up the other features and I don't want
to cut off the box-shadow discussions prematurely
<dbaron> I'm happy with moving to LC without box-shadow for now.
Brad: Do we have a shadow module?
fantasai: we can create one
Brad: Then we can discuss how the different shadows interaction, e.g.
text-shadow
Tab: I'm for pulling it out
Daniel: I am too. Given the constraints, it's reasonable
Brad: I agree
Bert: I agree with Elika
Daniel: No objection?
RESOLVED: Drop box-shadow from css3-background: work on box-shadow outside
css3-background for the time being, possibly re-merge with draft
later
<Bert> It's sad. Rectangular box shadows I've wanted since CSS1. But
holding up the module for that one feature is not wise.
Resizing border-image when the box is too small
-----------------------------------------------
Brad: I'd like them to resize the same way
Brad: as border-radius
fantasai: I think the original intention was for each dimension to resize
independently, but I'm ok with changing
fantasai: Bert?
Bert: I haven't quite made up my mind. I do think they should resize the
same way as border-radius
fantasai: ok, that's all we need here; we can work out the text later
<sylvaing> No objection
Daniel: no objections?
<dbaron> I'd want to see what it actually gets resolved to.
RESOLVED: border-image resizes to small boxes the same way as border-radius
<bradk> they overlap, then their used values are proportionally reduced until
<bradk> they no longer overlap.
Extensions to the Mouse Events Interface
----------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Sep/0180.html
<dbaron> I like the way it works for border-radius, and I have no idea
what the rules for border-image are.
Doug sent an email on the extensions to the mouse interface
dbaron: Is there anyone one the CSS end that knows about this stuff?
dbaron: because Anne is not here
hyatt looks it over
hyatt: I think this is just formalizing things that everyone implements
Doug: Why are they being done here rather than in DOM3 Events?
hyatt: I don't know
hyatt: I think it'd be fine to specify in DOM3 Events
Doug reads off a description of location, specified in relation of box module
Doug: For SVG it'd be the bounding box
Doug: I'm editing DOM3 Events. I'm not sure if this should stay in
this draft or move over to DOM3 Events
Doug: I'd rather have them in DOM3 Events which is more general;
these would be useful in SVG as well
Sylvain: We're talking about cssom-view
Sylvian: A lot of that has to do with formalizing stuff to the CSS box model.
Sylvain: Would it really be useful in an SVG document?
Sylvain: do you really want to use these properties in SVG? They're legacy,
they're not extensions in a good sense, they're there to document
legacy interop behavior
Doug: I'll talk with SVG WG to see if we want these features
Sylvain: Not all these features will be useful in SVG
Sylvain: It would be nice if it was clean and you only had one dependency,
but...
Doug: Perhaps the best solution would be to define the relation of the
padding box in CSS and the bounding box in SVG
Doug: As for gradients, I didn't see anything you can't do in SVG. I'm
happy to help with examples.
Meeting closed.
Received on Thursday, 1 October 2009 01:05:02 UTC