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

On Jul 20, 2007, at 7:58 AM, Lachlan Hunt wrote:

>
> 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.
>

These two paragraphs are unconnected. The second paragraph is an  
endorsement of an earlier proposal that has already described use  
cases and has had some discussion. I linked to the relevant emails on  
that in my review. The first paragraph is simply an editorial  
suggestion. The use of multiple nested elements adds nothing in  
semantics to the document that cannot be done in a more  
straightforward way. This idea that we should pretend like CSS does  
not exist seems bizarre to me. Imagine if we were on the CSS WG,  
would we then need to pretend that no semantic languages existed to  
which we could apply CSS? The proliferation of CSS is what has freed  
HTML to focus on semantics. Does that mean we have to remove every  
last semantic element from HTML? No, certainly not. However, it also  
doesn't mean we should pretend that authors have no choice but to  
present their content in 1995-style Mosaic with black text on a grey  
background. We're all using CSS. There's little reason to pretend  
we're not (there's nothing to be embarrassed about).

> 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.

OK

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

That's a presentational detail, that might be a great benefit. The  
use-case from my perspective is to be able to attach meaningful  
semantics to a code element that is an obvious next question when you  
tell someone this is some code (i.e., the next question is: what kind  
of code).

How it is presented is an interesting question, but we are working on  
HTML (a largely semantic language) so let us not shy away from  
providing semantic facilities that author's can use.

> 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?

It's just based on an unnecessary crippling of the author to stick  
only with HTML when CSS would be a better solution.

> 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.

So is just <code> or just <pre> as I described.

> 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.

It doesn't need to. A presentation layer can solve that problem..  
However, it would help any such presentation layer to have some  
specific information about the syntax highlighting it should apply.

> 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.

If it implemented it, the browser would need to know the syntax of  
the language. If it didn't happen to know the language designated by  
the @tyype attribute, it would resort to plain text or whatever CSS  
should be applied to the element.

> 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.

No, not at all. The absence of syntax highlighting does not change  
the meaning of the code in the same way that the absence of quotation  
marks around <q> changes that meaning.

> 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.

It might only be delivered to a niche market. Some would say the  
inclusion of any programming code ins meant for a niche market, yet  
we have an element for it in HTML.

> 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.

This seems like a lot of extra work, if all I want to do as an author  
is tag my code with tis code type. Again, let's make simple thing  
really easy and difficult things possible.

Take care,
Rob

Received on Friday, 20 July 2007 14:05:09 UTC