> > I know that in order for HTML to become a HyTime application a lot needs
> > to be accomplished especially regarding entity management. People
> > keep saying that there is the backward compatibility problem.
> > I understand this point of view but I do not think this is such a big issue.
> >
> > There are plenty of HTML 1 and HTML 2 documents all around the world.
> > Some people want to make them HTML 3 with no effort and that's what
> > they call the backward compatibility requirement.
>
> For "Some people" I'd read 99% of the WWW users. We should consider
> the "competition": whatever one may think of Netscape, to date they
> have added their extensions in a way that usually does not totally
> break documents/software ignorant of them. If we define a "standard"
> for HTML 3.0 that is cumbersome migrate to, the market may
> vote with its feet for something else. I don't want a standard that
> needlessly increases fragmentation in the web.
>
> I think that proposals to make HTML 3.0 other than a superset
> of HTML 2.0 should make a strong case for actual benifits
> coming from the change.
>
> (I'm more willing to see modest changes like removal of some
> depreciated features (or adding more usage to depreciated)
> or technical adjustments to the DTD than I am to endorse
> something that would break common usage of basic tags.)
>
> --
> Albert Lunde Albert-Lunde@nwu.edu
Do you really think that 99% of W3 users need the new features
proposed by HTML 3.0?
Do you think that 99% of the documents on the Web need to take
advantage of tables for instance?
As far as Netscape has done with their HTML "enhancements", I'd
say that maybe the new element types they introduced were necessary
but they shouldn't have done it this way. They should have
influenced the design of the HTML model and this model is defined
by the user community.
Once again I don't see why you want to migrate all the documents to
HTML 3? Only those documents that need the features introduced by
HTML 3 need such a migration (e.g. a document in which a table should
have been present in the first place).
The cumbersome side of document manipulation comes usually from the
user interfaces in the tools. I bet anyone would prefer to have a
WYSIWYG HTML editor. And they do exist now. And they can hide all
the cumbersome side effects of a so-called heavier markup. Therefore
the users will always interact with documents in the same way.
I totally agree with you when you say that any major change should
make a strong case. The idea for driving HTML into the future is not
backward compatibility. I'd say it is to propose a richer and richer
model for documents. And this model should remain in the hands of
the user community.
Best regards,
Christophe
PS: I am sorry about the line length in my previous mails :-( If
anybody is interested I'll resend them with a correct length.
Sorry...
-- Christophe Espert - E-mail: espert@cln46fw.der.edf.fr ======================================================================== EDF - DER | High Text 1, Avenue du General de Gaulle | 5, rue d'Alsace 92141 Clamart CEDEX - FRANCE | 75010 Paris - FRANCE Tel: 33.1.47.65.43.21 ext. 6635 | Tel: 33.1.42.05.93.15 Fax: 33.1.47.65.50.07 | Fax: 33.1.42.05.92.48 ISO 8879:1986 - SGML | ISO/IEC 10744:1992 - HyTime | ISO/DIS 10179 DSSSL