-
201110 Nov
Posted in W3C
This is cross-posted from the CSSWG Blog.
At the CSSWG F2F last week, I raised the issue that the radial gradients we were discussing were unreadable to me, and probably therefore to much of the intended audience. It was not at all obvious by looking at the gradient syntax what the various numbers and lengths might be.
radial-gradient(60% 43%, 25px 25px, #b03 99%, transparent)
So Tab Atkins, David Baron, Brad Kemper, Brian Manthos and I hashed out an alternative syntax.
radial-gradient(circle to 25px at 60% 43%, #b03 99%, transparent)
We’d like your opinion on which is preferred and why.
Examples Current WD Current ED radial-gradient(white, black)radial-gradient(white, black)radial-gradient(farthest-corner ellipse, center, white, black)radial-gradient(ellipse to farthest-corner at center, white, black)radial-gradient(top left, white, black)radial-gradient(at top left, white, black)radial-gradient(top left, farthest-corner ellipse, white, black)radial-gradient(ellipse at top left to farthest-corner, white, black)radial-gradient(circle, white, black)radial-gradient(circle, white, black)radial-gradient(circle, center, white, black)radial-gradient(circle at center, white, black)radial-gradient(center, 5em 5em, white, black)radial-gradient(to 5em, white, black)radial-gradient(center, 5em 5em, white, black)radial-gradient(circle to 5em at center, white, black)radial-gradient(75% 75%, closest-side circle, white, black)radial-gradient(circle at 75% 75% to closest-side, white, black)radial-gradient(25% 2em, 15px 30%, white, black)radial-gradient(ellipse to 15px 30% at 25% 2em, white, black)The generic forms are (very roughly speaking):
General Syntax Current WD Current ED radial-gradient(position, [size || shape], color-stops)radial-gradient(shape [to size || at position], color-stops)Shape/size and position are optional, unless the shape/size is given with explicit lengths, in which case the position must also be specified Each of shape, size, and position are optional. The size and shape clauses can be reordered. As a side effect, the keyword-based syntax more easily allows us to add other capabilities in the future. For example, offset radials could be expressed using a
from positionclause for the color origin.So, which is better or easier to read, the current WD syntax or the current ED syntax (and why)?
You can skip to the end and leave a response.
-
Comments
-
01.
I don’t see a world of difference between the two so I wouldn’t complain if the syntax were changed – but then, I don’t see any really clear advantage in the ED syntax. I’ve been using the WD syntax for a while now and it feels perfectly understandable to me – no harder to read than any other property value.
If anything, the almost natural language of the ED feels different to the rest of the CSS syntax, and somewhat out of place.
But as I said, no really strong opinion either way.
-
02.
A Fontcuberta says:Comment » November 11th, 2011 at 12:49 am
+1. The syntax should follow the ‘standard’ used in others values and properties. I’m feeling more comfortable with WD syntax too.
-
03.
We don’t generally use commas to separate values in other values and properties, except when it’s a list of the same type of item.
-
04.
I prefer the second one. It’s much clearer. But I would prefer to invert “at” and “to”:
radial-gradient(circle from center to top left, …)
radial-gradeint(ellipse from top left to farthest-corner, …) -
05.
There is not a large difference between the two, but I am inclined to agree that ED will lend itself more readily to new capabilities.
I’m a big proponent of both human readability and verbosity, ED is my choice.
-
06.
I prefer the WD syntax. The second one involves more typing, and those “at” and “to” look verbose to me.
-
07.
-
08.
staaky says:Comment » November 11th, 2011 at 2:53 am
“circle to 25px” doesn’t read as an indicator of size, “25px circle” would be better but having size in front of shape doesn’t work nice with implicit sizes. Language doesn’t seem like the best choice here.
-
09.
Wow way to turn
background: #1e5799; /* Old browsers */
background: -moz-radial-gradient(center, ellipse cover, #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(radial, center center, 0px, center center, 100%, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 12+ */
background: -ms-radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */INTO
background: #1e5799; /* Old browsers */
background: -moz-radial-gradient(center, ellipse cover, #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(radial, center center, 0px, center center, 100%, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 12+ */
background: -ms-radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: radial-gradient(center, ellipse cover, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
background: -moz-radial-gradient(/* new syntax……………*/);
background: -webkit-gradient(/* new syntax*/);
background: -webkit-radial-gradient(/* new syntax……………*/);
background: -o-radial-gradient(/* new syntax……………*/);
background: -ms-radial-gradient(/* new syntax……………*/);
background: radial-gradient(/* new syntax……………*/); -
10.
-
11.
I’m partial to the implementation; startX, startY, startRadius, endX, endY, endRadius.
Which could be expanded to work in CSS with;
radial-gradient(x1 y1, radius1, color1, x2 y2, radius2, color2, … );
This example would create a radial-gradient from the center of the bbox (black), to the farthest-corner of the bbox (white);
radial-gradient(center center, 0px, #000, center center, farthest-corner, #FFF);
This is the most verbose option… it would be simply;
x y, radius, color… repeat…
I’m all for some shortcuts though…
* Inputting only colors (creating a rainbow);
radial-gradient(red, yellow, green, teal, blue, purple, pink, red);
color… repeat…
* Inputting radius’s and colors (creating a gradient that is 70% blue);
radial-gradient(0%, red, 10%, green, 30%, blue);
radius, color… repeat…
* Mixing in some container terminology;
radial-gradient(contain, red, closest-corner, green, cover, blue);
The above options would be both easy to program, and easy to read…
-
12.
That was supposed to read Canvas option, but it seems this form doesn’t replace html_entities with > and so forth, so it was parsed out. Anyways, here’s a link to the canvas context createRadialGradient;
http://www.w3.org/TR/2011/WD-2dcontext-20110405/#dom-context-2d-createradialgradient
-
13.
With all the gradients syntax, be it radial or linear one.
It is quite tricky to get a hold on the syntax.I prefer the proposed syntax, to make it more readable to every out there. I think designer prefer to stick to generators, if not that much readable.
-
14.
I say stick with WD. It reads cleanly to anyone who’s used enough CSS(2/3) to understand properties and values. If you know what you’re doing it’s like when you do “border: top right bottom left” I’m CERTAIN everyone almost says it as they type those values… it’s going to be the same, and this is less verbose, and gives any true developer all the readability you need.
I say this because like others have said, the concept is the same, it’s all learned anyways, just stick to non-verbose option that appeals to developers not Johnny-drag-and-drop!
-
15.
I don’t feel tied to one or the other, really. The flexibility of the ED version to allow for new syntaxes is great, but it is more verbose and not necessarily all that improved in terms of legibility (IMHO). Frankly, regardless of the final syntax, I’m likely to use a generator to create the initial gradient and then tweak the values from there. I don’t know that I will be using tools like this frequently enough to devote precious head-space for memorizing the syntax. But maybe that’s just me.
-
16.
Well, I have no clue what “circle to 5em at center” means. I read the “to 5em” as “move to 5em”, but I guess it’s not that, and a different action verb is implied? Maybe “expand”? So, “expand to 5em” makes sense, but then “expand [to …] at center” doesn’t. Urgh, my brain hurts. Maybe we need and other verb? And some nouns. Could it be “expand to 5em and align the gradient’s center on the element’s center”?
Arguments against the natural language approach:
– Not consistent with basically everything else in CSS, including the linear-gradient syntax.
– Half-baked attempts at natural language are not that natural or intuitive. You have no action verbs in the proposed syntax, no nouns, and prepositions like “to” and “at” have dozens of meanings depending on context. Ouch.
– What about non-native speakers? The vast majority of Web authors have limited command of the English language and I’m not sure the ED version does them any good.Other than that, I like the position→size order in the WD syntax; size→position feels wrong. Not sure why. Maybe because I always write position properties before width/height properties in CSS declaration blocks.
-
17.
I prefer the WD syntax but I actually like Michael Deal’s suggestion best. Having all the initial values followed by the ending values makes more sense to me. It seems more like how you would say it out loud if you were trying to tell someone how to draw what you wanted.
-
18.
As lots of others have said, the two are equally inscrutable. Adding the extra words doesn’t add anything, and is therefore a bad idea IMHO.
I agree that Michael Deal’s idea makes more sense, as a list of tuples, grouping the properties together logically. The difference between circular and elliptical is simply whether the radius X and Y are equal or not, which is simple, so I’d suggest a shorthand where only a single radius dimension implies circular, but two are elliptical.
Love the idea of the shorthand of just listing colors and it assuming equal spacing, surely this is the one of the most common use-cases?
-
19.
I agree that the new functions introduced in css3 are unreadable, but I do not think that this approach is the solution. It only addresses a single function. Instead a change should be made that allows for generic keyword style argument passing to all functions with function-specific parser semantics. In Sass we have implemented keyword style argument passing for all functions and mixins to allow css authors the flexibility to create more readable code if that is important to them.
So a generic solution would look more like: radial-gradient(shape: circle, length: 25px, position: center, color-stops: (#c00 20%, #0c0 80%))
Such a syntax is order independent and clearer to a reader what each argument means.
I would really like to see the CSSWG start to address these kinds of issues more systematically instead of as one-offs.
-
20.
Sorry I meant “to all functions without needing function-specific parser semantics”
-
21.
Why would we – the non-english-speaking-part-of-the-internet – want to bind CSS styles to american grammar? There’s no benefit (other than american linguistics)…
-
22.
-
23.
I’m with Michael Deal’s comment. I love CSS3, but a lot of the new stuff seems more difficult for humans to read/write than it needs to be.
Make the syntax as human read-/write-able as possible.
-
24.
Two grammatical feel the same, but some new function a bit let css3 is hard to understand
-
25.
I yet to find any difference between Standard vs Transparent, therefor I think its the same as ASP has several ways of doing the same, if it helps browsing faster, thats the main key.
-
26.
I don’t think English-specific syntax is a good idea. I’d go with the WD version.
-
27.
@Chris Eppstein We actually are attempting to address this across CSS3: the intention is to shift towards treating the contents of a functional notation as a subset of the normal CSS property value syntax, which will give us more flexibility in defining arguments, especially optional ones. The problem with gradients is that, like the ‘background’ shorthand, they have too many arguments that parse as the same type. To handle that we need some way of disambiguating.
@MicroAngelo You can already do the colors-only shorthand –that’s available in both the WD and ED syntaxes.
-
28.
I agree that, for this property, the myriad values which can/need to be specified do make it very unreadable. But reading the code more like natural language just somehow seems wrong to me. The way CSS is written it makes it very easy to quickly see what element has which value. When looking at the ED syntaxes I feel like I have to read through the whole thing to find what I want.
I would agree with Chris Eppstein’s suggestion of using the more standard, colon-separated property-value syntax. This syntax would allow the values to be in any order and thus make it much more readable and bring the syntax in line with the rest of CSS.
-
29.
I definitely think that the ED syntax is much more human readable. However, I think that things are still a little unclear in meaning. Example:
radial-gradient(circle to 25px at 60% 43%, #b03 99%, transparent)
circle: obvious
to 25px: to what? not clear what this value means. why not just make this “size”?
at 60% 43%: at what? why not “position” I know it is longer, but makes sense to humansThoughts? Maybe I am being too picky.
-
30.
-
31.
-
32.
-
33.
The ED version *looks* like it should be easier to use, but in fact both WD and ED are equally confusing (to me, anyway). Michael’s suggestion above looks more orderly to me, so I second that.
I am curious what happens if you assign two such gradients to a single element; I assume they will overlap / merge. -
34.
Grant says:Comment » January 15th, 2012 at 11:41 pm
I like the original, seems to be closer to what existing style definitions look like.
-
35.
The alternative syntax definitely makes more sense from a semantic, easy-to-understand writeup viewpoint. But to satisfy the space-saver coders, what about offering essentially both (with a shorter syntax recognized that eliminates or condenses the “Circle to” verbage)?
-
36.
-
37.
-
38.
-
39.
-
01.
