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

On Aug 29, 2010, at 6:13 AM, Håkon Wium Lie wrote:

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

Even deprecated, it would still be mandated for SVG-supporting UAs UAs to support it. And it would still be present in JavaScript (ECMAScript). Right?

> important things, when there is long-standing consensus. The
> convenience that e-notation provides to some counts on the plus side,
> but on the minus side we find incompatibility with existing browsers

That's the biggest problem isn't it? Yet not so big. We already have things (properties, @rules, values) that cannot be used reliably on the Web until the most used versions of Web browsers support them. I no longer test my pages for how they look in Netscape 4, and soon (oh, please, soon) I will no longer care about IE6 either.

> and reduction of human readability. 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

I agree with this principle wholeheartedly, and it helps me sympathize with your point of view. Personally, all other things being equal, I would prefer the caret notation for really large or really small numbers for that reason, instead of the TI calculator look. But really, I find e-notation readable enough, and compact, for the few situations where I am likely to come across it (and I am the type of hand-coding non-engineer author that readability should matter to). And it's better than caret notation for the purposes of cross-compatibility with other languages.

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

I disagree that this applies to this situation. We are not talking about introducing a new property or @rule. It is really no worse than any of the following rules being equivalent:

{ width: 1in; }
{ width: 01in; }
{ width: 1.0in; }
{ width: 01.00in;  /* etc.) */ }
{ font-size:1in; width: 1em; }
{ width: 2.54cm; }
{ width: 2.54mm; }
{ width: 2.5400mm;  /* etc.) */  }
{ width: calc(0 + 1in); }
{ width: calc(0.5in + .500in); }
{ width: calc(12.7mm + 0.5in); }

I could go on and on...

> Tab writes:
> 
>>> 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. 

True, but JavaScript/ECMAScript is, and commonly needs to calculate and pass CSS values back and forth, which is a very strong argument for allowing e-notation in CSS, IMO.

Received on Sunday, 29 August 2010 14:28:13 UTC