W3C home > Mailing lists > Public > www-style@w3.org > November 2011

RE: [css3-images] closest side radial gradients

From: Brian Manthos <brianman@microsoft.com>
Date: Thu, 3 Nov 2011 19:32:09 +0000
To: Brad Kemper <brad.kemper@gmail.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D170444DE07@TK5EX14MBXC266.redmond.corp.microsoft.com>
"That you actually care about" ... might be true for you Brad, but it's not true for me and I suspect many other folks.

This is what I was referring to in my previous comment about the width property.

It's like saying we should disallow transparent for a border color because "clearly you don't want that".  How do YOU know what cases authors, artists, and "CSS animation movie makers" want to use?  Define what happens in the extreme cases clearly and people will use the facilities they want the way they want.  We do enough normalizing as it is.


Given a rectangle and a point within it (inclusive of the edges), "closest-side" on a given axis *means* the closest side on that axis NOT "the closest side + some filtering for stuff we think you don't mean".

If you want to propose closest-side-with-greater-than-zero-offset that's a whole different beast (and needs a prettier name).

-----Original Message-----
From: Brad Kemper [mailto:brad.kemper@gmail.com] 
Sent: Thursday, November 03, 2011 12:19 PM
To: Tab Atkins Jr.
Cc: Brian Manthos; www-style list
Subject: Re: [css3-images] closest side radial gradients



On Nov 3, 2011, at 10:48 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> Agreed completely with both points.  I understand where Brad's coming
> from, but I still think that the current spec definition is the most
> natural definition for the keyword's name.  

I just think we should pick a name that fits the most useful and least surprising value definition, and not the other way around. I further think that the name does not have to explain every nuance of the value, and that 'closest-side' is adequate enough. It does not have to be 'closest-side-that-you-actually-care-about-which-doesn't-give-absurd-results'. 

> I think we should look
> into adding more implicit-sizing keywords in the level 4 draft.

I don't. It is complex enough already. That just makes it more so. I want to ditch the not-so-useful-and-redundant meaning in favor of a more useful meaning. Whatever it is called. I don't think the fact that MS and you are in a hurry, or that MS has lots of code and tests that they would need to change should be reason to go with an inferior version that could still be fixed now in the spec.  
Received on Thursday, 3 November 2011 21:37:13 GMT

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