[CSSWG] Minutes and Resolutions 2009-02-04


   RESOLVED: box-shadow is not suppressed by border-image
   RATIONALE: It's useful in many cases, and the author can suppress
              it himself as needed.

   RESOLVED: Remove background-clip: content-box
   RATIONALE: content-box is not useful as a clipping rectangle, only
              useful as a positioning rectangle

   RESOLVED: Accept to add new type notation <image> to css3-values
   RATIONALE: Makes future additions like gradients easy to spec

   RESOLVED: Drop ::selection from Selectors Level 3
   RATIONALE: Vastly underspecified, implementations not interoperable.

   POSTPONED: Discussion of margins at page breaks postponed to Tokyo F2F

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


   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Dean Jackson
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Steve Zilles

<RRSAgent> See http://www.w3.org/2009/02/04-css-irc

Scribe: Steve Zilles

Discussion of issue 84 deferred for lack of place to put a solution
   <fantasai> (also deferred because it's not a high-priority item)
Discussion of duplication and @font-face deferred so jdagget can participate
Discussion of spec names closed - have a previous resolution, no need to revisit

CSS3 Backgrounds and Borders

   Issue 85 Box Shadow
   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/85
   Daniel: Question is, do we want border-image to suppress box-shadow.
   Bert: the other option is the box shadow follows the edge of the
         object; the outline
   ChrisL: that does not work well if the edge is semi-transparent
           making an edge defn difficult
   Do we want border image to surpress box shadow because it is too
      difficult to handle, being non rectangular and possibly lacking
      a hard edge
   <ChrisL> you could do a shadow by taking the alpha channel, blur,
            offset, and paint in the shadow colour
   ChrisL: can take it the alpha channel and paints it in with a blur
   Dean: the underlying services does this for us so it is not impossible
   Daniel: can we keep box shadow and identify it at risk
   ChrisL: Or, can we document what webkit does and suggest that as the
           possible solution and see if people sign up for it
   <ChrisL> I would like to see some test cases on this feature
   Fantasai: With both a dashed border and a border image, the dashed
             border ignored and only the border image is painted
   Fantasai: the shadow is just painted on the "edges" of the border box
   <sylvaing> so it always shadows the box, not the border
   Howcome: If the inset keyword is given the shadow is painting inside
            the box (border or padding)
   Fantasai: If you have a zig-zag border like that in the spec, then
             the box shadow is no placed in the useful place
   ChrisL: putting the shadow in the image (for the border image) does
           not work because the shadow is on a different side for
           different borders
   Fantasai: Making box shadow do more than rectangles is pushing the
             current property too much; if you want the full shadow
             effect, this should be done with a new property
   Many: It does not seem that border image should surpress box shadow
         because the user can always explicitly turn off box shadow if
         that is needed
   ChrisL: to HL please make you test cases available
   Howcome: inside shadows are really cool
   RESOLVED: Box Shadow is not surpressed by Border image
   We need to document with Webkit is currently doing and develop test
   case to show the effects desired

   Issue 86 background-clip: content-box
   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/86
   Fantasai: there is a content-box option on both background origin
             and background-clip
   Fantasai: The content box option is not useful for the background-clip
             so it should be removed
   Fantasai: It almost always looks too tight against the content, and
             if you have a quality font the letters will often leak
             outside the box
   Fantasai: So I propose removing content-box
   Fantasai: and having content-box in the background shorthand only
             set background-origin, leaving background-clip to its
             initial value
   <sylvaing> arronei says: only cool use would be for testcases.
   Peter: People want clipping to the content box to prevent clicking
          on other than the content
   Fantasai: This is typically done with non-repeating images and there
             are other, better ways to handle this
   Fantasai: For clipping you usually want a region around the content
             box rather than the exact content box
   Peter: Is the problem you describe just an issue with the shorthand
   Howcome: I agree with Fantasai
   Howcome: if we can remove something we should
   <Bert> I also agee with Fantasai, i.e., no need for bg-clip: content-box.
   Peter: the implementation cost is trivial and I predict that people
          will find use cases for this
   SteveZ: One should be careful with removing things because one can
           because the users may see consistency between the set of
           options that the implementer does not
   <anne> +1 to removing dubious features
   Fantasai: The main reason that I would like it removed is that it
             makes the shorthand less useful
   Fantasai: The vastly more common case (content-box origin with border
             or padding clipping) should be easy to specify.
   Arron: It would be very useful for verify test cases
   Arron: But I don't see any other use
   Remove: Arron, Fantasai, Howcome, Sylvain, Anne
   Abstain: SteveZ, ChrisL, Dean
   Keep: Peter, Daniel
   RESOLVED: Remove the content box option on background-clip

New <image> notation for value types

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Jan/0225.html
   Fantasai: It is simpler to say that any property that takes an
             <image> can take a gradient
   <ChrisL> So, this proposal is effectively a paint server?
   Fantasai: it is a notation for anything that defines a 2D graphical
             drawing, with or without intrinsic dimensions
   Dean: Webkit can also drop references to Canvas as well
   Dean: WebKit effectively has an <image> type in such properties
         (eg. gradients and canvas-images in backgrounds)
   RESOLVED: accept <image> proposal
   ACTION håkon: implement proposal for <image> type

Follow-up on margins at page and column breaks

   Steve summarizes his points on www-style
   Steve: I think we can resolve 2.1 now
   Previous tenative resolution: Accept Melinda's proposed CSS2.1
     wording to allow margins to be kept after a forced page break
     for CSS2.1 Issue 98
   Steve: Should this be on page-break-before only, or on both?
   Howcome: It's random whether I use before or after. It depends on
            what markup hooks are available.
   Steve: If you're putting in the margin, then you have the hook
   Howcome: Still, I'm not comfortable with attaching too much
            semantics to the difference
   <Bert> (I think I would like to be able to say 'page-break-after:
          chapter-start-page' to force the next page to be a named
          page with a big margin...)
   Proposed to defer discussion to Tokyo
   Steve suggests we get implementators' feedback

<dino> Here is a box-shadow on border-image (and other stuff)
         test: http://pastie.org/379633
<glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JanMar/0051.html
<dino> WebKit does follow border-radius for box-shadow, but not
         on border-image at the moment.


   Fantasai: 1. drop ::selection from Selectors level 3
   2. otherwise drop outlines form the set of properties
   Daniel: ::selection was introduced to allow enough contrast be
           introduceable for accessibility
   Daniel: I known a person that is color blind in the blue area
           which makes the most common selection feedback invisible
           to him
   Fantasai: Changing the default color of selection shouldn't have
             to be done in CSS, it could be done as a UA pref
   Fantasai: requiring a stylesheet to fix this problem is way too
             difficult for many users to solve there problem; it is
             better to have the UA give support for fixing the problem
   Sylvain: OSes usually have settings for these things as well
   <anne> I agree that keeping ::selection might be more trouble than it's worth
   <ChrisL> http://www.w3.org/Graphics/atypical-color-response.htm8
   Daniel: It is not difficult to implement; it could be useful to some
           designers; I do not see the point in removing it
   * anne has to run
   Fantasai: I agree that it's a useful feature and that we should have
             it in CSS, but not in Selectors Level 3.
   Fantasai: The main reason is that the implementations are inconsistent
             at this point and solving the inconsitencies would involve
             more specification than we can do now
   ?: Is it inconsistent enough that users would be surprised by the results?
   Fantasai: Yes.
   Daniel: It would be easy to implement your option 2 so I think that
           would be a better soulution.
   ChrisL: is the implementation of this going to hold up CR?
   Fantasai: it will hold up CR because the current, multiple implementations
             are sufficiently different that we need to nail down a better
   Many: Let's mark this feature at risk and see if we can nail down a
         definition and develop testcases
   Bert: Lets not add a definition that is only for now and we would have
         to change later; let's get Selectors 3 out the door
   RESOLVED: ::selection Selector is removed from Selectors 3

<fantasai> http://wiki.csswg.org/planning/tokyo-2009
<RRSAgent> I have made the request to generate http://www.w3.org/2009/02/04-css-minutes.html szilles

Received on Thursday, 5 February 2009 00:47:53 UTC