- From: Robert Burns <rob@robburns.com>
- Date: Fri, 20 Jul 2007 01:55:48 -0500
- To: HTML WG <public-html@w3.org>
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 < 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