- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Wed, 24 Dec 2008 21:08:44 +0100
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 <p><b>A</b>fter that....</p>, if the "bing" followed the <b> 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 <b> 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 <em>/<strong>/<b>/<i>/<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 <em>/<i> and <strong>/<b> 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 <b>/<i>). [ 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 <em> 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 <b>/<i> elements represent a somewhat middle value between normal text and <strong>/<em> 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 <b> denotes 'importance' (as 'relevance'), in a different manner than <strong>, but it is something remarkable (when it's not just pure style, of course), as the right keywords, along with <strong> 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 <strong>/<em> elements (though I still find their semantics is quite well defined in general, and specially for non-visual UAs). I mean, nested <em> 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 <em> elements provide a scale of emphasis (once the base inflection for a single <em> 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 <em>, 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 <b> and <i> tell a UA? If the UA is visual, about the same as <strong> and <em>, as well as whether the UA is textual (e.g., using a darker color in place of emboldened text). What about an aural one? <em> says "switch to emphasis inflection" or the alike, but what about <i> (and analogously <b> vs <strong>)? <i> covers a range of cases potentially leading to quite different voice "tuning", perhaps according to a language characteristics, perhaps when <i> 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 <i> for a (non-visual) UA? Is it something which sometimes is like plain text, sometimes is between plain text and <em> content, some other times is like <em> or even more than <em>? And how can a UA understand that by the mean of <i>? It can't, unless <i> had attributes telling about the context, or <i> 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 <em> and <strong> and then tune the presentation for <b> and <i> as a "mean value" (or a value laying) between plain content (as a lower bound) and <strong>/<em> (as an upper bound), for instance <strong> text might be bolder than <b> text, or preceded by a longer "bing", and <i> content inflected a bit more than normal text and less than <em> content. At the same time, there would be a chance to render a certain content the very same way as normal text or <em>/<strong> 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 <span> - 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 <b> and <i>, 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 <span>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
Received on Wednesday, 24 December 2008 12:08:44 UTC