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

Hi Andrew,

I think we're nearly in complete agreement. The issues you raise with  
what I wrote are nearly always just a misunderstanding of what I  
wrote. I'll explain below:

On Jul 21, 2007, at 2:48 PM, Andrew Sidwell wrote:

>
> Robert Burns wrote:
>> On Jul 20, 2007, at 7:53 PM, Lachlan Hunt wrote:
>>> Ignoring the syntax errors and assuming the code was rendered in
>>> purple, sure, you can give the browser guidance in how to convey the
>>> semantics of your class name to the user using stylesheets.  But  
>>> that
>>> doesn't mean the browser has understood the meaning of the class  
>>> name
>>> itself, or that the class name carries any particular meaning.
>>
>> It certainly does mean the class name carries meaning. If my meaning,
>> as the author, was to denote C++ syntax code. And you as the user
>> understand that purple text as C++ code.
>
> The example:
>
>   <pre class="cplusplus"> i = 10; </pre>
>   <style>.cplusplus { color: purple; }</style>
>
> That code could equally well be in C, or Lua, for all I know.  To find
> that this was C++, I would have to:
>  1. be told elsewhere, in English, that the code is C++, or
>  2. see C++-specific syntax elsewhere in the colour purple, and infer
>     that other similarly-coloured code is also C++.

I would imagine if you read the source, t hat might be a third way  
you would figure it out.  Remember we're comparing this to using  
<code> alone or <pre> alone or <code> with <pre>. The <pre> element  
is basically adding nothing  (except perhaps adding default  
presentation if the CSS in embedded in the document  somehow stops  
working). So <code> alone has very little distinct presentational  
hints either. You would either need to read the HTML source or be  
told somewhere in English what the <code> presentation meant.

> Note that nowhere is the class name used outside of the source code.
> That is, the class name provides no meaning, but the presentation
> (combined with inference) does.

Agreed. However, UAs commonly provide a mechanism to view source  
HTML. An audience consuming C++ code would likely be an audience  
capable of understanding HTML. So I don't think we should discount  
HTML source reading as another way to discern meaning. Browsers have  
been slow to expose certain meaning in HTML that's already specified  
in HTML4 (<link> for example) that therefore requires users to read  
the source to "discover" what meaning is hidden by the UA.

> Why does a class name not mean what you use it to mean?  Well, it  
> does,
> but only very occasionally.  Obviously, to you, it means what you  
> use it
> to mean.  (I could use the word "plu" to mean "plumber", but it would
> only mean that to myself; to everyone else, the word would be opaque.)
> Then, if you agree with other people that your class name means
> something (e.g. you start a cult of people who use the word "plu"
> instead of "plumber"), then it means that thing to those people.
>
> Another group may use the class name differently (e.g. they might use
> "plu" to mean "plum"), in which case the meaning is still lost.  In
> other words, for a class name to have a meaning, you must have a bunch
> of people using it in the same way -- that is, a microformat.


These examples show we're mostly in agreement here. You introduced  
ambiguity  into the class names to make the opaque compared to  
cpluplu that is harder to misunderstand. I completely agree with you  
on those examples. They would require prior understanding through an  
authoring community (like microformats.

>>>> Would you prohibit authors from writing a document like this?  
>>>> Unless
>>>> I get prior approval from some microformat politburo, I'm  
>>>> prohibited
>>>> from writing a document like this? Would I be purged for this
>>>> markup? :-)
>>>
>>> What?  No!  I do not understand your point.  All I'm saying is that
>>> class names by themselves don't convey any particular semantics
>>> without an agreement of their meaning (either explicit or implied),
>>> and that nothing useful can be done with them by default, beyond the
>>> presentation and behaviour specified by the author.
>>
>> No, what you're saying in a long-winded way is that class names do  
>> not
>> convey any particular semantics, without a prior agreement  EXCEPT to
>> humans. However, if an author wants to communicate specifically to
>> humans, then a class name does convey meaning. Which is all I was
>> trying to say.
>
> In what way are two people who both understand and use English, and  
> both
> know the name of a programming language, not making use of a prior
> agreement?

Here we're in total agreement. English and all sorts of cultural  
processes constitute a form of "agreement" that makes communication  
possible. The issue raised by Lachlan and other was that a prior  
agreement above and beyond those cultural condition would be required  
for a class name like cpluplu with a presentational idiom assigned to  
it by an author to carry any meaning. My contention was that such a  
class name could carry meaning based on the cultural environment  
already established: without microformats.

I do not mean to discount the microformats approach. I think that can  
be a very powerful tool. I just wanted to make clear that we have  
many ways to use class names semantically even without another formal  
umbrella group. I read HTMl4's intention for class names to be used  
in this semantic way.

The other point that bears repeating is that presentation is always  
an important part of conveying meaning. Certainly as Anne said  
earlier CSS is an optional language However, presentation is not  
optional. If HTML is not presented (even as source HTML), then it  
cannot convey its meaning. We only have very few presentational  
idiom's that relatively unambiguously convey meaning: <p>, <em>,  
<ul>, <ol>, <h1> – <h6>, <table>, etc. Many other facilities in HTML  
do not have such unambiguous  presentation (here, I do not mean  
machine unambiguous, but rather unambiguous with some human applied  
heuristics): <code>,  <var>, <dfn>, <cit>, etc. Without some author  
intervention here, it's likely these will not be clearly  
distinguished sufficiently from other presentation. Or their  
presentation will be easily confused with others semantics. I also  
think that even though CSS is optional we should think of it as our  
close cousin. HTML without CSS would be nearly useless to most  
people. The use of HTML paired with CSS has become nearly complete.  
We should assume authors have CSS available (or some equivalent) to   
differentiate meaning for many of the semantics already in HTML and  
any we may consider adding (e.g., <copyright> or <important> or  
<propern>): even, as I suggested earlier, as an HTML5 author  
downloadable default stylesheet.

Take care,
Rob

Received on Saturday, 21 July 2007 22:04:30 UTC