Re: Proposed Design Principles review

On Apr 26, 2007, at 10:27 PM, Doug Schepers wrote:

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

Do you have an argument for that? I explained how we could break  
compatibility without adding a version number, or vice versa. In what  
sense, then, are the two 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.

I don't think your argument follows. Authors are already widely using  
Flash to deliver video content. To get them to buy into a non- 
proprietary alternative that's built into HTML, we have to let it be  
a drop-in replacement, which means no requirement to restructure  
their existing HTML4 documents.

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

The main advantage of Flash for use cases like video or audio  
delivery is that it works everywhere. But it's also an advantage that  
it doesn't interfere with your existing content.

In any case, competing with proprietary technologies is a minor  
point. The fact remains, we want authors to be able to use new  
features without having to rewrite their documents.

If rewriting is OK, then there's no reason to do HTML5 instead of  
just improving XHTML2. By far the main reason we are doing it is for  
better compatibility with existing content. Given this, I don't  
understand why people keep advocating that HTML5 should break  
compatibility too. OK, I do understand in a way. Browsers are  
unlikely to implement XHTML2 any time soon, if ever, while it's  
pretty likely that HTML5 will get traction. But that fact does not  
exist in a vacuum - HTML5 has more traction with browser vendors  
precisely because it doesn't break compatibility.


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

I can see how you can do this when adding new functionality, but it's  
a lot harder to see how you can do it when removing functionality.

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

Yes. Here's one survey of usage share by version: http:// 
marketshare.hitslink.com/report.aspx?qprid=6

Short version, it's pretty significant.  IE 5.0, Safari 1.2, Opera  
7.x and Firefox 0.1 all see more use than even the most widely used  
mobile browsers. Firefox 1.5 sees about as much use as all versions  
of Safari combined. IE6 sees almost twice as much usage as IE7. Other  
surveys show even higher share for IE5 and other older versions.


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

What is simple and consistent is to some extent subjective and a  
matter of taste - what works in today's running code is completely  
objective.

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

IE5 came out 8 years ago. IE6 came out 6 years ago. We can expect  
today's most popular browsers to remain relevant for at least as  
long. So this cost will likely remain for a long time no matter what  
we do. Adding more processing modes is only going to increase the  
cost of supporting all widely used browsers.

That being said, the fact that a processing model may have odd corner  
cases usually does not need to deeply concern the typical developer  
of new content. If you make conforming HTML5 and check it with a  
conformance checker, it doesn't matter what weird things the error  
handling algorithm might do.

If we really want to help developers of new content, we need to make  
sure HTML can be used in a reasonably simple and easy to understand  
way for new content, while not breaking support for old content.

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

It's easy to be cavalier about other people's time and money. Maybe  
it will help you to think about the opportunity cost - engineering  
time spent implementing, maintaining and testing more modes is time  
spent not implementing other new standards that add new capabilities.  
Would you prefer Safari engineers spend our time on HTML5 mode  
switching, or on, for instance, making our SVG support more complete?  
Not that this will necessarily be the exact tradeoff. But engineering  
time is not free, and something has to give.

Also, you are weighing developers of brand new content over people  
maintaining and improving existing content, which is likely a bigger  
constituency.

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

I'm not sure how you can preserve backwards compatibility and not  
keep all that has gone before.

In any case, it would be a lot easier to consider this in the context  
of specific proposals to change things incompatibly. It's hard to  
give much weight to a non-specific set of simplifications against the  
huge cost of breaking compatibility. Maybe you can outline one  
specific example of something you'd like to change incompatibly so we  
can do a sample cost-benefit analysis.

Regards,
Maciej

Received on Friday, 27 April 2007 06:34:38 UTC