[whatwg] <output> and onforminput
jg307 at cam.ac.uk
Thu Jun 24 12:57:22 PDT 2004
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
> 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.
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
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"
More information about the whatwg