RE: [css-style-attr] SVG WG comments on CSS Styling Attributes Level 1

> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Håkon Wium Lie


> I think this is the right approach. The feature is, as you say, little
> used and only provides convenience -- not necessity. I don't know why
> e-notation was allowed in numeric values on SVG attributes in the
> first place, but it seems better to deprecate them there than to
> mandate e-notation across the board.

Harmonization one way or the other is the right approach as long as the 
rationale is sound.

> Introducing e-notation in CSS would have a considerable cost. We would
> need to change the CSS core grammar, which is -- sort of -- our
> constitution. Constitutions can be changed, but only for truly
> important things, when there is long-standing consensus. 

Dramatic analogies can only get you so far.

Constitutions are also old, calcified documents overseen by small groups 
of - mostly - old men appointed for life; they are often behind reality, 
incomplete, limited and get changed extremely slowly at great cost when 
the gaps are unsustainable. 

While some people might find this description to be a disturbingly accurate 
reflection of the CSSWG and the pace of its work, I would not consider it to 
be a desirable goal nor, if I thought it were true, would I consider it a feature :)

> The convenience that e-notation provides to some counts on the plus side,
> but on the minus side we find incompatibility with existing browsers
> and reduction of human readability. 

No incompatibility occurs until the feature is used which, as explained, involves 
new features like transforms which are already not supported in all browsers. 
Thus, in practice, the real incompatibility will lie elsewhere.

I don't buy the human readability argument. This notation is extremely common
in the scripting and programming languages in common use by web authors.
There is no reason to suppose it is any more or less readable in CSS than it
is in Javascript, Python or Perl.


This has always been an important
> design principle in CSS:
> 
>   CSS is a simple style language which is human readable and writable.
> 
>   http://www.w3.org/TR/CSS2/intro.html#design-principles

The Python, Perl and Javascript programmers I know are all human. Python
programmers who don't know Perl are perfectly capable of identifying number
literals in Perl programs and vice-versa.
 
> Further, the design principle states:
> 
>   The CSS properties are kept independent of each other to the largest
>   extent possible and there is generally only one way to achieve a
>   certain effect.
> 
> Introducing e-notation is against this principle, as it offers no new
> functionality, only a different syntax for achieving the same thing.

This is a red herring. This is not a property addition but a new literal 
notation. You might as well argue that since inches and centimeters can 
be used to represent the same lengths we should keep only one. What do
centimeters offer that cannot be expressed in inches, or millimeters or 
picas?

As it happens CSS also supports mm, pt, pc and the px as 1/96". Supporting
two ways to represent floating point numbers is no different.

>  > > You call it an artifact.  I call it a ubiquitous, living notation
>  > > embraced by all the programming languages people are using today.
> 
> You're right, it's common in programming languages. But CSS was
> explicitly designed to *not* be a programming language. The last words
> in the CSS1 Recommendations are:
> 
>   We do not expect CSS to evolve into a programming language
> 
>   http://www.w3.org/TR/REC-CSS1-961217

This is a very specious argument. Adding the e notation does not turn CSS 
into a programming language anymore than removing it from Python would make 
the latter declarative. The spec does *not* say: "We do not expect CSS to 
*look* like a programming language", Håkon. If that was true then surely 
declaration blocks should not use {} as delimiters as these look very 
familiar to even C programmers. Never mind the functional notation, semi-colon 
delimiters, quoted string values, comma-separated enumerations etc.
 
> 
> The main competitor to CSS in the early days was DSSSL, which *was* a
> programming language. I believe that one reason for the success of CSS
> is its lack of features from programming languages:

Same implicit claim that adding support for a widespread literal number 
syntax creates programming capabilities that are conveniently left entirely
unexplained. Could you elaborate on the programming I can do using
this notation ? Since IE has supported it for more than a decade, isn't it
curious it has not been exploited for programming purposes yet ?
 
If you want to make this argument, I strongly suggest you focus your
attention on calc(). That is the proper place for your anti-programming 
crusade. On this specific issue, it sounds rather preposterous.

And I will note that it would in fact be very easy to argue than the syntax 
of CSS is easy to learn *because* it looks familiar and conventional to even 
the occasional programmer.

> 
>   Compared to DSSSL-Lite, CSS was easier to support since it wasn't
>   Turing-complete and didn't require a transformation step. So, in a
>   way, it was the simplicity -- the lack of features -- that won people
>   over.
> 
>   http://friendlybit.com/css/interview-why-did-css-succeed/
> 
> Other features from programming languages can also be said to be
> ubiquitous, e.g. regular expressions. In 1998 there was a big debate
> about introducing regular expressions in CSS selectors. The debate is
> worth recounting, both for its entertainment value and for its
> arguments. Some key messages:
> 
>   http://lists.w3.org/Archives/Public/www-style/1998Mar/0048.html
>   http://lists.w3.org/Archives/Public/www-style/1998Mar/0032.html
>   http://lists.w3.org/Archives/Public/www-style/1998Mar/0051.html
> 


I fail to see the relevance or soundness of this argument. The implicit
claim here seems to be that 'regex is a feature in some programming 
languages, regex did not make it into CSS therefore anything that looks 
like a programming language feature will not be supported in CSS'. This 
is not just absurdly simplistic and circular, calc() proves it's already
 wrong in practice.


I am in support of the feature. I do not think it is critical; it's a convenience.
But claims of its 'great cost' seem hugely exaggerated and superficial.

Received on Monday, 30 August 2010 23:11:15 UTC