Re: Introduce <term> element

Preston L. Bannister schreef:
> Please, no - on "<term>". 
>
> Can we exercise some restraint on the "might be useful" features?  I 
> do not see anything here of significant value.
>
> What are the semantics of <term>?  Lacking any sort of context - 
> essentially none.  Is this a scientific term?  A technical term?  A 
> vulgar term?  How should it be presented?  Are there attached 
> behaviors (links to definitions, fly-over panels, etc.).  Do the terms 
> belong in an index (and if so which)?  The answer is simply that we do 
> not know.  If the formatting is at all inconsistent across browsers, 
> then the explicit styles will have to be defined by the programmer.  
> If there is more than one variant with "term" semantics, then class 
> attributes will have to be assigned.  At that point it is doubtful we 
> are at all ahead of simply using a <span> with class.

It carries exactly the same semantics as <dfn>, with the difference 
being that <dfn> is only used on the defining instance of that term, and 
<term> can be used on the other instances.

I concluded that there was a need for <term> after looking at the 
examples for <i> and <b> in the WHATWG specification, and noticing that 
more than half of the examples were really about terms. As also stated 
in my original post. That is why I think this is not merely a ‘might be 
useful’ feature, but there is a definite need for it.

I do not think there is a need to be much more specific about what type 
of term. I would say it is any kind of ‘foreign’ term (where foreign 
does not mean from another language, but rather a term likely not known 
to the reader, and thus foreign to him). This is a frequently used 
construct in typography, and can be found in e.g. scientific books and 
specifications, newspapers, etc. Using <i> for something as common as 
this doesn’t seem appropriate, especially not given the existence of <dfn>.

The terms could link back to an index (constructed from <dfn> tags), but 
they could also need explicit linking for that. Those links could be 
inserted by e.g. an XSLT stylesheet, wherever there’s a <term> element 
(just like indices would be generated by an XSLT as well). Also, the 
XSLT could alert the author in case terms are used that are not defined, 
just to name another use. The default visual representation would be 
italics in browsers.

Your problem with inconsistent formatting I do not understand. It’s just 
a simple proposal, obviously there are no details yet, but there would 
be if it ends up in the specification. So what does it have to do with 
your ‘please, no’?

Whether or not it is actually used correctly doesn’t even matter that 
much as long as the UA behaviour is consistent, and document authors are 
given the tools they need. Everything that is newly introduced has the 
potential to be abused. Just look at <blockquote>, seems a pretty 
legitimate element that has plenty of used. That some people in the 
Netscape 4-era used it to get indenting is not good, but it doesn’t make 
the element less legitimate nor does it make it less useful for document 
authors.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.