Re: HTML friendly links to metainformation

[resent because I accidentally siphoned this thread offline. - Al]

On Sat, 20 Oct 2001, Al Gilman wrote:

> >We installed Site Valet for a company whose intranet standards required
> >certain metadata to be visible within every page - so it had to go in
>
> If you don't need it to parse the contents, I am inclined to wonder if it

Thwe contents were maintenance information, including page maintainer
(with a mailto: link) and page review dates.  Site Valet parses that
lot to email maintainers when reviews fall due, among other things.

> >> <div> <!-- or any other container -->
> >> <meta keywords="accessibility, report">
> >> <meta scheme="EARL 1.3.7">
> >> <link role="meta" href="URI-reference_returning_EARL_doc"
> >> type="cturi:text/rdf;version=1.2">
> >> </div>
> >
> >Ugh! If anything is going to break back-compatibility, trying to
> >reuse HEAD elements in a BODY must be a prime candidate.
> >
>
> _Empty_ HEAD elements???  I just want to understand why it breaks something.

I'm not saying it does break something.  But why take the risk?

> Element types are for what they do, not where they go.
>
> The basic problem is that in order to provide a content model for The Web
> which
> give equal justice independent of the concurrency-horizon of viewports or
> interaction modes, we need to view web pages not as atomic 'resources'
but as
> extended samples of a finer infoset 'web.'  Or at least this view is
presented
> in the attached "page scope not universal" argument and figure.

Erm - I'm postponing looking at that (time ...).

> There is not legacy practice for metadata, or is there?  You seem to have a
> customer that does use it.  What is the current usage of metadata with HTML?

This customer is using a custom-DTD based on HTML4.  I wouldn't regard
it as useful input to any HTML-WG deliberations, beyond what I already
said about enabling human-readable metadata.

There are certainly uses of <META> on the Web at large: for example,
robots exclusion, PICS.  Why should a parser looking for things like
this even parse the <BODY>?

> The example I offered was meant to span
>
>   a) using DIV in HEAD to bundle META properties with LINK references

<div> would be the wrong element for that.  An expansion of the
syntax of <meta> would make more sense:
<metadata purpose="accessibility report"> ... </metadata>

>   b) permitting this inline in the BODY

This is effectively what we did with the customer I mentioned,
though it took some smoke-and-mirrors with <div> and CSS to
achieve satisfactory browser presentations.

> One can lose b) without striking the example, only the comment.
>
> >No, if a document is going to point to its own EARL report, then a
> >LINK element (or META as second choice) in the HEAD is the right
> >mechanism for it.
>
> The argument against this is that there should be plain HTML information
> disclosing the path to more information.

But that's exactly what <LINK> and <META> are!

>  No machine secrets; nothing up the
> sleeve.  People use hyperlinks in footers.  They don't use invisible
LINKs in
> HEADs.

Yes they do.  <LINK> support is gradually hitting the mainstream (recent
Mozilla and MSIE variants have finally got around to doing something
sensible).  You'll lose that by putting it in a <BODY>.

OTOH nothing in your example will be rendered by any existing browser -
except the <LINK> if put in the <HEAD>.

BTW - this is email-only, because yours was.  But feel free to quote
from it in a public forum if you want to.

-- 
Nick Kew

Site Valet - the essential service for anyone with a website.
<URL:<<http://valet.webthing.com/>http://valet.webthing.com/><http://valet.
webthing.com/>http://valet.webthing.com/>

Received on Saturday, 20 October 2001 20:37:07 UTC