[whatwg] [WA1] Literals and Actions, comments on inline markup

Literals
--------

   There doesn't seem to be any appropriate markup for literals in HTML.

   For example:

      The words 'elude' and 'allude' are frequently mixed up.

   The formatting for such elements varies freely: I've seen single quotes
   (which I prefer), double quotes, and italics. It is therefore stylistic,
   and should be controlled (or controllable) with CSS.


Actions
-------

   I can't figure out any appropriate markup for things like

      The pattern, I said, not the text! *runs away*
                                         ^^^^^^^^^^^
                                            this.

   It's not used in formal specs or professional web apps, but,
   it's frequently used in less formal discussions.


Links (<a>)
-----------

   * # If the a element has no href attribute, then the element is a placeholder

     This is nice.

   * Scanning quickly through the texts for <link> and <a>, I didn't see a
     discussion of their differing semantics. Chris Hoess sums up an explanation
     you gave to him four years ago in bug 87428:

     https://bugzilla.mozilla.org/show_bug.cgi?id=87428#c43

     "Ian actually managed to convince me last night on IRC that there's a reason
      to have different UI for <link rel="foo"> and <a rel="foo">.  The first is
      a page link; the relationship denoted in the link element applies for the
      whole page. The second is a context link; the relationship denoted applies
      to the immediate context of the anchor element."

     I would like to see this mentioned in the spec.

   * # The type attribute ... is purely advisory.

     Should it factor into the algorithm for determining a file's content type
     when meta-information is not there, or is that outside the scope of this
     spec?

   * One of the previous uses of <a> was to mark a destination anchor with
     'name'. For the most part, the 'id' attribute has made this use obsolete.
     I'm wondering, though, what would be the appropriate WA1 markup to use
     for anchoring to a bit of text that is not otherwise marked-up?

     For example, I use <a> to mark sentence fragments in
       http://fantasai.inkedblade.net/weblog/2003/marketing/tab-logic#what
     so that I can refer to them in the discussion. (I'll admit the styling
     is not well-chosen... numbering them with CSS would have been ideal.)


Emphasis (<em>)
---------------

   # The em element represents stress emphasis of its contents.

   I would render 'stress emphasis' as 'emphatic stress'.

   The example, btw, is *excellent*.


Strength (<strong>)
-------------------

   Subtle change from HTML4 semantics, and I think I approve. The example,
   again, is excellent.

   The contrast between
     # Changing the importance of a piece of text with the strong element
     # does not change the meaning of the sentence.
   and
     # The placement of emphasis changes the meaning of the sentence.
   is brilliant.


Highlighting (<m>)
------------------

   # The m element represents a run of text marked or highlighted.

   This is cool.

   Another use for it would be in highlighting important phrases in
   documents optimized for skimming. (Or buzzwords in marketing hype
   like at the top of
     http://fantasai.inkedblade.net/weblog/2003/marketing/about
   , not that I approve of such language.)

   I'd say the distinction between highlighting and <strong> & <em>
   is that highlighting does not change the reading of the text when
   you're reading straight through, it just helps you find the
   bits you should pay attention to.


Small Print (<small>)
---------------------

   # The small element represents small print (part of a document often
   # describing legal restrictions, such as copyrights or other
   # disadvantages), or other side comments.

   Is <small> appropriate for the example at the end of
     http://fantasai.inkedblade.net/weblog/2003/big-small/
   ?

   # Note: The small element does not "de-emphasise" or lower the
   # importance of text emphasised by the em element or marked as
   # important with the strong element.

   Does <small> de-emphasize the text at all? This paragraph implies
   that it does, except within <em> or <strong>, but it is not clear
   from the definition.


Defining Instances (<dfn>)
--------------------------

   # The paragraph, definition list group, or section that contains the
   # dfn element contains the definition for the term given by the
   # contents of the dfn element.

   I have very often seen defining instances whose definition is limited
   to just the sentence in which it appears. The rest of the paragraph
   is related discussion, of course, but nothing I would pull out into
   a glossary.

   Also, this sentence implies that <dfn> should be used with <dl>, but
   I don't see what you mean by that implication. There are no examples
   with <dfn> in the <dl> section. If I were to take that idea and run
   with it, I'd say that if a <dt> contains a <dfn>, then the <dd> is
   defining the term contained within the <dfn> only; the rest of the
   <dt> is extra meta-information. E.g.

    <dt><dfn>term</dfn> (t?rm)</dt>
    <dd>...</dd>


Instance of Term (<i>)
----------------------

   # The i element represents an instance of the use of a term, such as
   # a taxonomic designation, technical term, an idiomatic phrase from
   # another language, or similar.

   I think this is a great definition for an element we really need to
   have in HTML.

   However, I am not convinced that leaving HTML with no purely
   presentational tag for italics is a good idea. That leaves nothing
   for people who do not have the time, opportunity, or patience to
   learn/semantic/ HTML markup and for simplistic authoring UAs. <b>
   and <i> are often the first -- or only -- tags people learn, and
   they are among the few tags understood by most commenting systems.
   Whatever semantics you declare here for <i> will be flagrantly
   ignored by all but a minority of authors. How is defining <i>'s
   semantics this way useful?


