- From: Shannon <shannon@arc.net.au>
- Date: Fri, 29 Aug 2008 18:31:14 +1000
Ben Adida wrote:
> Shannon wrote:
>
>> <link rel="vocabulary"
>> href="http://some.official.vocabulary/1.1/metadata.cm">
>>
>
> Not workable, as this in the HEAD of the document and oftentimes we
> simply can't expect users to be able to modify the head of the document
> (widgets, blog engines where you can only modify the content of a blog
> entry, etc...)
>
I thought I made this clear. There are at least 4 methods or applying
CSS. Each has a purpose. Use the one the works for your situation. Two
of these methods do not require a seperate document or code in <head>.
Discussing the shortfalls of the others for your particular use is
pointless.
>
> I don't think what you wrote above is widely used or understood. In
> fact, I think it's not used at all, whereas RDFa is actually being used
> today.
>
I'm referring of course to the behaviour and syntax, not the elements or
properties, assuming that behaviour were basically the same as CSS.
> Also, one big hole: how do you make a statement about another item? How
> do you describe multiple items on a page? How do you relate two items on
> a page? Say, the Craigslist example, with multiple listings?
>
The same way RDFa does except it's done within a metadata block or
attribute.
> eRDF tried to squeeze everything into @class, and it isn't able to be as
> flexible as RDFa (and thus as we need) in this respect. It has a lot of
> trouble expressing data about multiple items.
>
eRDF is a hack that abuses the purpose of @class. Class was never meant
to carry meaning beyond group membership.
> What's surprising to me is this attempt to shoe-horn so much unexpected
> stuff into @class. What is so sacred about HTML4 that *this* issue can't
> be helped by a bit of rethinking? Certainly, everything else seems to be
> up for rethinking in HTML5.
>
>
Class is not being shoehorned in this proposal. Nothing is being put
into class except class names.
I'm not sure I'd call RDFa "rethinking". It seems a lot like all the
other attributes stuffed into HTML over the years. When the rethinking
on HTML attributes came it was realised that many of those attributes
were underused, inflexible or just better off somewhere else. CSS was
the rethinking of @width, @background, @color etc and a host of
non-style attributes have been removed from HTML5. You're already asking
for at least 4 new attributes and while you've made a case for why they
could be desirable inline you haven't made a case for why they *have* to
be inline or why they *have* to be attributes. This proposal provides
the author the choice of inline, inline blocks, or external files. Each
is useful for differing circumstances.
Your proposal requests 4 or 5 new attributes. This proposal should
support any number of current or future RDF metadata attributes without
changing HTML. Future metadata formats and extensions can be developed
in a metadata working group without being depended on HTML support.
Your proposal depends on RDF. This proposal is mostly format neutral.
New metadata types can be supported in the future using
type="metadata/type" on link and metadata elements.
I think you see the problem to be solved as "RDF-in-HTML". I would
prefer the problem defined as "Metadata-in-HTML".
> By the way, we considered using @class instead of @typeof, but
> we met with serious opposition from folks who didn't want us to mess
> with the existing uses of @class.
>
>
I haven't seen these discussions but were these objections because the
opponents did not understand the concept of multiple classes; or were
they because you were trying to use URIs or namespace seperators
directly in class names eg, class="dc-title"? What precisely were the
objections based on? Was the discussion about a seperate metadata
definition like we are talking about here or was the proposal actually
trying to cram all your RDF namespace, about and typeof data directly
into the class attribute (like eRDF)?
From what you've said here and elsewhere it really sounds like you were
really discussing adding meaning to the value of @class. This is not
what this proposal is about and it isn't what class is for either. For
example this is consider bad:
<div class="red"></div>
this is better:
<div class="thing"></div>
Class is not meant to express an outcome, nor any meaning beyond that of
an identifier. However as an identifier you can use it to associate more
complex declarations of style, script and metadata. Unless I'm mistaken
about your intent it seems these folks may have objected to making
universal class names that have meaning in their own right (reserved
names, class namespaces)?
> Except that means you have to coordinate multiple documents, and that
> really doesn't follow the goal of having HTML be the carrier of all the
> information. That's an important requirement for Creative Commons and
> others.
>
>
You would not have to use multiple documents or any code in head. That
is not a CSS requirement nor should it be a metadata one.
Your choices for creative commons snippets would be something like:
<!-- SNIPPET -->
<metadata>
@namespace cc url(http://cc.org);
.whatever{
about: url(/whereever/link);
typeof: something;
}
</metadata>
<div xmlns="http://cc.org" class="whatever">
...
</div>
<!-- END SNIPPET -->
-- or --
<!-- SNIPPET -->
<div xmlns="http://wherever" metadata="typeof: something; about:
url(/whereever/link);">
...
</div>
<!-- END SNIPPET -->
This proposal requires exactly 1 new element, 1 new attribute, and one
new use of rel, all of which are reusable for future metadata
extensions. If these proposals do not serve CC's needs then you could be
more explicit about why. Claiming that authors wont like or understand
this stuff seems speculative.
> The existing attributes don't do everything we need, as the Primer makes
> clear with the use of, for example, @about.
>
>
I realise that, but you're still focused on the need for RDF attributes
rather than exploring other methods. There is very good evidence that
this proposal could serve your stated needs while also being flexible
enough to meet the needs of others and to grow without requiring even
more attributes in HTML6.
>> Since CSS is
>> familiar to web developers AND already implements the extension and
>> selection mechanisms to target specific elements and groups it is
>> superior to RDFa in many ways.
>>
>
> This argument is *exactly* the opposite of criticism we heard during our
> open period for comments, that whether @class is a semantic extension or
> just a CSS hook, most users think of it as purely a CSS hook.
>
Those users are wrong. One day they will learn otherwise, whether
through this proposal or some future use of class (ie,
getElementsByClassName). For most users the distinction won't even matter.
> Plus, it's *not enough* to express the full range that we need.
>
The spec says that class is not supposed to *express* anything. It is an
identifier of group membership. It is no different from how operating
systems assign users to groups and then assign rights to groups. Whether
this is commonly understood or not is irrelevant. class="red" does *not*
make something red.
> That's one extra level of indirection, which makes things more complicated.
>
>
So what? Metadata is complicated. The only issue is how and where the
complex information is recorded. It's the same logic as putting your
details in your drivers license record instead of tattooing them on your
forehead. If the police require the information they use your drivers
license or social security number as an identifier. In this case @id or
@class are the identifier. If you really insist on painting your
metadata across your structures then use the proposed @metadata inline
attribute.
>> * You can specifically target elements by class and id. The primary
>> benefit is more clarity or specificity.
>>
>
> One extra level of indirection doesn't make anything clearer. That's the
> criticism we heard about CURIEs, and Manu explained well why we think we
> gain from CURIEs more than we lose.
>
> In this case, you're proposing indirection that gains us nothing, since
> @class will still have to provide some semantic meaning that is *then*
> mapped to more generic semantics in a separate file. What's the gain?
>
Once again my response is that class is not supposed to "provide
semantic meaning" and metadata is not required to be a separate file.
This seems a common thread in your arguments. Class is a grouping
attribute with no meaning. No attempt is ever made by the spec to
process class for any purpose other than CSS targetting and some
javascript actions. In both cases being 'human-readable' or 'meaningful'
is a happy bonus, not a requirement. class="udrFGvc8734" is perfectly valid.
> There's no real separation of concerns, unlike with CSS.
>
Of course there's a separation of concern. Metadata is not a requirement
of valid HTML nor even useful for a large number of sites. Metadata
"pollutes" clean code in the same way as inline style attributes.
>> * You can store the metadata locally or remotely and in any format (ie,
>> RDF, ID3) that can be parsed by the agent to key/value pairs.
>>
>
> Key/value pairs are not enough. We need the subject, too. Triples.
>
>
By 'subject' I assume you mean scope (or namespace). Scope is something
CSS provides with nesting, adjacency and multiple classes on an element.
But since this metadata proposal is *not* CSS it can probably provide
whatever additional extensions or scoping are required.
Also I wasn't aware of this until now but CSS3 actually does provide
namespace support. http://www.w3.org/TR/css3-selectors/#typenmsp
CSS examples:
@namespace foo url(http://www.example.com);
foo|h1 { color: blue }
foo|* { color: yellow }
|h1 { color: red }
*|h1 { color: green }
h1 { color: green }
>> * The structure and metadata can be separated. The benefit is both the
>> metadata and the HTML are cleaner and easier to maintain.
>>
>
> As I mentioned above, I don't buy this argument one bit. You still have
> to assign @class, which is effectively an indirection on the metadata,
> but really is another way of expressing (a limited amount of) metadata.
> So there's no real separation of concerns.
>
This is the same argument as above, just rephrased. Class expresses no
metadata beyond group membership. There is also no requirement on @class
at all. @id, tag names and other selectors are equally good.
This argument is the same for class vs. inline CSS. As a designer I've
found time and time again that class is generally a much cleaner and
reusable construct than style="" inline. Class is simply a method of
grouping related elements. It works for CSS and it can work for
metadata. The spec allows a single element to have multiple classes so
an element can have multiple associations from both metadata and style sets:
<style>
.boxed{...}
.title{...}
</style>
<metadata>
@namespace foaf url(...)
foaf|.title{...}
</metadata>
<div xmlns="foaf" class="title boxed">Engineer</div>
These could also be implemented using <link rel="namespace"> which has
been proposed as an alternative or companion to xmlns in some w3c
whitepapers.
> @class may be a semantic extension for HTML, but CSS is not. It's
> Cascading *Style* Sheets, so your proposal tries to to fit a square peg
> into a round hole.
>
Now you're being silly, nobody is proposing putting metadata in a
<style> block or using CSS style properties. The point was made that CSS
has a syntax and behaviour that may be useful for applying things other
than styles to objects. Without resorting to analogies what is your
evidence that CSS behaviour or syntax is unsuitable for reuse? I believe
the reason the OP mentioned CSS and the reason I support it is that
vendors may reuse existing parser and selector code; and designers are
all familiar with its syntax (providing a better basis for discussion).
It's a fairly light language and easy to embed within HTML blocks and
attributes. It was designed for that.
My objection to being forced to put metadata on an element is largely to
do with the fact you dont always have that option. Many CMS or web
programming languages will generate tags without fine-tuned control over
the tag attributes. I'm sure there are many situations where the content
you're trying to tag is not able to receive the new attributes you are
proposing. In these cases the metadata *needs* to be targeted. CSS
selectors may not always be able to do it, but they still stand a good
chance.
<metadata>
/* Except for the property names this is valid CSS3 */
.foo option[value="1"] {typeof: "movie:actor";}
.foo option[value="2"] {typeof: "movie:title";}
.foo option[value="3"] {typeof: "movie:director";}
</metadata>
<!-- generated list from <cfselect query="sql_data"> (Coldfusion), no
additional attributes possible on each <option> -->
<p>Request information about:</p>
<select id="foo">
<option value="1">Indiana Jones
<option value="2">Raiders of the Lost Ark
<option value="3">George Lucas
</select>
Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080829/2f875139/attachment.htm>
Received on Friday, 29 August 2008 01:31:14 UTC