Re: [css3-*] Review of functional syntax in CSS

I am all for making CSS syntax as similar to JS as possible - as the CSS features become more powerful and complex to express it simply makes sense to borrow the syntax from a more powerful sibling web technology.

As for the prefix pattern whereby authors are dropping a no-prefix property at the end of the list: I'm guilty of it whenever I use any prefixed property. The idea is to be forward compatible otherwise when a spec goes final and vendors remove support for the prefixed version website's *appear* to break.

Arguably that's an author's problem for using incomplete properties in production environments instead of for personal projects - but that's what happens because it's the fancy new stuff which sells and make's client's happy, so it's the fancy new stuff that get's used as soon as it's practical to do so. 

I'd suggest that the only way to avoid this kind of problem is to get browser vendors to disable all experimental vendor-specific prefixes unless the user has opted in through a preference or special build. The problem there is it's not in the vendor's interest to do this because it is the fact that Safari and Chrome can do fancy stuff that pushes their share of the market up. It's certainly one reason I like Chrome/Safari - I love those hardware accelerated 3D Transforms, they make clients drool and developers lust.

-Matt

On 20 Jan 2012, at 18:55, Aryeh Gregor wrote:

> On Thu, Jan 19, 2012 at 9:01 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> General Principles
>> ==================
>> 
>> 1. Functions group/namespace a set of CSS-like values, and so should
>> abide by general CSS value syntax principles
>>  1.1 Optionality is handled per #3, as far as possible
>>  1.2 Ordering should be flexible as much as possible/prudent
>> 2. Lists of parallel items are comma-separated
>> 3. Lowest operator is comma
>> 4. Backwards compat should be preserved unless there's a very good
>> reason otherwise
> 
> I think this misses two noteworthy points:
> 
> a) Functions look like programming-language functions, which always
> have a comma between arguments.  Allowing multiple arguments with no
> comma will be confusing to anyone with even slight scripting
> experience, and *requiring* no comma will be even more confusing.
> 
> b) If all functions require a comma between arguments, it's easy to
> remember.  If some functions require it and some forbid it, it will be
> very hard to remember which is which unless the choice is very
> consistently applied.
> 
> I think requiring commas between all arguments always, like
> programming-language functions, is the most natural and simplest for
> authors to understand.  Most people who do a decent amount of CSS work
> have at least some exposure to JS, and having the function syntax look
> similar strikes me as very valuable.  I think the syntax should be
> made more analogous to JS functions than to CSS property values --
> which it already is, by and large.
> 
> On Fri, Jan 20, 2012 at 3:51 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> Are the proposed comma removals backwards-compatible in the sense that
>> prefixed properties would work with extra commas if unprefixed? (It
>> seems to me that wouldn't be the case.) Without that kind of
>> compatibility with what's deployed, I expected it to be very confusing
>> to authors if dropping prefixes needs to be couples with dropping
>> well-selected commas, too.
> 
> Particularly since it's common to see authors using unprefixed
> properties before any browser actually implements them, like
> 
>  -ms-transform: translate(10px, 10px);
>  -moz-transform: translate(10px, 10px);
>  -webkit-transform: translate(10px, 10px);
>  -o-transform: translate(10px, 10px);
>  transform: translate(10px, 10px);
> 
> Mozilla, for one, seems to systematically advocate this pattern.  I've
> certainly seen it in the wild, and I haven't even looked.  The
> advantage is that if there's no change in syntax when unprefixing,
> things will continue to just work.  But if there is, things will
> break.  The same goes for if authors copy-paste the existing lines and
> remove the prefix -- it will work fine as long as the syntax hasn't
> changed.
> 
> I don't mean to bring up the whole prefixing argument again, but I'll
> observe that even if you like prefixing, that doesn't mean there are
> no compatibility constraints on property syntax until we unprefix.
> They just aren't quite as strong.  We can change the syntax when
> unprefixing without actually breaking many sites, as long as browsers
> still support the prefixed syntax for long enough that authors switch
> over.  But the transition is still easiest if we don't change the
> syntax at all.  Even though we *could* change it, we *shouldn't*
> without good reason.
> 
> For things like matrix3d() or Bezier curves, where it's really hard to
> read if there's a comma between each pair of entries, it might be
> worth it -- although who's really writing these by hand, and why can't
> they make grouping clear with whitespace?  I definitely don't see the
> value in not requiring commas for translate() and such.  I think it's
> more confusing than anything.
>

Received on Friday, 20 January 2012 19:10:24 UTC