Re: (code, sample output and keyboard/device input <code>, <samp>, <kybd>) part of my review of 3.12 Phrase elements

Robert Burns wrote:
> The <pre><code> example seems  like less than best practice. Why not 
> simply use <code style='white-space: pre;' >some code with 
> line-breaks</code> or even just <pre class='c-plusplus-code' >some c++ 
> code here</pre>. Either of those contain the same or more semantics 
> without adding another level to the hierarchy.
> 
> I endorse the suggestion of a @type or @codetype or @syntax attribute 
> for code[1]. The indication of a type could also be coupled with default 
> formatting for white-space. More advanced UAs could even provide 
> syntax-specific styling based on the type of code contained.

Please try to focus on describing the problems and use cases that you 
are trying to solve, instead of jumping straight to a solution.  From 
that, I can derive that there are possibly two problems that you are 
trying to solve.

1. A way to indicate the significance of whitespace in computer code. 
Significant whitespace should be presered in the default presentation, 
insignificant whitespace can be collapsed.

2. A way to achieve appropriate syntax highlighting for computer code.

For the problem of whitespace preservation, I not sure that really is a 
problem.  You haven't explained why using <pre><code> "seems like less 
than best practice".  Your statement seems like nothing more than a 
personal opinion.  Why is it a problem?  Why would your two suggested 
solutions be any better?

IMHO, <pre><code> is an existing solution that already works 
sufficiently.  XHTML2 introduces <blockcode>, presumably for the 
convenience of having a single element, but keeping our design 
principles in mind (particularly backwards compatibility and don't 
reinvent the wheel), I think the existing solution is fine.

For the problem of syntax highlighting, which has been briefly discussed 
earlier in the thread, I'm not sure adding an type attribute (or 
similar) actually solves that problem.

If a browser were to implement it, it would be required to know about 
the syntax of and have syntax highlighting rules for various languages 
including C/C++, Java, HTML, XML, PHP, Python, Perl, and dozens of others.

For HTML and XML, that might not be too difficult, considering that 
several browsers already have syntax highlighting for viewing source.

I know there are many editors that have syntax highlighting for such 
languages built in, but I don't believe it is trivial to implement. 
 From experience, different editors often handle syntax highlighting 
quite differently and often produce different results.  Dreamweaver, for 
example, quite often messes up syntax highlighting for HTML, 
particularly for erroneous markup.

For syntax highlighting to be implemented in browsers, it would need to 
be thoroughly specified for as many languages as possible and 
interoperably implemented among browsers.

Given the complexity of specifying such rules and implementing them, 
consider how difficult it would be to achieve interoperability and how 
much of an impact that would have on the code footprint and performance 
of the browser.  Syntax highlighting for computer code would only be for 
a niche market.  I'd estimate that well over 90% of users have no 
interest in code, and implementing such a complex system for a minority 
is hardly worthwhile.

However, it might be worth documenting how authors already solve this 
problem to provide syntax highlighting and it might be possible for the 
microformats community to address the issue.

Some pages use javascript to add the highlighting.  For example:

This uses <pre class="javascript">
http://dean.edwards.name/weblog/2007/04/packer3/

This uses <pre><code class="javascript">
http://livepipe.net/projects/event_behavior/

Maybe it would be possible to write a browser extension using similar 
scripts that could perform the syntax highlighting, particularly if the 
microformats community came up with hCode or something.  But, I really 
think more research and documentation of existing use cases and real 
world examples is needed before any good solution can be developed.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Friday, 20 July 2007 12:59:20 UTC