W3C home > Mailing lists > Public > public-webplatform@w3.org > July 2013

Re: CSS values and units

From: Lea Verou <lea@w3.org>
Date: Tue, 30 Jul 2013 23:11:57 +0300
Cc: Eliezer Bernart <eliezerbernart@gmail.com>, "public-webplatform@w3.org" <public-webplatform@w3.org>
Message-Id: <B427D346-C03F-4363-99FD-51FF4CF70980@w3.org>
To: PhistucK <phistuck@gmail.com>
On Jul 30, 2013, at 23:03, PhistucK <phistuck@gmail.com> wrote:
> - By css/values/[type] do you mean css/values/px (for example)? I do think the category is needed (length), especially since you use this category in the syntax of the properties.
No, px is a unit. Of course we should have a page for <length>.

> Alternatively, perhaps a css/values could be a listing page that shows the category and when (as suggested in some other thread)
Of course, just like we currently have a css/data_types listing page.

> linking from the <length> in the syntax, you could use the anchor of the category from the listing page. But I still think css/value/length/px is better, because it has more immediate visibility beside going to css/values and beside skimming the page for the category to which the type belongs.
What is there to include in a page about px? I don't think it makes sense to have separate pages with just a paragraph of text.

> - This seems a bit problematic. While I do support removing the notations path, I think it is problematic for those functions to reside only under css/functions. For example, calc is a special function. It should be in both of the paths (css/functions and css/values/length), since it actually serves as a length value and can be used everywhere. However, if you do that and you also have an image type, should linear-gradient and friends be there as well?
How is calc() special? Every function accepts certain parameters and returns a certain data type. calc() returns lengths or percentages, linear-gradient() and friends return <image>, attr() could return *any* type. I don't think it's sensible to include them in the pages of their return types, especially since attr() should be included everywhere in that case.

> - css/values/color/color_by... should probably be css/values/color/hsl (and similar). A more elaborated representation ("color by hue") should be in a css/concepts level and not in the reference page. Also, these are also functions, so... yeah.
Color is a data type. There are also several functions that return colors. Not sure where the confusion lies.
I stand by my argument that hsl() should be under css/functions and that we shouldn't nest more deeply than css/values/[something]. 

Received on Tuesday, 30 July 2013 20:14:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:52 UTC