LISTSERV mailing list manager LISTSERV 16.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


HTML-WG@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HTML-WG Home

HTML-WG Home

HTML-WG  November 1995

HTML-WG November 1995

Subject:

Re: HTML Editors (What's in store?)

From:

Glenn Adams <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Fri, 3 Nov 95 05:12:22 EST

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (127 lines)



    Date: Thu, 2 Nov 95 22:04:21 EST
    From: [log in to unmask] (Brian Kelley)

    >  - no more doctype decl

    This bring up an interesting question: what do you want from a DOCTYPE
    declaration?  If absent, one is implied, and it seemed to me that inclusion
    of a doctype declaration would, if anything, denote a stricter level of
    compliance with _written_ standards.

I agree, the presence of DOCTYPE should be a warranty on the part of the
content provider that the document actually adheres to the specified DTD.
So, for example,

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

Should strictly be valid according to the 2.0 DTD; while:

    <!DOCTYPE HTML SYSTEM "http://foo.com/mydtd.sgm">

Should be valid according to mydtd.sgm.

In the case at hand, your product read a document which claimed a
certain level of strict conformance.  If as a result of changes by
your product the document no longer conforms, then I agree that you
should remove the DOCTYPE declaration.  In this case, you may want
to warn a user that it is being rendered incompliant (and finding
out if the user really wants to do this).

    >  - removal of H1 markup (replaced by FONT/B markup
    >  - invalid element structure, i.e.,
    >    <B> ... <FONT> ... <P> ... </FONT> ... </B>
    >  - removal of UL/LI markup
    >  - insertion of NONSGML characters (&#149; a bullet?? in C1 space)
    >  - insertion of <BR>s

    There are a few points I should make:

    1) The level of editing functionality we are providing is basic (not
    complete support of HTML2.0). Some of these criticisms are a bit
    misdirected since we don't support lists.

OK.  I'll buy that explanation for lists.  How about the changes from
H1 to FONT ...

    I spend no time "testing" my HTML in a browser (because I already
    see _exactly_ what it will look like) and ...

This is exactly the problem I'm concerned about.  What do you mean by
"_exactly_"?  Do you mean "_exactly_ in Emissary" or "_exactly_ in Mosaic"
or what?  The only way you can make such guarantees is to (1) insure your
content meets certain conformance requirements that insure portability;
and (2) that there exist a set of applications which render conforming
documents "exactly" (whatever that means).

If I recall the HTML specification, it prescribes certain formatting for
an H1 header.  Since your product changed H1 to FONT, a non-standard tag,
which the HTML spec says to ignore, I can't see how your product can assume
exact viewing without making lots of other assumptions.

Furthermore, by removing H1 you have removed a crucial piece of structural
and semantic information that could be used by an indexer or an outliner.

    [hence the "generated by Emissary for Emissary" comment.]

OK. If documents created by Emissary are viewed only be Emissary, then we're
fine.  The problem is this thinking is going to lead to:

Emissary for Emissary
My Editor for my viewer
Her Editor for her viewer
etc.

Portability is going to be gone completely and you will have just given
Adobe and PDF proponents all the ammunition they need to sell PDF to
content providers.

    Forgive me, but this seems a wee bit hyperbolic given the current state of
    the Web.

Well, I don't find the chaos heartening, and editors that produce more
chaos don't help.

      There are countless pages on the Web that _depend_ upon the
      following broken behavior:

       1. ">" inside of quoted attribute terminates the attribute ad the tag,
       2. "-- >" (with a space after "--") does NOT terminate a "<!--" comment,
       3. "IMAGE" equivalent to "IMG",
       4. terminating semicolons not necessary in entity references

Yes, and some people build houses on the beach.  They tend to be rebuilding
them a lot.

    And finally, I _do_ care about standards, and I know that Wollongong cares
    a lot about standards.

Great!  If TWG's (and other's) implementation of TCP/IP had been so liberal,
then we wouldn't be talking now.  [I remember the transition from NCP to TCP
and it sure didn't happen over night.]

I have nothing against dealing with the multitude of HTML sins out there.
Everyone (including us) who wants to sell products in the Web has to deal
with it.  However, we've *got* to find a way to improve the situation. One
way to do this is by having editors and servers that do more to insure they
create and transmit valid documents.  Remember the Internet adage, be
conservative in what you transmit transmit, and liberal in what you receive.

IMO, *all* editors should have the ability to at least insure some level
of document conformance.  Otherwise, it isn't much more different than
using Emacs to edit HTML.

BTW, does anyone besides me find it ironic how much people are concerned
about Internet security but at the same time don't seem to care at all about
document integrity (and the potential problems that entails).

Regards,
Glenn Adams






Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
January 1996
December 1995
November 1995
October 1995
September 1995
August 1995
July 1995
June 1995
May 1995
April 1995
March 1995
February 1995
January 1995
December 1994
November 1994
October 1994
September 1994
August 1994
July 1994

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager