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

Hi Boris,

	You have some good points, all supporting my point of view...

	See below:

--Original Message--:
>On 8/25/10 5:25 AM, Alex Danilo wrote:
>> Modal?
>>
>> You're kidding right.
>>
>> Here we go, quirks mode, modal CSS parsers.
>
>Well, that's what happens when two different groups specify syntax that 
>is almost but not quite identical and you want to support both syntaxes. 

Yes.

>  You have the choice of writing two separate but very similar parsers 
>or one parser with a mode switch.  I'm not sure what you complaint is, 
>exactly.

I didn't realise it was a complaint.

More like an observation that decades of educational institutions
seem to think that exponential notation is a valid way to represent
numbers and that the CSS WG has somehow decided that "people
don't understand them", etc.

You as an implementor should be objecting to having to deal with the
different parsing modes, especially when it serves no purpose
other than to add to the complexity of a browser and add memory
footprint and scope for bugs.

There are many camps that argue modal vs. non-modal interfaces
but parsing numbers doesn't really fall into that category.

>> The web browser of 2020 will likely contain 1 million modal parsing and
>> layout modes
>
>I think most people who write UAs are working rather hard to avoid that. 
>  Some smaller fraction of those who write specs is doing likewise.

I totally agree with you here.

And the people writing the specs should learn to listen from the
implementors who tell them that perhaps your spec could be changed
for the better rather than stubbornly arguing their point of view
at the detriment of the overall community.

If "implementers will implement it that way anyway" then perhaps
it's a signal that the spec is short-sighted and could do with
some correcting and/or clarification to better reflect what
the actual people writing the code need to handle, and it's
not what's in the spec all the time as I'm sure you'd agree.

>> Some days I wonder if the lunatics are really running the asylum...
>
>This is the web.  It's "run" by people who write web pages, by and 
>large.  What you think of them is up to you.

Wrong.

<rant>
This is not "run" by people that write web pages.

It's run by browser implementers, and secondarily by the standards
bodies that try to influence the direction of the browser writers.

Years ago I remember Tantek making a comment at a BOF table that
all the standards setting and namespace stuff was irrelevant since
all that people care about was HTML4, CSS1 and a few embellishments.

He was correct to a point, but that is the crux of the problem.

I have worked on a large project whose analysis was that 99.6% of all
web pages out in the field violate the HTML spec. So, it comes
down to error handling.

The maxim "be prudent in what you generate, and generous in what
you consume" has historically been the path to hell for interoperability
on the web.

The "people" that "run" the web by writing rubbish and testing it
in one browser are innocent parties, the guilty ones are the web
browser implementers that think it's OK to render anything that's
almost correct, mixed order of tags, etc, etc.

So we have the situation that there are only perhaps 4 main
implementations of the "web" and the code-bases represent
probably hundreds of man-years of work and are likely to be
unchallenged by any new entity due to the sheer legacy mess
that exists. Office, anyone...

The HTML5 effort is commendable for trying to lock down the
browser specific behaviour in a form that can be replicated
by others, the HTML5 parsing algorithm being a prime example.

But, given all that - the working groups doing this work
seem to have lost sight of the KISS principle. Keep It
Simple Stupid.

To be forced to have a modal or duplicated parsing code with
minor differences violates the KISS principle, doesn't at
all align with Agile DRY and pragmatic ideals nor benefits
anyone.

I have yet to meet a single graphic artist who hand edits
HTML/XML/CSS/SVG to produce web graphics. Yet those are the
people we are meant to serve.

The web is not "run" by people who write web pages, the
artists are the real originators of what is arguably the
best content. They don't care about whether their tool
generates weird tags that may or may not include scientific
notation, but you can bet that coping with generation and
parsing of the notation on a conditional basis is a pain
both for the authoring tool implementor and the browser
implementor.

In the '80s we entered the supposed WYSIWYG age where the
content was king and the file format, namely the markup
was invisible and secondary. Only a fool would think that
the bulk of the web would be authored in emacs.

My point is that if an implementor of any W3C spec. has to
write _any_ extra code to implement an arbitrary restriction
that has no basis in functionality, then that is a bad thing.

Also, geeks on standards bodies are not the primary content
generators for compelling content, and so are the last people
who should be debating "what people understand" when the
thing being understood should be an opaque file format.

When was the last time anyone hand edited a Flash file...
</rant>

Fire away,

Alex

>-Boris
>
>
>

Received on Wednesday, 25 August 2010 12:18:14 UTC