- 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