On Sat, 14 Jan 2006 04:39:29 -0800, Matthew Paul Thomas
<[EMAIL PROTECTED]> wrote:
If authors -- or specifications -- try too hard to use a semantic
element, or to force other people to use it, it will be misused so much
that UAs can no longer trust the element to have any particular meaning,
so it will become de facto presentational.
Yes! That is what I was trying to say earlier. The best case examples are
inline strings which are typically italicized and bolded, but aren't being
emphasized. The problem with using <EM> and <STRONG> in those situations
is that these 2 elements have been stretched to include more than just
emphasis.
That's why I think that every semantic element should have a corresponding
element that appears to be the same, but doesn't have the same meaning. If
we had something similar to <TABLE> and its children, then people may have
been willing to transition to those other elements with less arguments,
and thus, blind people would find more value in pages with actual tables.
Having similar elements to <TABLE> and its children doesn't represent best
practises, but it does represent better practises. The same goes for <DL>
and its children. If there had been an alternative, then there would have
less likely been any tampering with the semantic elements.
The bottom line is that we should be very protective and strict of the
semantic elements and lenient of the others.
<p>
This has been semantic until now, meaning a paragraph. But the
current Web Applications 1.0 draft pretends that the English word
"paragraph" means something much broader than it really does, so
broad that it will have no semantics at all. (For example, someone
instructed to write a ten-paragraph essay will get incorrect
results from a paragraph count if, as suggested by Web Apps 1.0,
they use <p> for the essay's byline.) As a result, <p> will come to
mean "present this as a block with extra vertical margins".
But isn't it possible to redefine the draft to limit the definition?
--
Sincerely, and with thanks,
Eugene T.S. Wong
