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

[CSSWG] Minutes and Resolutions 2009-09-30

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 30 Sep 2009 18:04:25 -0700
Message-ID: <4AC40019.9090206@inkedblade.net>
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 GMT

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