Re: target and frames nonsense (Was: Re: Comments on HLink)

"Steven Pemberton" <steven.pemberton@cwi.nl> writes:

> From: "William F Hammond" <hammond@csc.albany.edu>
> > <grumble class="curmudgeon">
> > I've always seen target, frames, and friends (going back to blink) as
> > juvenile.

> . . .                                                            Or search
> applications with one frame for search results, and one for the content of
> the current search result. Or an overview frame, and a content frame, like
> Acrobat. The problem with HTML Frames is that the inital design was faulty.
> The concept nevertheless has proven to be a valuable one. Which is why we
> are trying to improve it.

(XML frames _may_ be OK.  Undecided.)

The anchor target attribute as currently used is problematical.  It
probably is, as you suggest, an issue with user agents, but I think
the attribute, in fact, was originated out on a limb by a particular
user-agent with obnoxious pre-emption of user prerogative.  Then
others followed suit.

Given that history, the target attribute is "broken" (not that markup
can be broken).

> > <grumble class="parenthetical">
> > And you guys want to trash <br> and <hr> which do, in fact, represent
> > loosely structured content.
> > </grumble>
> 
> We don't want to trash <br> functionality, just the way you represent it (to
> make the structure more explicit).

Ultimately, isn't this analogous to saying that using "." for the end
of an English sentence should be supplemented by also using a code
point to begin a sentence?  Does that square with e. e. cummings usage
in English poetry?

Think about those who have written translation style sheets to convert
highly structured address elements in serious document types to the
HTML address element with HTML "br".

In fact, as a theoretical matter, no defined-empty element can have
the same "functionality" as an element that is permitted to have
content.  It can only approximate that functionality.

> As for <hr>, we still haven't reached consensus. I believe strongly that the
> <hr> functionality (of a separator) has shown its worth, but that the name
> is misleading.

Supply a better name for new use, but keep the old name for the sake
of preserving the value of extant translation style sheets from
serious document types.

                                    -- Bill

Received on Tuesday, 1 October 2002 12:40:48 UTC