- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 26 Apr 2007 23:34:32 -0700
- To: Doug Schepers <doug.schepers@vectoreal.com>
- Cc: public-html@w3.org
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