- From: Xaxio Brandish <xaxiobrandish@gmail.com>
- Date: Sat, 5 Mar 2011 23:53:13 -0800
- To: Sylvain Galineau <sylvaing@microsoft.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, Brian Manthos <brianman@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, Estelle Weyl <estelle@weyl.org>, "www-style@w3.org CSS" <www-style@w3.org>
- Message-ID: <AANLkTi=uA7cJr_wGie4sOFfwQh+bsjzwhxSQEDZMfVa0@mail.gmail.com>
Good evening, Let's not pick on somebody for using the term "surprising". Fantasai also used the term "surprised" earlier, and I do agree that's an accurate choice of wording. In everyday life, if one sees letters made of black construction paper suspended above a page, with a light source casting a shadow on that page, the color of the letter shadows does not change if the color of the construction paper changes. If the color of the shadows did change, I'd say it would be surprising. However, the digital display isn't and cannot always be modeled after such print media. Making the color a required component seems to make sense because only the author knows how their shadows should be displayed. *Unfortunately*, not all authors have a sense of where to start with shadows, and forcing them to specify a color/opacity for shadows would lead to quite a bit of trial-and-error before they figured out what seems correct to them. Having the UA default this seems like a reasonable way to avoid hassle. What makes sense for a default for on-screen rendering DEFINITELY may not make sense for projection media. The UA can provide a valuable starting point (default) for authors. Devices with limited color profiles may not be able to render author-specified preferences in much accuracy, which provides another case for defaulting the color to the UA. Unless the media for this property becomes more specific than "visual", I would vote for the UA to be able to provide a value for this color (and opacity!) if one is not explicitly specified. However, specifying currentColor does not seem like an interoperable default except among browsers, which is very limiting to other types of visual media. Although the group is trying to determine the specification [ by specifying things, nonetheless! ;) ], there are sometimes parts of the specification that need to be open enough to interpretation that they become *useful* parts of the specification. --Xaxio On Sat, Mar 5, 2011 at 10:41 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote: > It's been like this for quite some time and it wasn't 'surprising' until > you and others here heard of it. As far as I can tell from looking all over > including public bug databases, it has simply not been an issue. I wish all > 'surprising' behaviors were like this. > ________________________________________ > From: Brad Kemper [brad.kemper@gmail.com] > Sent: Saturday, March 05, 2011 10:55 AM > To: Sylvain Galineau > Cc: Brian Manthos; fantasai; Estelle Weyl; www-style@w3.org CSS > Subject: Re: [css3-background] Default shadow color > > On Mar 4, 2011, at 6:11 PM, Sylvain Galineau wrote: > > > I don't get how black is better than currentColor given that it is the > default color for text in most browsers; why pick a default that's will be > wrong the most often ? > > Black or translucent black would be wrong less often. Shadows that stayed > black when the author changes the text color to red would be less > surprising. Having the box shadow turn red just because you turn set the > color of the text to red would be totally surprising to almost anyone. > >
Received on Sunday, 6 March 2011 07:54:55 UTC