[whatwg] <output> and onforminput

[James Graham]

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"