< another counterexample or two>
>How would they make use of that information? Unless and until there's
>a public agreement about what such data represents, you're talking
>about private techniques. When such general consensus is reached,
>then we add it to the spec. No?
_BUT_, they can be private techniques which won't break current and
future WWW clients. Otherwise, each new data element will require
not only the discussion/consensus cycle, but also the implementation
cycle for each Web browser or server out there. I'd be much happier
not having to create an empty tag for "Keywords", since my browser
ignores it. The <meta> tag seems like a great way to allow extensible
data items to a document without requiring that the browser manage to
parse the syntax (tag) for each one.
>> Other likely names are "Keywords", "Created", "Owner" (a name)
>> and "Reply-To" (an email address).
>
>Yes... all these belong in the <HEAD>...</HEAD> of an HTML document.
>The HEAD is by design isomorphic to the HTTP headers, or the headers
>of a mail message or a news article. You don't need an extra META
>element to say this.
In a perfect world, this would be true. However, realistically
speaking, HTML <HEAD>s still need some protective formatting. I
think the <meta> proposal offers this - a way to add both generic
(such as "Expires" and "Keywords") and application-specific
("Chris' Quality Rating") information to documents without having
current browsers/servers break, and without having future browsers
break on information types they don't understand. I think this
would save a LOT of new tags for things like Expires, Keywords,
etc. I'm not saying this means we don't need to formalize some
of these commonly-used (what's the correct tense construction for
"will be commonly used"? :^) META information types, though - just
that there should be a quick way of adding application-specific
document information that is compatible with current systems.
>>> I can see the need for:
>>> <EXPIRES DATE="...">
>>> but not a general HTTP header escape mechanism.
>>
>>But can you anticipate the needs of everyone?
>
>No, and I'm not trying to. New elements can and will be added over
>time.
But why should document producers need to beg for a whole new TAG
just to add a little bit of data that their server wants to see?
It seems like you're saying here, "I don't WANT to do it the
easy way", which would be fine if someone could tell me why
the <meta> tag is a BAD idea.
>I find that original proposal quite on target, and I don't see how
>the counterargument carries much weight. What examples motivate
>this "general need for document metainformation" that are not
>satisfied by new HEAD elements?
None, given that 1) you don't mind that an indiscriminately large
number of tags may need to be added, which may take eternity, and
2) you (as a document producer) don't mind that some browsers and
servers are going to choke on your data due to unrecognized tags.
I, as a client and server developer, would much rather support one
tag with genericized values for representing arbitrary information
(most of which I can probably safely ignore) than having to code in
support for a bunch of new tags, or get a load of errors parsing
documents because my browser doesn't understand all the new tags
someone is using in their document.
>>Love to, but HTML lacks any ability to add new elements which
>>contain content without breaking compatibility with existing browsers.
>
>Sad but largely true: HTML is defined by the behaviour
>of Mosaic. The HEAD element has long been documented as info
>that doesn't go in the text flow with the body elements, but
>the Mosaic code doesn't make any distinction between HEAD
>and BODY.
Guilty as charged. However, this kinda goes in with the above -
even if it's in the head, it's still gotta be parsed. With future
"strict compliance" modes in browsers, this is a can of worms that
I really just don't see the need to open, when we could skirt the
issue so easily.
>>Thus, including the above in any existing document will result
>>in the line
>>a,b,c,lkjsdlfkjsldf...
>>appearing at the top of the display.
>
>Ok, fine... so make all the new elements empty. Or just fix Mosaic. :-)
...but fixing Mosaic won't fix future elements not being supported
by future browsers.
>>The META element is not a hack.
>
>I disagree.
In a sense, it is a hack... if a hack could be defined as a widely
(perhaps even "uncomfortably") extensible system for adding
open-ended information to documents. However, adding a new tag for
each new information element isn't just a hack, it's a _LOT_
of hacks. It's a _LEGACY_ of hacks. Hacks are going to happen,
whatever the Web community wants - look at <img> - but we have
the opportunity to prevent the need for a lot of elements being
hacked in by putting in _one_ element. I see this as a VERY good
thing. My vote's with Roy (and Jon Knight).
-Chris Wilson
:::::::::::::::::::::<<< NETWORKING THE DESKTOP >>>::::::::::::::::::::
Chris Wilson Spry, Inc.
WWW Product Development Lead 316 Occidental Avenue S. 2nd Floor
Email: cwilson@spry.com Seattle, WA 98104
Phone: (206) 447-0300 FAX: (206) 447-9008
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::