[whatwg] Physical quantities: <var> or ?

Sat Jan 21 05:13:46 PST 2012

2012-01-21 0:30, Ian Hickson wrote:

> On Tue, 26 Jul 2011, Jukka K. Korpela wrote:
[...]
>> I don’t think you have clarified whether <var>  is suitable for
>> physical quantities, but I guess you meant to imply it—even though
>> there is not a single example about markup for physical quantities.
>
> Given that the spec contains the exact example you gave (E=mc^2), and
> given that the definition explicitly includes "an identifier representing
> a constant" as one of the uses for the element, I have to disagree with
> your assessment.

Now that you have added that example, the text implies that <var> is the 
suggested markup for symbols of physical quantities. It is still 
somewhat odd that this is expressed via an example only, and the basic 
prose says: “The var element represents a variable. This could be an 
actual variable in a mathematical expression or programming context, an 
identifier representing a constant, a function parameter, or just be a 
term used as a placeholder in prose.” None of the examples covers 
symbols of physical quantities, and yet they are probably more common 
texts in general (as opposite to mathematics and programming) than the 
examples given.

>> On the other hand, it seems that it doesn’t really matter. The <var>
>> element has now been defined to have such a wide and vague meaning that
>> it is pointless to use it. There is little reason to expect that any
>> software will ever pay attention to <var> markup on any semantic basis.
>
> You seem to imply that there was reason to expect so before, which is
> certainly news to me!

I have rather been optimistic about future developments for markup 
elements that have been defined exactly enough to warrant meaningful 
semantics-based processing. For example, most of the uses mentioned in 
current text imply that <var> element contents should be kept intact in 
automatic language translation.

 > I would not really expect these elements to be used
> for anything other than styling hooks.

That might be realistic, especially there is no significant semantic 
clarification in sight in general. This raises the question why we could 
not just return to the original design with some physical markup like 
, , and together with that was added later. What’s the 
idea of wasting time in wondering which markup to choose, among several 
vaguely described alternatives, when it all ends up with being 
comparable to arbitrary author-named styles in word processing?

The advantage of using , , and is that they have defined 
default rendering (even in the absense of CSS) and universal support in 
browsers. Authors can still use classes if they like, and they can still 
change the rendering via CSS just as they can when some <fancy> markup 
is used.

>> So authors will use <i>  if they think italics is semantically essential,
>> and <var>  won’t be used much.
>
> That seems to be the status quo.

So why not simply define recommended and describe <var>, <cite>, 
, and <dfn> as deprecated but supported alternatives? This would 
make authoring simpler without any real cost. There’s little reason to 
tell authors to use “semantic markup” if we don’t think it has real 
effect on anything.

> However, some authors like the ease of maintenance that comes from using
> elements as a general classification mechanism and classes to provide
> fine-grained control, and it is mostly for them that HTML provides a
> variety of more specific elements like <var>.

This implies a burden on learning, teaching, and using HTML. Anyone who 
seriously tries to understand HTML will ask, for example, which of 
<var>, <cite>, , <dfn>, , , <abbr> he should use in 
particular situations.

Authors who wish to use classification may well do that with elements 
like as well. Then they just need to decide on their own classification.

>>>> Too bad there's no example of<var>  used in programming context. The
>>>> current wording suggests that it would be normal, when discussing
>>>> programming, to write, say, "Then we define the variable
>>>> <var>myFoo</var>  of type <code>fooType</code>  with initial value
>>>> <code>"Foo"</code>  - -", which really makes no sense, even if we use
>>>> both <var>  and <code>  for myFoo.
>>>
>>> Why does it make no sense?

Because <var> does not imply that the contents is computer code. Yet a 
variable name in programming is surely code if a type name or a literal 
is. And using <code><var>myFoo</var></code> is clumsy, and it makes the 
text appear in italics by default, which is probably unsuitable 
(monospace italics doesn’t work well). Why would an author use markup 
that by default causes rendering that he does *not* want, when there’s 
the option of using ?

>> Because it implies that in default rendering, identifiers of variables
>> appear in italics whereas identifiers of types or classes do not. Why
>> would anyone use extra <var>  markup when it has no other implications
>> than requiring extra CSS code to remove (when possible) italics?
>
> To enable easier maintenance of the markup and easy self-documenting
> styling, same as pretty much all of HTML.

I don’t see how <code><var>myFoo</var></code> would ease maintenance and 
be self−documenting, as opposite to e.g. myFoo.

Yucca

[whatwg] Physical quantities: <var> or <i>?