Re: backward compatibility for links + more random thoughts

David - Morris (dwm@shell.portal.com)
Fri, 19 May 95 15:29:40 EDT

On Fri, 19 May 1995, Larry Masinter wrote:

> could be used around segments that should be totally elided if the
> browser supported the link types.
>
> Even browsers that didn't support navigational buttons in a menu bar
> might want to elide the sections marked with XXLINK when printing.

Good idea ... two things I would add ...

1. Eliding of the text should be controled by an XXLINK attribute.
(default=elide would be fine). In some cases, I would expect
the author to put the next page button in context in the page
as well as have it added to the browser bar if supported.

I have written pages which say "push the browser's back" button
etc. What I learn again and again is that what is obvious to
me isn't to other folks.

2. Rather than being forced to use <img src=button> I still believe
and additional related capability is that we need a
<button label="next page"> empty element which would have the
browser render a button with the specified label however it
would have rendered a <input type=submit value="next page">
on a form. Better UI consistency, less network traffic, etc.

Then Larry's example would look sort of like:

<xxlink href= ...>
Some text
<a href= ...>
<button label="Next Page">
</a>
more text.
</xxlink>

Of course, since this wouldn't be backward compatible,
so perhaps it should be
<button>Next Page</button>

Which leads to a new random thought ... not original ... another reason
to define some form of conditional processing for html of the
future which might not help backward compatibility this year but
might in 6mo to a year. Something like:

<when level="regular expression against html features">
do this if when is true
<otherwise>
or do this if not true
</when>

All of the currently available solutions which require content negotiation,
server pre-processing, etc. are truly awkward for the content author who
must create and maintain multiple versions of a document for modest
differences (or depend on non-standard non-portalble local solutions).

The syntax, precise semantics, etc., can vary but I believe it is
going to be critical to have some kind of conditional processing
markup if we are to avoid the continual forever debates about how
to gracefully deploy new features.

Dave Morris