W3C home > Mailing lists > Public > www-html@w3.org > November 2003

Re: The <blockcode> and <l> elements

From: Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
Date: Fri, 7 Nov 2003 13:16:58 +0100
To: www-html@w3.org
Message-Id: <200311071317.01717.Christian.Hujer@itcqis.com>

Hash: SHA1

Hi Lachlan, dear list members,

Am Freitag, 7. November 2003 06:24 schrieben Sie:
> >> 1. ELEMENT blockcode (l)* OR
> >
> >I wouldn't change it.
> >Imagine:
> ><blockcode>
> ><h>\chapter{introduction}</h>
> ><p>This is really interesting stuff.</p>
> ></blockcode>
> >
> >Marking up LaTeX or XHTML using XHTML in a <blockcode/> while also
> >demonstrating the results of the markup.
> Why not use:
> <blockcode>
>     <l class="h">&lt;h&gt;\chapter{introduction}&lt;/h&gt;</l>
>     <l class="p">&lt;p&gt;This is really interesting stuff.&lt;/p&gt;</l>
> </blockcode>
>   Using class selectors and CSS, the formatting can be demonstrated without
> losing the semantics of code.
Uh, oh, so why not drop all those elements anyway and use <span/> and <div/>
only? There's no need for for <section/>, <l/>, <h/> anyway... ;-)
I definitely see stronger semantics in elements than in classes. If classes 
provided all the semantics we need, why do we have elements then?

By the way, the &lt;h&gt; is superflous. The example should not demonstrate
/what/ xhtml markup corresponds to the LaTeX markup, just to translate the
LaTeX markup into xhtml for structure. The <h/> in my example was intended to 
make \chapter{introduction} in fact a heading, not to be shown, otherwise I'd 
have used a CDATA section.

>   However, demonstrating output should be done using the <samp> element, or
> the future <blocksamp> element, which, as I can gather from previous
> threads, might be included in the next draft.
1. A full LateX source or snippet semantically is <blockcode/> as long as it
hasn't just sample character, I think, in which case <blocksamp/> might be 
more appropriate, if it is introduced, but a full source would be 
<blockcode/>, and I'm sure you're glad I didn't include a full 14678 lines 
latex source but just 2 lines for terseness ;-)
2. In general, I like the idea of a <blocksamp/> element.
3. I see the danger of an endless philosophical discussion about when to use
<blockcode/> / <code/> vs. <blocksamp/> / <samp/> similar as we had it with
<abbr/> vs. <acronym/> before.
4. For the given example, it doesn't really matter at all wether it's 
<blocksamp/> or <blockcode/>.

> <snip/> (some example code)
> > I don't see why there mustn't ever be any markup within <blockcode/>
> >outside <l/> elements.
> >For instance, in Java, I could want to use the class declaration as a
> >blockcode heading:
> ><blockcode>
> ><h><span class="modifier">public</span> <span
> > class="modifier">class</span>
> >
> >Hello {</h>
> ><!-- ... -->
> ></blockcode>
>   Semantically, I don't think this would be a heading.
But since you are not the author of the document, you can only guess that but 
you cannot know that. And maybe your guess is wrong.

>  Presentationally it
> might be, which can be done using class selectors and CSS as described
> above.
But it also might semantically be a heading.
I might want to title a chapter <h>public class Hello {</h>. Imagine an online
resource full of code examples. What's more appropriate as a heading for Java
code than the class declaration of the main Java class?
So why not give such a resource a Java-ish style by using such section
    <h><code>public class Hello {</code></h>
    <!-- ... --->
But if they all start with their listing, why repeat the first line again?

So why not use:
        <h>public class Hello {</h>
        <!-- ... -->
(other markup omitted for terseness)

Currently there's no restriction in XHTML that requires headings to be used as
top-level of sections only. And I definitely wouldn't change that.

Of course, usually it's much easier to use <h/> as a first child element of
<section/> only, for CSS as well as for XPath.
But the above example isn't too difficult for CSS or XPath to cope with.

>   OR, place the heading ouside the blockcode element:
> <h>Java Class Header</h>
> <blockcode>
>     <l>...</l>
> </blockcode>
>   The bottom line is that all code is plain text.  Many editors do present
> code using different colours (which can be done using <span>, or other
> inline elements), but, semantically, it's still all plain text.
Semantically, most text is all plain text but still contains hyperreferences
and other meta information.
So where's the big difference between an emphasisis vs. normal text in human
language or a keyword vs. a non keyword in a computer language ;-)
Or between a link from a term to its definition in a human language sentence
on one side and a link from a keyword to its definition in a computer
language on the other side.
Also, in a source code listing or example, it must be possible to semantically
corretcly highlight important parts using <em/> or <strong/> or to give
expantions for abbreviations using <abbr title=""/>. Markup does make sense
in <blockcode/>. But how to decide what markup makes sense and what markup 
You could say "Inline makes sense, block and heading don't", but I'd respond 
I'd want certain sections of the source code to be in their own <div/> 
elements for structural reasons.
So why not just accept that for some people, it makes sense to markup some
lines of a source code as headings?

Okay, another example where it does make sense to use <h/> in <blockcode/>.
I might want to publish a Java source code in HTML so syntax highlightning and
hyperreferences from method calls or objects to their method or class
definitions are possible.
<h>Sources of project X</h>
<h>Table of contents</h>
    <li href="#class_A">public class A {</li>
    <li href="#class_B">public class B {</li>
<h id="class_A">public class A {</h>
<h>    public void someMethod() {</h>
<l>        <a href="#class_B">B</a> b = new <a
<l>    }</l>
<h id="class_B">public class B {</h>
<h id="constructor_B__B_void">    public B() {</h>
<l>        if (C.debug) {</l>
<l>            System.err.println("new B constructed");</l>
<l>        }</l>
<l>    }</l>

Another point of view is given by a comparison with <blockquote/>.
A blockquote must be able to contain headings.
Those headings in some cases aren't headings in context of the containing
document, but just headings valid in the context of the <blockquote/>.
Why should <blockcode/> differ so much from that?

And last but not least do not forget that the border between computer language
and human language is not strict but a fluent one.
Think of perl lyrics.
Basically, perl lyrics are both, computer programs and human readable texts.
So both, <blockcode/> and <blockquote/> are valid markups. I'd choose
<blockquote/> for the just parsable perl lyrics and <blockcode/> for those
perl lyrics that even compile and run and do something useful. Or I'd always
choose <blockcode/> because I'm more technically oriented. But still I want
to be able to markup headings in perl lyrics as such, while still retaining
the information that it's a source code of a computer program in markup.

Still, if <h/>, <blockcode/> and some other elements in general do not make so 
much sense as children of <blockcode/>, think about that <div/>, <l/> and 
Inline make sense, and how complicated the changes in the content model would 
have to be to reflect all this.

So finally:
I definitely cannot agree with your suggested restrictions on <blockcode/>'s
content model.
You cannot convince me of your view.
I often enough markup source code in xhtml and I do not want to see
restrictions on <blockcode/>'s content model compared with that of <div/> or
<section/> or <blockquote/> because that would force me to use something else
than <blockcode/> to markup listings. Thus in many cases I could not use 
<blockcode/> for the purpose it's been invented for, making it completely 
useless. If there's an element with a special markup purpose I'd like to use 
it for that purpose.

- --
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

Received on Friday, 7 November 2003 07:19:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:06 UTC