- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 04 Feb 2009 16:47:13 -0800
- To: www-style@w3.org
Summary:
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 =====
Attendees:
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
http://www.w3.org/Style/CSS/Tracker/issues/84
<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
http://lists.w3.org/Archives/Public/www-style/2009Jan/0225.html
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.
Selectors
---------
Selectors:
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
definition
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