[whatwg] Phrasing semantics feedback omnibus

Wed Dec 24 12:08:44 PST 2008

First of all, let me state I wasn't (and am not) too strongly concerned 
on the following issues. These where either formal questions, or 
impromptu thoughts inspired by the dialog, perhaps not enough weighted 
when not enough felt. I guess it was no way clear in my mails. Let me 
also state that I'm definitely not aiming to argue, but I feel to 
disagree about some conclusions.

Ian Hickson ha scritto:
>
> On Fri, 14 Nov 2008, Pentasis wrote:
>> 1) Just because it makes sense to a human (it doesn't to me), does not 
>> mean it makes sense to a machine.
>
> HTML is ultimately meant for human consumption, not machine consumption. 
> Humans write it (sometimes with the help of a machine), humans read it 
> (almost always with the help of a machine). We don't need it to make sense 
> to a machine, we just need the machine to do what we tell it to so that it 
> makes sense to us.
>
>

Don't you really consider the machine role as "central" in this process? 
HTML is the way (= the *language*) you tell the machine what to do so it 
makes sense to human users. You've given a bare definition of a 
*computer language*, but a computer language is for machine consumption! 
HTML is for human use (= the author/web developer) but for machine (= 
the UA) consumption, the very same way C++ is for human use (= the 
programmer) but for machine (= the compiler) consumption, since both are 
computer languages; the former being a specialized language and the 
latter being a general purpose one is no way relevant from this point of 
view, since both are computer languages *by definition* (not my own, of 
course...). Only the machine output is for human (end users) 
consumption. How should a human user be supposed to consume an HTML 
document if a machine doesn't consume HTML _code_? And how should a 
machine be supposed to consume HTML code if it's not projected having in 
mind machine constraints _first_ (e.g. context-freedom), authors needs 
in second place? :-)

> On Tue, 25 Nov 2008, Calogero Alex Baldacchino wrote:
>> [...]
>
> Could you give a concrete example? In all the examples I can think of, 
> there is no problem that I can see. For example this:
>
>    <p><b>H</b>ello!</p>
>
> ...would be fine in an AT, even if the AT went "bing" as it was saying the 
> first part of the word.
>
>

