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

Dear 
Håkon,

--Original Message--:
>Also sprach Chris Lilley:
>
> > >> Looking back in time by reading the source code of Unix
> > >> edition 7 which dates back _a long time_ (the '70s) I see that the
> > >> 'C' function 'scanf' can handle parsing scientific notation.
> > 
> > Indeed, lex allows scientific notation (as the original comment
> > from SVG notes). CSS however uses a modified lex grammar which does
> > not allow scientific notation.
>
>A better term for the notation in question may be "e notation".
>
>  http://en.wikipedia.org/wiki/Scientific_notation#E_notation
>
>This notation is an artefact from limited i/o capabilities of
>calculators and computers. It looks quite differnet from classic
>scientific notation, though.

Yes, a good point, thanks for the clarification in terminology.
The reference is also great reading indicating that perl
and python both natively support e notation.

><snip/>
>
>I hope no UA starts accepting the e-notation in CSS unless it -- over
>my body -- ends up in a W3C Recommentation. For example, I don't want
>to see this in style sheet:
>
>  h1 { font-size: 2.6e-4em }
>
>It's a feature we don't need, one that will cause harm in terms of
>human legibility.

I see your point of view from a hand authoring point of view.

My point of view is that more humans read the rendered result of
a web page compared to the number of humans that hand
author them.

You my friend are blessed with a high IQ and so should easily
parse the e notation.

For the rest of us dummies, we rely on a machine to generate
the content automatically from a database or whatever the 
poor programmer has to deal with.

For example, the 'C' code:
--
main()
{
	double f;

	f = 1.0;
	f /= 100000000;
	printf("h1 { font-size: %gem }", f);
}
--
when compiled produces the output (using GCC) of:
--
h1 { font-size: 1e-08em }
--

So the tools available for automated CSS generation using
programming languages such as 'C'/C++, perl, python etc.
will produce equivalent output.

To err is human, to really screw things up you need a computer.

>If we need very small numbers in some properties, I'm sure there are
>better solutions.

I would gladly review your suggestions of alternate solutions
as I'm sure many in the automated content development community
would as well. Please feel free to suggest any suitable ideas
that will make this a simpler task and more human readable.

><snip/>
>
>The most unfriendly part of this debate seems to be your summary. And
>that's saddens me; I thought we had a very good meeting.

I'm sorry to hear that there were some negative feelings produced
from the discussions both verbal and in email, and I'm sure
that this sort of issue can be resolved with some form of
sanity and diplomacy.

However, you are correct for the scope of your understanding
of what is "right" for the web, i.e. people needing to read the
content and hand edit it, this is after all one of the greatest
virtues of XML as a format over binary file formats.

At the same time, there is a large industry that automates the
generation of content from any number of original data sources
and these sort of applications will by accident or deliberately
generate content with e notation.

The general population will not care if the page they are
viewing has underying content using e notation that renders
in some UAs but not others, but they will be upset when it
fails to render.

Those blessed with a higher IQ and possibly even a mathematical
or engineering education are likely to be able to read the
e notation just as easily as my good learned friends.

Perhaps you may come to understand that before we need to worry
about your body.

Cheers,
Alex

>-h&kon
>              Håkon Wium Lie                          CTO °þe®ª
>howcome@opera.com                  http://people.opera.com/howcome
>
>
>

Received on Friday, 27 August 2010 14:58:33 UTC