Re: target="_new" - I won't miss it (was: ...Napoleanic Issues)

> XHTML will not make old documents obsolete.
> If you have correct HTML 4 documents, they will still be correct
> HTML 4.  Browsers will not suddenly stop rendering them when
> XHTML becomes a Recommendation.  Some new browsers and special-
> purpose clients may require XHTML 1.1, but if that's an issue,
> then the lack of <A target> is the least of your problems.

Yes, that's true.  I could just serve documents as
text/html, or I could serve them as text/xml.  But was
not the point of XHTML that documents validated "against"
its DTD would be not only well-formed but also valid, and
be capable of being served as text/html to older browsers?
If you wish to require that users obtain new browsers in
order to read these documents, you lose the point of XHTML,
and might as well just serve XML documents with arbitrary
DTDs.

And in fact your last point underestimates the problem.
We are likely to face a host of widely different DTDs
based on XML or XHTML, all of which try to use HTML
features, but tailored to different user agents, such
as the Open eBook specification or other portable
devices.  With HTML one could be compatible by including
elements that were simply ignored if the user agent did
not have that feature; with XML or XHTML one can only
use elements in a particular DTD.

> > Nielsen's complaint is not
> > valid--the BACK command does work in Lynx, so if
> > a user agent wishes to respond that way it can--
> > it is not a problem in the HTML DTD itself.
> 
> I love the logic here.  You've now said that:
>   1 - Lynx ignores target="_new"
>   2 - Lynx does the right thing.
> 
> A lot of people would conclude:
>   3 - The right thing is to ignore target="_new", and
>       if browsers should just ignore it then there's no point
>       carrying it forward in future versions of HTML.
> 
> But your conclusion is:
>   3a- target="_new" is great and should be supported in all
>       future HTML specifications.

I didn't say that "target" was great. Only that it has
a function and is used, and that prohibiting its use via
a new DTD is not necessary.  I pointed out that an HTML
user agent might simply ignore that element, as Lynx 
does--that is the proper place to handle it, not by
arbitrary DTD authoring.  In other words, Lynx does the
"right thing" to ignore it--but so does Internet Explorer
do the "right thing" to handle it the way it does.  That
is the way HTML works.  But not XHTML.

My point is that almost all of the benefits of XHTML
could be obtained simply by requiring that the
document be well-formed in XML terms.  If there is
an element "target" in the document the parser needs
to figure out where in the structure of the document
this is allowed.  The parser doesn't need to get
involved in the semantics of the element--whether or
not "target" has a meaning to the browser depends on
more than just the document structure as set forth in
the DTD.  Moving the logic to the style sheet improves
the matter not one bit.  Whether or not "target" is
a "good thing" or something horrible ought to be
irrelevant when writing a DTD for XHTML; it should only
be a case of whether the structure ought to be outlined
so the browser parser can know how to handle it. 

I can see the earlier problems with framesets in XHTML:
they cause structural problems because of the "body"
element in the DTD.  But I can't see that the same
argument applies to the "target" attribute when it
is not used in a frameset.

Really, what happened to the "eXtensible" part of XML?
Here we are arguing once again whether or not "blink"
and its cohorts ought to be allowed to the table.

But you are right that most of us will hold back and
not rewrite our documents for XHTML. I would like to
use "accesskey" but don't even have a browser to
figure out how it would work.  When I don't have to
use <center> to center a subhead in Lynx then I will
consider doing away with that hack and writing to
"pure" XHTML and CSS.  Meanwhile, good luck, W3C, in
your arduous labors!

Received on Tuesday, 18 January 2000 20:09:37 UTC