What about After that...., if the "bing" followed the 
content (the same way a radio advertisement speaker could read out 
"Intel Inside" followed by the usual jingle "do dooDOOdooDO"), wouldn't 
such end up in a difficult to understand sound? [for a 'bing' preceding 
the content, just shifting tags inside the word causes the same 
"problem"] Anyway, in a following mail I agreed an AT might default such 
cases as plain text, just ignoring "in word" tags whose semantics may 
alter speech (but specifying certain semantics should be applied only to 
whole words by non-visual UAs wouldn't be an awful idea, I think). 
Perhaps it wasn't clear.

>> However, I think that a solution, at least partial, can be found for the 
>> rendering concern (and I'd push for this being done anyway, since there 
>> are several new elements defined for HTML 5).
>
> Which rendering concern?
>
>

The one raised vs my (impromptu and abandoned) idea of new semantic 
elements: backward compatibility with older browsers unaware of such new 
tags (it's the very same for new elements though).

>> [...]
>
> Actually other than the validator, user agents ignore the DTD altogether.
>
>

[other points like the above]

I've acknowledged in other mails my assumptions were definitely wrong, 
and I apologized for that, as far as I remember (did I forgot to? if so, 
I apologize now!). Then the discussion moved towards the suitability of 
a kind of "foundation style sheet" to handle at least new elements 
presentation, and hiding those ones whose semantics might be difficult 
to cope with in older browsers (such as a menu constrained to be a 
contextual menu: a default CSS wouldn't be enough to cope with such), as 
a graceful degradation.

[my own personal conclusion, in my humble opinion, was that the result 
might be unreliable and definitely browser-dependent -- for instance, IE 
family seems to accept a 'custom' tag with its 'custom' attributes, by 
creating a 'proper' (as far as possible) html element, and styles are 
correctly applied to the element too, BUT any content inside the unknown 
tags is extracted and put inside the outer container, as if it were 
misplaced - a partial solution, though apparently not working in IE8, 
consists of adding a script creating an element with the 'custom' tag 
name by calling document.createElement() before unknown tags are parsed, 
but such tells me a "foundation style sheet" is not a (fully) working 
solution _per_se_, though desirable for consistent cross-browser rendering].

>> Let's come to the non-typographical interpretation a today u.a. may be 
>> capable of, as in your example about lynx. This can be a very good 
>> reason to deem <small> a very good choice. But, are we sure that *every* 
>> existing user agent can do that? If the answer is yes, we can stop here: 
>> <small> is a perfect choice. Better: <small> is all we need, so let's 
>> stop bothering each other about this matter. But if the answer is no, we 
>> have to face a number of user agents needing an update to understand the 
>> new semantics for the <small> tag, and so, if the new semantics can be 
>> assumed as *surely* reliable only with new/updated u.a.'s (that is, with 
>> those ones fully compatible with html 5 specifications), that's somehow 
>> like to be starting from scratch, and consequently there is space for a 
>> new, more appropriate element.
>
> All browsers handling <small> is better than some browsers handling 
> <small>, certainly, but some browsers handling <small> is better than no 
> browsers handling a new element. So I don't really agree with your 
> reasoning here.
>
>

Well, I guess there are more chances to see new elements, whose 
semantics is somehow felt as necessary, implemented in new browsers, 
than elements replacing other elements with a somehow close semantics. 
Thus I have to agree. :-)

>
>
> On Tue, 25 Nov 2008, Calogero Alex Baldacchino wrote:
>> I'll start with an example. A few time ago I played around with Opera 
>> Voice. [...]
>
> I don't think this browser bug is a good guide for language design.
>

Well, it was a plugin version perhaps, anyway I've never tried it out 
again. Anyway, that tells me any unspecified behaviours may lead to 
bugs/bad choices/different choices in different UAs, and such might be a 
reason to consider a standard definition instead, IMHO.

>> Let me reverse this approach: what should an assistive user agent do 
>> with such a <b>M</b><small>E</small><b>S</b><small>S</small>? [...]
>
> What should an AT do with <em>M</em><strong>e</strong>s<em>s</em>? Why is 
> this any different?
>

First, the same thing I've said above I agreed previously, that is 
ignoring elements (not their content) whose use (by authors) is not 
easily bindable to non-visual semantics.

Second, isn't an AT some kind of non-visual UA? Shouldn't 
////<whatever> semantics be defined such as covering 
non-visual behaviours for visual (mis)uses?

Third, anyway, but this is parenthetical, it was one reason I was 
considering (just on the fly) a kind of new element constrained, both in 
conformance and in parsing rules, as containing no less than one full 
word (this was part of what I called a "crazier" - and soon abandoned - 
"idea").

>> Here it is me not understanding. I think that any reason to offset some 
>> text from the surrounding one can be reduced to the different grade of 
>> 'importance' the author gives it, in the same meaning as Smylers used in 
>> his mails (that is, not the importance of the content, but the relevance 
>> it gets as attention focus - he made the example of the English "small 
>> print" idiom, and in another mail clarified that "It's less important in 
>> the sense that it isn't the point of what the author wants users to have 
>> conveyed to them; it's less important to the message.
>
> I strongly disagree, and urge you to compare the examples in the spec for 
> <em>, <strong>, <b>, <i>, and <small>, which show very different cases. 
> They are not equivalent. Only <strong> indicates a change in importance.
>

I feel to disagree as well. For what concerns this subject, I've always 
used the term "importance" or "important" in a wider sense, as synonym 
at "relevance" or "relevant" (which I suppose to be consistent with a 
linguistic analysis - but linguistics may become a mined ground). From 
this point of view, I deem use cases for "b" as expressing a different 
(and perhaps lesser) grade of importance, or a differently 'scoped' 
importance than "strong" content (to say, "strong" applies to a whole 
sentence/a whole message or a substantial part of it, while "b" 
indicates importance in a tighter scope or something which is important 
as a reading key, to focus the reader attention on the message core but 
not necessarily expressing the core of the message per se/alone).

For instance, a product name and brand in any advertisements, though 
suitable to be 'labeled' as "b" content as keywords, represent the only 
relevant part of the message, that is the only one a company wants 
people to remember and wish to buy, while it's not the whole core of the 
message per se (which is "remember product x, wish product x, buy 
product x!!"), and the rest of the message is about a semiotic "trick" 
to make people remember the name and brand of a product. Furthermore, I 
really can't get how a keyword is not an important word in its message; 
ok, perhaps it doesn't (always) add important contents, but clarifies or 
otherwise focuses attention on something being somehow important in the 
surrounding content (it is, or can be, important to understand the 
overall meaning -- how much clear would be a hardware review never 
mentioning the reviewed product name? And the very first time it is 
mentioned, doesn't it adds an important content to the prose? Keywords 
are an important part of a message, and remarking them is worth it, thus 
they can be emboldened).

That is, if "strong" offsets a span of text which is important per se, 
as the core of the message, or a further message related to the rest but 
more important, "b" might be thought as offsetting something which is 
important with respect to its relationship with the surrounding text 
(this is the way I interpret it, even with current definition - for 
non-'decorative' purposes), expressing a different kind or degree of 
importance, not just a stylistic offset - which is (visual) 
presentational matter - thus I'd consider consistent to say that "b" 
offsets some phrasing content between plain text and "strong" content, 
and "i" offsets some content between plain text and emphasized content, 
just to trace a boundary for their semantics and try and avoid semantic 
overlapping between close elements in some borderline contexts (visually 
their semantics overlap though - I mean, each pair of / and 
/ are suitable for the very same visual presentation - and 
that's perhaps unavoidable to some extent, as well as misuses) -- 
elements semantics is for UAs consumption in first place, because if a 
UA cannot handle it, elements content cannot be rightly presented to users.

And if I figure out an AT producing a "bing" before or after an 
emboldened keyword, I can't help imagining it doing the same for 
"strong" text, perhaps with a louder or longer or (slightly) different 
sound (a different voice telling something like "the following sentences 
are very important, take care" might be an alternative choice, but not 
for "strong" content surrounded by plain text -- important things can 
also be spoken about with a somehow different inflection and speed, but 
it's the same for certain use cases of /).

[ Maybe this discussion is harmed by a cultural gap leading to different 
interpretations. For instance, I'm understanding the English concept of 
emphasis (mainly) covers a (quite noticeable) change in voice inflection 
causing a change in meaning, e.g. underlining different feelings; in my 
own language inflection is a kind of emphasis, but emphasis per se is 
related to meaning, to relationships between words remarking some 
concepts, e.g. a word used outside its context, as figurative, or a 
pompous term breaking out while discussing something, or an 
exaggeration, or a repetition of terms remarking a point (e.g. 
(translated) expressions like "never ever", "ever and ever" and so on, 
though leading to some speech emphasis, are emphatic per se and are said 
to bring emphasis into a sentence). Nevertheless, I think current 
semantics (as well as examples) for the tag is quite well defined. ]

Anyway, I'd be tempted to prefer a "pure CSS" solution in most cases, as 
I think a (sighted) user can always disambiguate the meaning of 
boldened/italicized text not only because of their stylistic offset, but 
also by the mean of other characteristics, such as punctuation, the 
overall meaning, the presence of uppercase words (like 'WARNING'), while 
I don't really expect a (non-visual) user agent to be capable to cope 
with all possible subtleties covered by emboldened/italicized spans of 
text just basing on them being emboldened/italicized (e.g. a product 
name might be read out differently in a review and in advertisements, 
while a taxonomic name might be pronounced differently the first time 
it's found in a scientific paper, but not in other occurrences, though 
being always italicized -- a visual UA can just use 
italicized/emboldened text and leave out any semantic interpretation to 
the human reader, while for a non-visual one I think aural CSS's would 
be a better solution for fine tuning, but also a good way to mess 
everything up, and are not supported by screen readers, perhaps 
rightly). Stating / elements represent a somewhat middle value 
between normal text and / elements might be a compromise 
from the point of view of a non-visual UA consuming them (at least as a 
well-defined, context-free, non-presentational (non-visual) semantics).

For what concerns the quoted part, I really can't figure out something 
more important than 'small print' content in legal agreements and ads, 
in most cases, since it's the more important part to take care of to 
avoid bad surprises... I mean, in some cases - if not in most - a kind 
of stylistic offset is not related to the real importance of the overall 
message, but to the greater or lesser relevance an author wishes readers 
will give to some content, as a mean to focus their attention one way or 
another, to mask real importance to some extent. This is basically why I 
like to think of 'relevance' (for authors' purposes) whenever and 
wherever I read 'importance', and also why I think actual semantics for 
 denotes 'importance' (as 'relevance'), in a different manner than 
, but it is something remarkable (when it's not just pure style, 
of course), as the right keywords, along with content and/or, 
perhaps, italicized text, may lead to different interpretations, 
pointing out something looking somehow obscure or secondary at first 
glance as being strongly related to all surrounding prose (e.g. in a 
quoted content).

>
> On Wed, 26 Nov 2008, Calogero Alex Baldacchino wrote:
>> Now I'll throw in an even creazier idea. [...]
>
> Experience with aural-specific markup has been quite negative, in that 
> people end up using it when they think it's appropriate but it is not, and 
> they end up making the experience significantly worse for screen reader 
> users. Media-specific markup is bad regardless of the medium, it seems.
>

Well, I called it 'crazy' ( :-P ) and don't want to push it anymore. I 
was just thinking to possible misuses and (mainly) to rare use and 
scarce support. Didn't I pointed it out in following mails? Perhaps it 
wasn't clear anyway.

But I like to think of screen readers (and speech software in general) 
as a good example of non-visual user agents. A textual UA (like lynx) 
may use different colors to represent different styles (bold/italic/font 
sizes), thus, once the final user is confident with such a convention, 
any semantic disambiguation is up to him; but an aural technology must 
disambiguate any text before reading it in order to make it meaningful 
for listeners (maybe such is possible only to certain extent, but the 
spoken content must be as close as possible to its meaning to make 
people understanding it). From this point of view, perhaps similar 
oppositions might be raised vs every semantic elements an author might 
misuse, and particularly for nested / elements (though I 
still find their semantics is quite well defined in general, and 
specially for non-visual UAs).

I mean, nested semantics is quite perfect for authors' needs, but 
such can't be just a way to annotate an author's thought, it must be 
easy to handle for every UAs in order to produce a meaningful output for 
the end user. In a visual presentation, unless specific CSS rules are 
provided, the same style (= italicized text) might be applied regardless 
the nesting depth (or stopping at a certain level), because (human) 
readers would get the point by mean of punctuation (e.g. repeated or 
alternated exclamation/question marks can suggest a different degree of 
emphasis and/or a different feeling), text formatting (e.g. uppercase 
letters standing for a louder voice), and, last but not least, the 
surrounding content, which gives the context of a sentence; but a UA, as 
well as any language transducer, cannot understand contexts, thus it 
can't easily adjust punctuation or change letters case, nor it can 
safely apply different styles (such as increasing/decreasing font weight 
and/or size, and/or underscoring words, and so on) without caring of 
possibly resulting in non-very-friendly layouts (after a certain depth).

Instead, an AT (which might also avail of punctuation to some extent), 
might use nesting levels to tune voice pitches (and the alike), that is 
nested elements provide a scale of emphasis (once the base 
inflection for a single level is chosen, consecutive levels can be 
tuned proportionally). But scaling inflection with elements depth might 
result in a too loud speech, or a non-easily understandable one, if 
elements are improperly nested. Thus, a screen reader developers might 
choose not to support nested , as well as they prefer not to support 
aural CSS, since they don't trust in authors' ability as a conservative 
approach.

Moreover, I believe that cross-media/media-neutral elements might 
require media-specific considerations (specially if cross-UA consistency 
and standard, predictable behaviours are a goal), the same way an IDL 
may require language-specific bindings (to solve peculiar problems, or 
as a guideline for similar languages). I think when elements semantics 
meets content meaning, elements presentation determines content 
understanding. [IMHO]

>
> On Sun, 30 Nov 2008, Calogero Alex Baldacchino wrote:
>> [...]
>
> Could I possibly encourage you to split your paragraphs into smaller 
> paragraphs?
>

Oops...... sorry........

>
>> In other words, I'm not concerning whether the actual semantics of <b> 
>> and <i> is consistent with common uses of italicized and bold text, and 
>> with their conventional definitions (human-understandable, but perhaps 
>> not machine-friendly), but whether that's well defined (context-free) 
>> with respect to a user agent capabilities to correctly interpret and 
>> present them. Visually that's painless, but non visually (non 
>> graphically) I'm quite feeling the need for a greater context-freedom 
>> (at least binding them to some more precise semantics, with respect to 
>> which to scale <b> and <i> semantics and make them more context-free).
>
> I have to admit to having no idea what you are talking about here.
>

I'll try and explain that, as far as I'm able to.

What do and tell a UA? If the UA is visual, about the same as 
 and , as well as whether the UA is textual (e.g., using a 
darker color in place of emboldened text). What about an aural one? 
says "switch to emphasis inflection" or the alike, but what about 
(and analogously vs )? covers a range of cases 
potentially leading to quite different voice "tuning", perhaps according 
to a language characteristics, perhaps when is used to stress a 
concept as a non-speech kind of emphasis rather than naming taxonomy 
(both use cases for italicized text, since sometimes italic is preferred 
to bold and sometimes used in conjunction with bold, to create a kind of 
scale of emphasis or stress over a matter).

So, what's for a (non-visual) UA? Is it something which sometimes is 
like plain text, sometimes is between plain text and content, some 
other times is like or even more than ? And how can a UA 
understand that by the mean of ? It can't, unless had attributes 
telling about the context, or semantics were restricted to one 
precise context and other elements where created to tell about a 
specific context, but such might be risky because of possible misuses, 
thus delegating context interpretation to UAs, in part, may be 
reasonable. But UAs cannot understand contexts because they're (about 
Turing) machines, so they don't understand content and cannot resolve 
contexts, thus a compromise is needed to help a UA to attach an 
acceptable presentation (when the most proper is not achievable) to a 
certain semantics.

At first glance, a compromise might be a convention like,

"normal text" <minor than or equal to> "i content" <minor than or equal 
to> "em content"

and

"normal text" <minor than or equal to> "b content" <minor than or equal 
to> "strong content"

so that, at first glance, any UAs might fix a presentation for and 
 and then tune the presentation for and as a "mean 
value" (or a value laying) between plain content (as a lower bound) and 
/ (as an upper bound), for instance text might be 
bolder than text, or preceded by a longer "bing", and content 
inflected a bit more than normal text and less than content.

At the same time, there would be a chance to render a certain content 
the very same way as normal text or / text, according to 
what's considered a better choice for a certain medium dealt with by a 
certain UA. Perhaps that's what UAs (specially non visual ones) should 
do anyway, but any degree of (non standard) freedom may lead to 
inconsistent behaviours passing from a UA to another, and standard 
behaviours are or can be a goal. Thus, I think that spending one more 
word for clearness purpose (at least) is always better than not doing 
so, because I believe precise semantics is needed by UAs more than by 
authors.

More technically, html defines a (specialized) programming language 
whose transducer is any conforming UA, the same way as any document 
format (from the binary .doc, to the human readable RTF, to LaTex, to 
ODF, to PDF and so on) defines a (specialized) programming language 
whose transducer is a compatible word processor (from this point of 
view, a WYSIWYG editor can be thought as a kind of visual IDE) -- let me 
point out that's not my own personal opinion, that's just current theory 
on computer languages, and I'm and will be fine with its actual 
statements at least until someone'll confute or overcome them.

HTML has to deal (not only, but also) with "human" (or "natural") 
languages semantics, but such semantics cannot be the base for html 
semantics, because as every computer language html needs 
context-freedom, while natural languages are strongly context-dependent. 
It's a fact, human beings are addicted to metaphors, to double senses, 
to figures of speech, we often don't even catch that, as when we talk 
about the "arms" of a chair, which is a catachrestic (unperceived) 
metaphor; nothing of such is far reproducible in computer languages 
actually.

In printed/written text we avail of conventions like punctuation, 
uppercase letters, fonts size and style, colours, and so on, to 
reproduce speech conventions, such as voice speed, pitches, volume, 
which are our first disambiguation mean; sometimes print/grammar 
conventions aren't enough, as well as voice inflection (e.g. a person 
may use very similar inflections to express (slightly or quite) 
different feelings, or no inflection for a mixed metaphor, since 
perceived as normal speech, or he/she may pronounce and write 
different-meaning words the very same way), though we're able to 
understand meaning most of times, because we can add further knowledge 
on a speech subject than what's expressed by the speech itself: we're 
aware of contexts, computers are not.

[ A classic example may be a sentence like "legs have cats": who owns 
what? Everyone can answer "cats" is the "who" and "legs" is the "what"; 
someone'll notice that sentence does not conform to English grammar 
rules, yet we understand its meaning, because we can add a wider 
semantics to each term, we can contextualize it, while a computer 
cannot; a computer can, at most, find the verb, understand it, than 
attach the 'owner' semantics to whatever precedes it and the 'owned' 
semantics to whatever follows it -- I like thinking of natural languages 
as some kind of multidimensional, cyclic, implicit and generally 
"non-explicitable" function our brains are capable to deal with by the 
mean of probabilistic algorithms based on a database of previous 
experiences coming from each sense and acquired knowledge - that is 
fuzzy logic ]

An HTML conforming UA is a language transducer, a kind of compiler, thus 
unaware of contexts and content meaning. HTML elements' semantics should 
be as close as possible to one specific context (eventually with the 
help of attributes - whether to create a new element or to add a new 
attribute is a matter of syntax), so that any UAs can attach a proper 
presentation to elements' content, helping human end users to understand 
its 'meaning'; if that's not reasonably possible, more contexts (close 
to each other) should be grouped in one semantics taking care of 
defining (or referring to, when possible) a mean presentation which is 
an acceptable cross-media compromise, possibly referring to other 
elements with a somehow close, but better defined ( = more specific) 
semantics, or even aliasing them. [IMHO]

In other words, an element's semantics should be defined taking care of 
UAs constraints, first, and of authors' needs in second place, not 
because authors' needs are less important, indeed they're so important 
that there's place even for some (reasonable) redundancy; but a human 
being can always take the effort to care of machine constraints, while 
the opposite is not always true (if possible at all), and won't be true 
at least until technology will provide us human-level AI.

>
> On Tue, 25 Nov 2008, Pentasis wrote:
>> Just because HTML5 redefines the element does not mean that the element 
>> will suddenly be semantic.
>
> The key is that the way we have defined <b>, <i>, and <small> is roughly 
> in line with what authors do already anyway, as much as other tags are 
> roughly in line with how they are used.
>

That's a good key, but solves half of the problem, the part related to 
authors needs; I think another key should be taken into account beside 
that, answering the question, is an element's semantics something any 
UAs can _easily_ understand and _correctly_ present to end users, 
without any further knowledge on the element's content and context than 
what's expressed by the element semantics itself? I fear whatever effort 
is taken to define a "media-neutral" semantic, there is always a chance 
for a media-dependent answer, especially for phrasing semantics, which 
deal somehow (or mainly) with content 'classification' and presentation 
(cross-media, as far as possible), and a wrong presentation may 
compromise content enjoyment, despite human capabilities to disambiguate 
contexts.

>
> One way to think of <nav> is "would you want an accessibility tool to skip 
> these links by default?". One way to think of <aside> is "would you want 
> this to be moved to a sidebar?".
>
>
> On Fri, 14 Nov 2008, Nils Dagsson Moskopp wrote:
>>> The small element represents small print [...]
>>>
>>> The b element represents a span of text to be stylistically offset 
>>> from the normal prose without conveying any extra importance [...]
>> Both definitions seems rather presentational (contrasting, for example, 
>> the new semantic definition for the <i> element) and could also be 
>> realized by use of <span> elements.
>
> Consider a speech browser. Does it makes sense to convey small print in a 
> speech context? (Yes, consider radio ads for pharmaceuticals. They speak 
> faster for the small print.) Does it make sense to represent a span of 
> text stylistically offset from the normal prose without conveying 
> importance in a speech browser? (Yes, e.g. there could be a "bing" sound 
> after each word in a <b>, indicating that it is a keyword. I can't think 
> of an example on radio currently, though.)
>
> Media independence is what we're going for here. <font>, for example, 
> isn't media-independent.
>
>
> On Mon, 24 Nov 2008, Asbj?rn Ulsberg wrote:
>>> However, you can only notice this if the words have been distinguished 
>>> in some way.  With <b>, all user-agents can choose to convey to users 
>>> that those words are special.
>> They are only special for sighted users, browsing the page with a rather 
>> advanced user agent. They are not special to blind users or to users of 
>> text-based user agents like Lynx. If you want to express semantics, then 
>> use a semantic element.
>
> <b> now _is_ a semantic element. Lynx already uses a different colour for 
> it, for example. What problem do we solve by inventing a new element to do 
> exactly what <b> does today?
>
>
>> Expressing semantics through presentation only is done in print because 
>> of the limitations in the printing system. If the print was for a blind 
>> person, printed with braille, one could imagine (had it been supported) 
>> that letters with a higher weight could be physically warmer than 
>> others, or with a more jagged edge so they could stand out.
>
> Right, and we can get that with <b>. No need for a new element.

All right, but that's mainly a (cross-media) presentational semantics 
(unlike links and inputs, which describe interaction mainly, for 
instance), thus media-specific considerations might be needed to some 
extent to improve cross-media consistency, which I think is a goal 
conveyed by media-independence (otherwise, the same markup would/might 
lead to unreliable results, so telling what a certain semantics means 
for a certain UA, not only for authors, with respect to other, somehow 
similar elements, is something I'd consider), because what changes here 
is media-neutrality, while presentational nature of elements with a 
redefined semantics is left untouched (and couldn't be otherwise).

Once UAs implemented, for instance (and only as an example), conventions 
like,

'thicker text' (visual) <=> 'darker colour' (textual) <=> 'warmer 
letters' (braille) <=> 'louder "bing" before content' (aural)

and

'letters size' (visual) <=> 'colour hue or saturation' (textual) <=> 
'more or less jagged edges' (braille) <=> 'voice speed and/or volume' 
(aural)

there wouldn't be any major differences between,

<b> Something </b>

and

<span style="font-size:inherit; font-weight:bold;"><!-- or perhaps 
hypothetical letter-size, letter-weight with font-* properties derived 
accordingly for screen media --> Something </span>

other than actual CSS support (that is, enriching and generalizing - 
implementation-side perhaps - certain visual CSS properties' semantics 
instead of certain html (born-)visual elements' semantics, once provided 
a wide support for CSS, would be quite the same), and perhaps the former 
being a good and more expressive 'shortcut' (or alias) for the second 
(from authors' point of view).

Most elements might be reduced to a <div> (or a - only one is 
needed, 'thanks' to display property) with proper style and attributes, 
but a semantics such as "(almost) everything is a div" may not be enough 
expressive to meet authors' needs. Such a need for expressiveness (given 
any lack in CSS support is something possibly subject to change) is 
perhaps the only good reason to maintain presentational (though 
media-independent, as far as possible) elements such as and , but 
also to create newer ones such as <article>/<section> (<div>s with 
proper styles), <aside> (a floating or otherwise positioned <div>), 
<nav> (a <div> with an opportune tabindex, if supported by ATs to order 
content), for instance. Though, that's a very good reason to have what 
I'd call a reasonable redundancy. :-)

 >
 > On Fri, 14 Nov 2008, Pentasis wrote:
 >> Not yet maybe, but we could at least try to keep options open for the
 >> future.
 >
 > This doesn't scale -- there are an unbounded set of features that aren't
 > in HTML5 currently. We can't add them all. We are focusing on only 
adding
 > those features that we can justify today, as that seems like the most
 > sensible cut-off point given that we need a cut-off point.
 >

That's a good point, going further might be either unneeded (and might 
be done as soon as a real and wide need arose, in a bullet-tracing 
fashioned evolution), or yet possible by the mean of xml extensibility 
(in xhtml, for instance), or even by the mean of <div>s or s with 
a proper not-only-presentational class attribute (if 'everything is a 
div' lacks expressiveness, 'something is a div classified as @class' 
might be enough expressive for custom/niche needs). :-)

Best regards, and happy holiday to everyone (if having holidays this period)
Alex

 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

 Sponsor:
 Polizza Auto?
* Con Direct Line garanzia furto e incendio a soli 30 euro per un anno! Affrettati: l’offerta è valida fino al 31 Dicembre. 
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8512&d=24-12