- From: Karl Dubost <karl@w3.org>
- Date: Fri, 30 Mar 2007 14:43:06 +0900
- To: HTML WG <public-html@w3.org>
starting with a new topic
Thinking out loud
Le 30 mars 2007 à 03:11, T.V Raman a écrit :
> Well said. Another good example of invisible metadata that later
> became "visible" and is a big success on the web is the use of
> the link element to point at
> RSS and ATOM feeds in HTML pages; later, these became "visible"
> when browsers started showing an XML icon on pages.
hmmm. yes! More exactly. [1]
1999. RSS is created
2001. Dave Winer markets the XML orange button everywhere.
2002. People tries to think about a mechanism
for autodiscovery and creates it to not
clutter the UI and improves the usability.
<link rel="alternate" type="application/rss+xml"
title="RSS" href="url/to/rss/file">
2006. Browser implements it in their UI
=> Metadata in the head implemented in the UI for better usability.
Another example: explicit data.
* Implicit data = simple data in a Web page without specific markup.
I understand them because I'm human.
<p>Email: joe@example.org</p>
* Explicit data = data which have been marked up for making their
meaning explicit.
<p><a rel="contact:email" href="mailto:joe@example.org">Joe</a></p>
=> microformats, RDFa are explicit data, but they are still hidden
metadata. All information contained in class, rel, etc. is *not*
visible. The problem of our debate might be here. We are looking at
it in the wrong way.
The debate is more about easy or not to modify depending on the
*authoring* context. This is mainly due to:
1. wysiwyg tools
2. editing through web forms
What people call invisible metadata are most of the time data which
are in fact not data invisible but data which are difficult to edit.
For example the head section of a document which is often
inaccessible in CMS. It reminds me that a few years ago I started a
discussion with Charles on Common Authoring Tools Problems in the
same way than we did for [CUAP][2] and [CHiPs][3].
Let's try to get back to the issue. I think it is all about Authoring
Metadata capabilities and not about visibility.
* For example we could argue that "object" element in its design is a
lot easier to maintain than "img" element for the text equivalent.
Difficult to author and update
<img src="beach.jpg" alt="Beautiful Beach"/>
Easy to author and update
<object data="beach.jpg" type="image/jpg">
<p>Beautiful Beach</p>
</object>
* Another example acronym versus [ruby][4].
Difficult to author and update
<acronym title="World Wide Web">WWW</acronym>
Easy to author and update
<ruby>
<rb>WWW</rb>
<rt>World Wide Web</rt>
</ruby>
(putting aside the bad implementations in browser for these examples.)
[1]: http://goatee.net/2003/rss-history.html
[2]: http://www.w3.org/TR/cuap/
[3]: http://www.w3.org/TR/chips/
[4]: http://www.w3.org/QA/2006/02/ruby_annotation_to_change_the
--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
Received on Friday, 30 March 2007 05:43:54 UTC