> 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.