Inline Code Fragments (<code>)
------------------------------

   The example should be of an inlined code fragment, not a block-inline
   tag combination pretending to be a block element.


Sample Output (<samp>)
----------------------

   # Nested samp and kbd  elements allow for the styling of specific elements
   # of the sample output using a stylesheet.
   #
   # <pre><samp><samp class="prompt">jdoe at mowmow:~$</samp><kbd
   # >ssh demo.example.com</kbd>
   # Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1
   # Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189
   # #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown
   # <samp class="prompt">jdoe at mowmow:~$</samp> <samp
   # class="cursor">_</samp></samp></pre>

   This is an interesting example. The outer <samp> can be interpreted as
   "output of terminal" and the inner one as "output of shell", which seems
   all well and good.

   However, what if I wanted to colorize the output of Mozilla's layout
   regression tests?

   Running verify test for E:\moz_src\mozilla\layout\html\tests\block\rtest.lst.
   Writing regression data to
     E:\moz_src\mozilla\layout\html\tests\table\core\verify\standards1.rgd
   Comparing to regression data from
     E:\moz_src\mozilla\layout\html\tests\table\core\baseline\standards1.rgd
   frame bbox mismatch: 0,26437,4824,600 vs. 0,26437,4872,600
   Node 1:
     TableOuter(table)(144) 0x10004 0,26437,4824,600, |null attr|-16777216|left:
     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw top:
     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top: 1[0x1]enum
     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum 0|1
     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw  Null
     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0 8
     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
   Node 2:
     TableOuter(table)(144) 0x10004 0,26437,4872,600, |null attr|-16777216|left:
     0[0x0]tw top: 0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 0[0x0]tw top:
     0[0x0]tw right: 0[0x0]tw bottom: 0[0x0]tw  left: 1[0x1]enum top: 1[0x1]enum
     right: 1[0x1]enum bottom: 1[0x1]enum  left: Null top: Null right: Null
     bottom: Null  left: Null top: Null right: Null bottom: Null  1[0x1]enum 0|1
     1 [none]|left: Auto top: Auto right: Auto bottom: Auto  Auto  0[0x0]tw  Null
     Auto  0[0x0]tw  Null  0 Auto  |0 0 0 Normal  Normal  0[0x0]tw  Normal  |0 8
     1,000000 0 0 0 0 0 0 0 0 0 0 0 [none]|0 0 0 -1 1 |0 0 0 Null
   frame bbox mismatch: 0,0,4824,600 vs. 0,0,4872,600

   (This makes more sense if it's not wrapped. See
     http://www.mozilla.org/newlayout/doc/regression_tests.html
    But not much more.)

   I would want to mark up
     - the Running veryify test line
     - the Writing regression data line
     - the Comparing to line
     - the filenames in each of those
     - the frame bbox mismatch label
     - its vs. value
     - the node labels
     - the frame type (TableOuter(table))
     - each name-value pairing in the output line

   However, it does not seem to me that marking these with <samp> would be the
   right thing to do any more than marking up function names, variable names,
   and keywords in a code sample with <code> would be the right thing to do.
   Either those are both right, or they're both wrong.

   Please specify.


User Input (<kbd>)
------------------

   # The kbd element represents user input (typically keyboard input,
   # although it may also be used to represent other input, such as
   # voice commands).

   Can we have some examples for marking up GUI elements? E.g.

     Don't press the Emergency button.

     Go to Tools > Options... and select the General tab. Change
     the Indentation Type radio from Tabs to Spaces, check the
     Auto-Indent box, and type 4 into the Indent Spaces box.

   Those should be marked up so that one can use a style sheet to
     - make "Emergency" look like a button
     - display "Tools" and "Options" in the menu font
     - make "General" look like a tab
     - make "4" look like it's typed inside a text input
     - and use the appropriate label fonts for "Indentation Type",
       "Tabs", "Spaces", "Auto-Indent", and "Indent Spaces".

   # When the kbd element is nested inside another kbd element, it
   # represents an actual key or other single unit of input as
   # appropriate for the input mechanism.

   So "Press the Esc key" would be marked up as
     <p>Press the <kbd><kbd>Esc</kbd></kbd> key</p>
   ?


Superscripts and Subscripts (<sup> and <sub>)
---------------------------------------------

   # marking up mathematical, but

   "mathematical" should be replaced with a noun.


Quotes (<q>)
------------

   * You should probably add some notes on presentation, esp. wrt
     quote mark generation.

   * You need to explain that <q> should only be used for actual
     quotations, not as a shortcut for &ldquo; and &rdquo;. (I've
     seen it abused that way, but I forget where..)


General
-------

   Overall, I'm really, really impressed with what you've done here.

   One nit: Please provide actual titles for the sections (as I have
   done here) rather than just putting the element name. (But don't
   leave out the element name either.)


~fantasai

Received on Wednesday, 11 May 2005 20:50:25 UTC