- From: James Graham <jg307@cam.ac.uk>
- Date: Thu, 24 Jun 2004 20:57:22 +0100
Jim Ley wrote: > On Tue, 22 Jun 2004 01:14:03 +0100, James Graham <jg307 at cam.ac.uk> wrote: > >>Lachlan Hunt wrote: >> >>>Ian Hickson wrote: >>> Why should it matter that >>>Internet Explorer has a large market share? >> >>Because web authors will not build sites that don't work for 9/10 of >>their visitors. > > > The WHATWG website claims that the spec is backwards compatible, which > means it'll work on all UA's no need to special case IE, of course It means that 'legacy' UAs will be able to display the new documents as if they were HTML 4 documents. Of course it doesn't mean that all the new features of the spec will be available in legacy browsers and, in particular, server-side validation will still be required. However, server-side validation will always be required to ensure data integrity since it would be trivial for anyone to write a simple application to POST invalid data without any client side checks. The only use of client side validation is to aid the user in entering data of the correct form without repeated trips to and from the server to check the validity. This is independent of whether we are talking about javascript, Xforms, web forms or something else. There is nothing to prevent the developers of lynx or other browsers implementing web forms support. Your choice not to upgrade browsers should not inhibit the browser developers from adding new features to later versions of the browsers to benefit those who do choose to upgrade. That applies to DOM, CSS, XSLT and pretty much every other technology implemented in browsers today, not just Web Forms. I don't see anyone arguing that generated content in Opera 7 is intrinsically bad because Opera 6 doesn't support it. The fact that the WHAT group has decided that the ability to implement parts of the spec in existing versions of IE is important reflects the fact that it dominates the browser market and that web developers won't use functionality not fully supported in IE. Why write a spec without considering what is required to make it useful? > it's looking increasingly like that is marketing speak, and the actual > intention is to obsolete the commercial browsers still in the > marketplace to drive sales of the Opera client. What? I don't understand what you're trying to say. You seem to be accusing Opera of creating new and useful technologies to implement in the hope that the improved functionality that they provide will be an incentive to use a browser that supports those technologies. I always understood that improving one's product was a good idea (as opposed to, say, forcing an upgrade through licensing or by refusing to support older versions). Doing so in collaboration with other vendors to create a standard that is compatible with older clients seems like a very very good idea to me. If Opera were looking to deliberately break older clients it would certainly be possible to spec Web Forms so it didn't work at-all in legacy UAs. > >>The idea is that they don't need to be because it will be possible to >>use the mechanisms available for extending Internet Explorer (e.g. HTCs) >>to implement (much of) the spec without the aid of Microsoft. > > > Script HTC's cannot be used in a commercial environment, they're > simply inadequate to the task and full of memory leaks and various > other problems If what you say is true, one of four things will happen: 1. People won't use Web Forms or other WHAT specs. We'll be stuck with HTML 4 for the foreseeable future. 2. Organizations will switch to a browser that has native Web Forms support and so avoids the problems with IE 6. This might be Opera or Mozilla or might be a future version of IE. 3. People will accept the HTC problems and get on with their lives. They'll upgrade their computers to deal with the memory leaks and they'll consider IE crashing to be an inevitable part of computer use (this isn't at all an unrealistic option - how many 'commercial environments' have ever used a notoriously unstable Operating system like, say, Windows 95, 98 or ME?) 4. HTCs will be banned and Web Forms documents will act like HTML 4 documents for those organizations who don't follow 2 or 3 above. Which of those options leads to a situation that is worse than the one we're in today? What other path would you recommend following so that we are guaranteed to be in a situation better than the one we're in today? >>"Hi, Microsoft, we're a consortium of your competitors and we'd really, >>really like it if you supported more web standards so more people could >>switch to our products more easilly". > > > Which is obviously much worse than "Hi, Customers, we're going to make > our own browsers obsolete so you'll have to buy new ones, but it's > okay, we'll still support the browsers made by our competitors." I'm pretty sure that it's considered OK for people to add new functionality to new versions of their products so people have a reason to upgrade. Perhaps you can suggest how to add new functionality for authors whilst not causing any possibility of a poorer experience in clients that don't support those features? I'm sure many people, not just in WHAT, would be interested in a solution to this problem because at the moment, if I use a feature from any spec (e.g. generated content in CSS) that is not implemented in all browsers, that creates a problem for people using the browsers that don't support it. As I said, without good IE support (better than just what HTML 4 compatibility provides), the spec is dead in the water. That doesn't benefit vendors, authors or anyone apart, perhaps, for those trying to promote closed solutions to the same problem. > >>I would be a lot more convinced by your arguments if you could >>demonstrate that there is any significant mobility toward XHTML. > > > Tantek Celik recently told me that all the website creation folk in > the US were using XHTML, now I found that difficult to believe, but I > expect he's more likely to have accurate figures than me for that > area. He probably means 'XHTML as text/html'. Since this is parsed as malformed HTML and none of the features of XML work with it, it's pretty irrelevant. Almost no one uses XHTML as application/xhtml+xml and, to the best of my knowledge, no commercial sites use this MIME type because: a) It's not compatible (at all) with legacy clients (in simple cases one can serve text/html to legacy clients but if you actually use namespaces or any other XML features they won't be available to the legacy clients at all. If you don't do this, what's the point of XHTML?) b) It requires a new XML-aware CMS that ensures well-formedness at every stage of the publishing process. Such a new system would be incompatible with existing documents (which are almost all mal-formed). > >>You also seem to believe that everything the W3C does is automatically >>good and useful. > > > Oh no, that's far from true, but at least they have a process Process for the sake of process seems unnecessarily bureaucratic. In any case WHAT seems to have a process albeit one that is loosely defined. > , it may often fail So the W3C process is dysfunctional? > at least it exists Why is a formal specification of process so important that you believe that even a dysfunctional process is better than the current mode of operation of the WHAT-WG? > and isn't controlled by 2 browser vendors Well there are at least 3 browser vendors and one person who, as far as I know, is independent listed as members. It is also clear the input is being taken from this public mailing list. The impression I get is that you have taken exception to the fact that people don't agree with everything you say and so have started disparaging the entire effort. Whilst I couldn't be sure that some relevant points haven't been missed among the large volume of email, I'm not sure this approach will encourage people to take more account of your views in the future. -- "If anybody ever tells you that you?re using the language incorrectly, just yell 'prescriptive grammarian!' at the top of your voice and all the linguists in the building will run over and surround the guy... and then they?ll rough him up"
Received on Thursday, 24 June 2004 12:57:22 UTC