Re: Proposed Design Principles review

Hi, Maciej-

Maciej Stachowiak wrote:
> 
>>   I'm convinced that a version
>> attribute is the way to go, while others contend that the language 
>> itself must incorporated (almost) all the features of past 
>> implementations.
> 
> I think these are two separate issues. 

I think the issues are more closely related.


>> To me, the idea of a version that clearly identifies that the page 
>> will be treated strictly according to the HTML5.0 standard, and which 
>> will produce visible problems if not coded correctly, gives us leeway 
>> to be less inclusive of past quirks.  If the language is designed 
>> correctly (and I have no doubt this group could do so), then the 
>> leaner syntax would still degrade gracefully in older browsers.
> 
> I think there are a few problems with this:
>
[snip]

> 3) We don't want the use of new HTML5 features to be blocked on making 
> unrelated changes to your document to avoid deprecated features from 
> older versions of HTML. An author shouldn't have to change their doctype 
> string and fix all validation failures to play around with <canvas> or 
> <video> or the client-side storage API. That's just asking too much. 
> Authors will just go with proprietary solutions like Flash or 
> Silverlight that don't require them to make unrelated changes to their 
> markup. Or if they do use HTML5 features, they will pay significant 
> development cost to make the other changes to their site to be able to 
> do so.

I'm not convinced that it's a logical step to say that rather than make 
a few changes to their existing infrastructure, authors will buy 
(literally and metaphorically) into proprietary technologies that will 
oblige them to make even more drastic changes to their infrastructure, 
and add in even more costs and training time to do so.

If they do make that choice, then it's clear that those languages offer 
them something that we could not, and I would argue that's likely to be 
a simpler, more powerful environment.


> For these reasons, HTML5 has to handle the vast majority of legacy 
> content, or at the very least be compatible with doing so. These three 
> issues vastly outweigh the benefits of simplifying the language. I agree 
> with you that a simpler, cleaner language would be more elegant. But, 
> unfortunately, it would be far less useful.

That totally depends on how it's designed.  A graceful fallback of 
cleanly-designed language may mean that older browsers don't have all 
the richness of functionality or appearance that user of newer browsers 
will experience, but it won't necessarily "break" (and in newer 
browsers, will be more useful).

As a side note, has anyone done a study on how many people are using 
older versions of browsers?  I keep up on current browser releases (not 
least because they nag me to upgrade), but is that uncommon among normal 
people?


> You are in effect asking browser vendors and maintainers of existing 
> content to pay a large development cost for the aesthetic benefits 

No, please don't mischaracterize my intent like that.  It's not about 
aesthetics, it's about a simpler, more consistent language for developers.


> of a 
> simpler, more elegant spec. And I don't think that is a reasonable 
> request. We're talking potentially billions of dollars in development 
> costs across the industry.

While you are asking for developers to continue to struggle with the 
legacy quirks for years or decades to come, certainly a greater cost.

I'm less concerned about 4 or 5 browser vendors who (once the majority 
of implementation work is done, a simpler task with a cleaner language), 
will essentially have only to fix bugs and innovate, than about the 
millions of authors who will have to code to those browsers (myself 
included).

Maybe I'm being naive, but I think there has to be a way to preserve 
backwards compatibility without aiming so low as to keep all that has 
gone before.

Regards-
-Doug

Received on Friday, 27 April 2007 05:27:57 UTC