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

Summary:

• Editorial suggestions including some refinement of semantics
* @type attribute proposal for <code> and <pre>


Code <code>:

the <code> element makes mention of special meaning to @title when  
used with <dfn> but nothing else is said about that here. An example  
and explanation would be helpful.

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.  
I do not think the registered MIME types would be useful[2], but HTML  
could define its own keyword values for this attribute within the  
HTML namespace. This attribute might also be useful on <pre>  
considering the way <pre> is often used.

Sample Output (<samp>):

the <samp> element makes mention of special meaning to @title when  
used with <dfn> but nothing else is said about that here. An example  
and explanation would be helpful.

The draft currently says
"The samp element represents (sample) output from a program or  
computing system."

Should this make explicit mention of text output. In other words  
computers can output pixels, sound, refreshable Braille, embossing,  
and any other sort of output governed by mechanical, electrical, and  
thermal control system. I think we should restrict <samp> to textual  
sample output (however its presented: aurally, visually or  
tactilely). Adding the word text in there will also orient users to  
what this element means better than just  saying "output" alone.

Proposed wording:
"The samp element represents textual output from a program or  
computing system."

I also feel this would be better kept narrow in focus rather than  
expanding it to other areas. That is  we should keep this focussed on  
the sample text output from command-line programs or alerts or  
dialogs of graphical programs. Trying to express anything beyond that  
would require a more specialized element with more intricate semantic  
hooks.

In the second example, it's not clear what the meaning of the nested  
<samp> elements conveys. This nesting would suggest to me this was a  
computing system outputting HTML <samp> elements (if proper &lt;  
escapes were added), but I sense the draft authors had something else  
in mind. Some explanation should be appended.

<samp class="prompt">jdoe@demo:~$</samp> <samp class="cursor">_</ 
samp></samp></pre>

Keyboard input <kbd>
I don't think we should expand the semantics of <kbd>to include voice- 
commands. If we feel there's a need for that semantic, I think it  
would be better to add a new element. Adding anew element shouldn't  
create significant problems since a voice-caommand has no common  
presentational idiom. If there is a need for epxressing voice-command  
semantics, then we should not hesitate to add an element for voice- 
command: such as <voicecmd> . The presentation of this element would  
not suffer compared to using the <kkd> element, so it will be  
compatible with common browsers.

{Aside: the issue of not expanding <kbd> to include voice-commands is  
not the same as my earlier proposal to clarify <var>. In that case,  
<var> represents a variable: a variable that can literally stand in  
for anything. So it's not a change in the semantics its a  
clarification in adding prose and a @type attribute to facilitate its  
use as a variable.. Its like a term that's introduced and points to  
some thing: giving it a name. Like x = 10 makes x stand in as a term  
for the number 10. Using z = the java class "string". Now <var  
type='class'>z</var> is a class. The broader semantics is implied by  
the term. With <kbd> the broader semantics of all input commands  
issued to a computer do not really fit. Could <kbd> refer to a punch- 
card? Would it refer to a mouse movement? <kbd>left-click</<kdd>, for  
example. I think its both too much of a stretch and not really a  
semantic with a great demand for an facility in HTML5. In this sense  
<kbd> is more like <samp> and I think its meaning should not be  
changed even if that change is an expansion. I don't think there is a  
strong need to express those semantics we would be expanding them  
into; and if there was, it would be better to introduce a new element  
(or new elements) to express those semantics (with better mnemonics). }

The second example for <kbd> also supports the idea of including  
explicit markup for writing about GUI constructs: including tty  
presented menus as I suggested in my review of <var>[3]. The use of  
<kbd> there is awkward.

<p>To make George eat an apple, select
     <kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</ 
samp></kbd></kbd>
</p>

To me, the <kbd> would suggest arrowing or selecting <kbd>f</kbd> to  
select the file menu and the menu itself should have a completely  
different semantic facility


[1]: <http://lists.w3.org/Archives/Public/public-html/2007May/1176.html>
[2]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/0126.html>
[3]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/0936.html>

Received on Friday, 20 July 2007 06:55:55 UTC