[whatwg] [WA1] Literals and Actions, comments on inline markup
fantasai
fantasai.lists at inkedblade.net
Wed May 11 20:50:25 PDT 2005
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 “ and ”. (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
More information about the whatwg
mailing list