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

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 18:56:20 UTC