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

Eric wrote:
> Jason wrote:
> > 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.
>
> 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?

Yes, that is a feature of XHTML (but not "the point", imo).  Users
don't need to obtain new browsers to view XHTML.


> 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.

*grin* Does it sound that bad to you?  There will be many different
document types, yes.  But that won't hurt interoperability.  Anyone
who creates a new document type will provide a means to view it (an
XSL stylesheet is fine) and a DTD to validate instances against (if
necessary).


> 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.

That's not the case at all.

You can use XHTML without a DTD.  This gives you more flexibility.
http://www.w3.org/TR/html/#well-formed

XHTML 1.1 will provide a framework for extending XHTML.  You can build
an XHTML module with your own tags.  Then, if you like, you can
generate a DTD that includes basic XHTML and all your extensions.
http://www.w3.org/TR/xhtml-building

If that's not "open" enough, you have other alternatives.  Make up
your own XML document type.


> 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 don't understand what you've written here.  You seem to have a mental
model of how the web should work, and that an XHTML DTD runs counter to
that... but I hesitate to interpret your statements; I don't know
precisely what you mean.


> 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.

Right, this is the real issue.

The intent of W3C Recommendations is to help the Web grow and improve.
This means value judgements are involved.  The W3C should not
recommend features that hinder security, interoperability, or
usability on the Web.

The extensibility is still there, but the W3C will try to avoid
recommending poorly designed extensions.

-- 
Jason Orendorff

Received on Wednesday, 19 January 2000 16:19:21 UTC