A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Generic Metadata Mechanisms: Difference between revisions
Lachlan Hunt (talk | contribs) |
|||
Line 58: | Line 58: | ||
* Con: Makes it harder to select individual property/value pairs through CSS or the DOM. (Might required dedicated APIs... Ugh.) | * Con: Makes it harder to select individual property/value pairs through CSS or the DOM. (Might required dedicated APIs... Ugh.) | ||
= Related Proposals, Research and Discussions = | |||
* [http://www.mail-archive.com/[email protected]/index.html#11037 WHATWG Discussions] | |||
* [http://microformats.org/wiki/grddl GRRDL (Transformations of XHTML to RDF)] | |||
* [http://www.xanthir.com/rdfa-vs-crdf.php RDFa vs. CRDF (Cascading RDF Proposal)] | |||
* [http://research.talis.com/2005/erdf/wiki Embedded RDF Wiki] | |||
* [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF in HTML (Embedded RDF Examples)] | |||
* [http://en.wikipedia.org/wiki/Semantic_web Wikipedia page on Semantic Web] | |||
* [http://microformats.org/wiki/what-are-microformats What are Microformats? (microformats.org)] |
Revision as of 02:22, 1 September 2008
There have been some requests for introducing generic metadata mechanisms into HTML5.
To help determine what we would need to add, and whether it is worth adding anything, we have to come to an understanding of what the goals and requirements are of such a proposal.
Please document arguments with links to supporting research or links to other wiki pages detailing the anecdotal evidence for or against particular aspects of the goals and requirements.
Goals
What is the problem we are trying to solve?
...
Who faces this problem?
Nobody
...
A few people
...
Everybody
...
Requirements: If we assume that we are going to address this need, what do we need to provide?
Please list each requirement in its own subsection so that arguments pro and con and links to supporting research can be included.
The DOM has to be consistent between HTML and XHTML representations
- Pro: If it isn't, then migrating between the two becomes complicated.
The syntax has to be something that Web authors can easily deploy
- Pro: If authors can't deploy this, then it won't get critical mass and won't matter
- Con: Tools will be used to deploy this. It'll mostly be used by big sites like Facebook. So individual authors don't matter.
It has to have both a way to abstract it from the HTML and a way to include it inline
- Examples: Javascript and CSS
- Pro: Inline it may be quicker for non-professional developers to use and adopt.
- Pro: Abstracted it is more flexible for professional developers, does not clutter the HTML, and gives it more space to develop such as style did once it was abstracted from HTML.
- Con: More complicated than having either.
Inline it should follow the conventions of CSS and Javascript
- Javascript example: onclick="doSomething();doSomethingElse();foo();"
- CSS example: style="width:300px;height:200px;border:1px solid #ccc;font-size:1em;"
- Pro: The properties are grouped together and in the case of style only uses one attribute name. This keeps the markup cleaner and better organized than creating multiple attributes directly on the elements. Compare with how we added style to elements before CSS.
- Con: Makes it harder to select individual property/value pairs through CSS or the DOM. (Might required dedicated APIs... Ugh.)