<4F1ABA0A.8040706@cs.tut.fi>
Current votes: None.
2012-01-21 0:30, Ian Hickson wrote: > On Tue, 26 Jul 2011, Jukka K. Korpela wrote: [...] >> I don=E2=80=99t think you have clarified whether <var> is suitable fo= r >> physical quantities, but I guess you meant to imply it=E2=80=94even th= ough >> there is not a single example about markup for physical quantities. > > Given that the spec contains the exact example you gave (E=3Dmc^2), and > given that the definition explicitly includes "an identifier representi= ng > 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=20 suggested markup for symbols of physical quantities. It is still=20 somewhat odd that this is expressed via an example only, and the basic=20 prose says: =E2=80=9CThe var element represents a variable. This could be= an=20 actual variable in a mathematical expression or programming context, an=20 identifier representing a constant, a function parameter, or just be a=20 term used as a placeholder in prose.=E2=80=9D None of the examples covers= =20 symbols of physical quantities, and yet they are probably more common=20 texts in general (as opposite to mathematics and programming) than the=20 examples given. >> On the other hand, it seems that it doesn=E2=80=99t really matter. The= <var> >> element has now been defined to have such a wide and vague meaning tha= t >> 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=20 elements that have been defined exactly enough to warrant meaningful=20 semantics-based processing. For example, most of the uses mentioned in=20 current text imply that <var> element contents should be kept intact in=20 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=20 clarification in sight in general. This raises the question why we could=20 not just return to the original design with some physical markup like=20 <i>, <b>, and <u> together with <span> that was added later. What=E2=80=99= s the=20 idea of wasting time in wondering which markup to choose, among several=20 vaguely described alternatives, when it all ends up with being=20 comparable to arbitrary author-named styles in word processing? The advantage of using <i>, <b>, and <u> is that they have defined=20 default rendering (even in the absense of CSS) and universal support in=20 browsers. Authors can still use classes if they like, and they can still=20 change the rendering via CSS just as they can when some <fancy> markup=20 is used. >> So authors will use <i> if they think italics is semantically essenti= al, >> and <var> won=E2=80=99t be used much. > > That seems to be the status quo. So why not simply define <i> recommended and describe <var>, <cite>,=20 <em>, and <dfn> as deprecated but supported alternatives? This would=20 make authoring simpler without any real cost. There=E2=80=99s little reas= on to=20 tell authors to use =E2=80=9Csemantic markup=E2=80=9D if we don=E2=80=99t= think it has real=20 effect on anything. > However, some authors like the ease of maintenance that comes from usin= g > 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=20 seriously tries to understand HTML will ask, for example, which of=20 <var>, <cite>, <em>, <dfn>, <i>, <span>, <abbr> he should use in=20 particular situations. Authors who wish to use classification may well do that with elements=20 like <i> as well. Then they just need to decide on their own classificati= on. >>>> 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 us= e >>>> 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=20 variable name in programming is surely code if a type name or a literal=20 is. And using <code><var>myFoo</var></code> is clumsy, and it makes the=20 text appear in italics by default, which is probably unsuitable=20 (monospace italics doesn=E2=80=99t work well). Why would an author use ma= rkup=20 that by default causes rendering that he does *not* want, when there=E2=80= =99s=20 the option of using <span>? >> 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=E2=80=99t see how <code><var>myFoo</var></code> would ease maintena= nce and=20 be self=E2=88=92documenting, as opposite to e.g. <span class=3D"code=20 var">myFoo</span>. Yucca