E-mail List Archives
Re: Graphics and Captions
From: Patrick H. Lauke
Date: Jan 20, 2006 8:30PM
- Next message: Patrick H. Lauke: "Re: Graphics and Captions"
- Previous message: Kynn Bartlett: "Re: Graphics and Captions"
- Next message in Thread: Patrick H. Lauke: "Re: Graphics and Captions"
- Previous message in Thread: Kynn Bartlett: "Re: Graphics and Captions"
- View all messages in this Thread
Kynn Bartlett wrote:
> Which is an awful, horrible can of worms which isn't even really worth
> considering. I mean, embedding semantics into classes on a user-agent
> or site-specific basis? Why?
To clarify: I'm not saying microformats are the best way of doing things
(versus, say, having links in the head of a document to some RDF or XML
file)...but I don't see them as the civilised web as we know it...
> The primary, and only valid use, of class is for creating selectors
> for applying styles.
Where did you get the "and only" from? Any spec that could corroborate this?
> Class is acceptable presentational markup. It's the glue that allows
> us to "separate presentation from content" in a consistent manner.
It's either the glue between markup and presentation, or it's
presentation in and of itself. The above is contradictory.
> In both cases you're talking about extending beyond the standard. I
> would rather extend in a manner that makes sense, rather than just
> trying to patch together something that will have to be torn down
> again in the future as harmful.
So a "sit and wait" approach rather than a "we accept it's only a
> ID is, of course, a different thing, which is why I'm not talking
> about ID. I'm not entirely sure why you're trying to mix ID into this
> discussion, except perhaps to obfuscate the point.
I'm not attempting to obfuscate the issue, thank you very much. Could it
be that I mention them in the same breath because...oh....the spec does
7.5.2 Element identifiers: the id and class attributes
> "After all," someone might say. "Why do we need to be able
> to identify a caption, if you can just do class="caption" and be done
> with it?"
Because my idea of microformats would be to first use the most
appropriate method, within the boundaries of HTML, to achieve something
(getting back to the thread starter, wrapping the image and its caption
inside an element to denote that they somehow belong together in some
vague way), and then apply additional information that can be further
used by microformat-aware user agents / transformers / whatever (and
it's purely optional...we're not just relying on the software being able
to understand the microformat...if it doesn't, it's still getting our
best effort HTML).
> If your client-side or server-side processing tools are so
> unsophisticated that they have to rely upon using the class attribute
> instead of using proper markup, in this XML-friendly world, then you
> need to develop better client-side and server-side processing tools.
I personally favour XML as well. I think it's disconcerting though that
even Tim Bray makes a mention of microformats as a viable alternative
Patrick H. Lauke