- From: Robert Burns <rob@robburns.com>
- Date: Tue, 24 Jul 2007 08:54:09 -0500
- To: public-html WG <public-html@w3.org>
Regarding specifying syntax type on CODE element,
on Jul 24, 2007, at 6:04 AM, Ben Boyle wrote:
>
> I think it's already been mentioned but it sounds like a good thing to
> take up over at microformats.org:
> http://microformats.org/wiki/code-brainstorming
One issue I wanted to raise about microformats is that I think if we
find something useful in them, we should consider adding similar
features as an integral part of hTML. For example, if microformats
find it useful to add pre-delineated class names to an element to add
semantics, I don't think we should simply pat them on the head and
say great idea (there cowpath paved). Rather we should consider
whether adding something like type='QNAME would be useful considering
a class name was useful. The microformats community resorts to class
names and other facilities like that because they're not the drafters
of HTML. Since we are the drafters of HTML, we should try to make
these cowpaths integral to the language. The makes it easier for new
cowpaths to make use of @class.
In our role as drafters of a new HTML specification, we have the
ability to create new element types, new attribute types, incorporate
QNAMES into HTML, etc. If there's a need for this we should consider
it. Clearly we do not want to get out of hand and create thousands of
new elements or let attributes get out of control. However, there are
many simple enhancements we can make that lifts some of the burden
off of the microformats communities.
Some of what the microformats communities do is perhaps too
specialized for HTML to handle itself. Things such as vcard or vcal
microformats could simply be handled by <object type='text/x-
directory' data='avcardfile.vcard' > for example. Other things such
as providing more semantic information about <code> or other types,
we can incorporate into HTML proper. Some mciroformat inspired issues
I think we should deal with integral to HTML are:
• routine non-fiction issues of:
• citing sources
• attributing quotations and ideas
• providing reference/ source lists
• integrating subordinate text typically presented as footnotes,
endnotes, etc.
• semantics for defining terms (as I addressed in my reviews)
To name just a few. Others are also already dealt with in the current
draft.
Take care,
Rob
Received on Tuesday, 24 July 2007 13:54:27 UTC