- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Sun, 30 Nov 2008 00:22:53 +0100
Tab Atkins Jr. ha scritto: > On Wed, Nov 26, 2008 at 4:48 PM, Calogero Alex Baldacchino > <alex.baldacchino at email.it> wrote: > >> >> [cut] >> > We don't have to touch parsing at all to accomplish essentially this.The issue you're worried about is getting crazy semantics applied to > individual letters. Semantic parsers (which honestly the average > browser is *not*) can easily just ignore the semantic value of <b> or > <small> or <i> when they don't wrap a full word, assuming that the use > is either stylistic or too complex/subtle to easily capture. > > Well, such is a 'semantic' solution equivalent to leaving all to the implementation; a 'parsing' solution would solve the 'problem' at the bottom, but I acknowledge the question is too marginal to be seriously taken into account. >>> >>> >>> Agree to disagree, I guess. I don't find "We hope you'll find <b>Product >>> A</b> to be the best laundry detergent you've ever used!" to be denoting >>> emphasis or importance, really. >>> >> I think 'Product A' is the core of the message, the thing some people are >> trying to sell you, the name you *must* remember when you want to by a >> laundry detergent, so those people become rich. The bold presentation aims >> to capture your attention and keep your eyes on it a bit longer; on a >> tv/radio spot the name of the product would be spoken out with some >> isolation, with at least a bit of emphasis, for the same reasons. It denotes >> importance meaning you need to pay a special attention to it in order to >> understand *what the author wants you to understand*. I think that the same >> semantics can be expressed by <strong>, since the importance of a piece of >> text is not (only) in its meaning, or in the message overall meaning, or in >> one's way to take it as important or not, but (also, or mainly) in the >> author's intention to mark it as different from the rest of the content, as >> a reading key, to drive your attention and as well your thoughts (ok, that's >> like saying that truth is a chimera, but such can be a crude truth :-P ). >> > > If I was contrasting Product A with another item, I could perhaps > agree. But we're not, so I don't. ^_^ However, we're obviously > splitting hairs here. > But you're implicitly contrasting 'Product A' with a bounce of generic items, all items of the same category your potential buyer might happen to know (I think this needs some clarification with one example, I guess you were referring to comparative advertising, which has not been legal in Italy for several years, so what you wrote - with some makup - has always been one of the most common advertisement here). Anyway, I agree we're splitting hairs, but there's some reason for me to push those concepts, and I hope I'll be able to make it clear. > >> Well, a foreign-language word, specially if correctly pronounced (by someone >> else), can be more or less hard to 'catch', so a bit of emphasis in its >> pronounce might help the listener to correctly distinguish sounds. >> > > That's stretching quite a bit more than I think is appropriate. Just > because I use a foreign phrase, does not mean that I'm emphasizing it. > If I, in audible speech, would put a bit of inflection on the phrase, > that still doesn't mean I'm emphasizing it in anything like the way I > emphasize "I'm <em>not</em> going to the dance with you!". > Isn't a bit of inflection also a bit of emphasis in pronounce? Perhaps I'm misusing the English term; that sounded correct at me in a wider sense, but I'll leave that concept, or modify it... > In other words, at most I might slightly stylistically offset the > phrase from my surrounding spoken words, but I wouldn't be > *emphasizing* them. So the <i> semantics are correct here. ^_^ > > >> After all, most of times bold and italicized texts (try and) reflect our way to >> pronounce sentences, with more or less isolation, more or less emphasis, >> quicker or slower, so changing their meaning, telling the listener that any >> part requires a greater or a lesser attention, is somehow 'special', with >> somehow different grades of 'speciality'. From this point of view, I think >> either <b>/<i> can be semantically the very same thing as <strong>/<em>, or >> their semantic should be redefined so to indicate a different (and lower) >> grade of 'speciality' on the same "speciality scale", but not as a different >> kind of 'speciality' (i.e., <b>-text stands out for some - opaque - reason >> which has nothing in common with <strong>-text). >> > > You're overreaching your definition of "importance" and "emphasis". I > don't think it's valuable to denote *everything* that is in some way > special as important or emphatic - you lose a sense of scale. If you > wish to define the words as such, then sure, <b> and <i> are lesser > grades of importance and emphasis by definition. By more conventional > definitions, though, they're not, and their stated semantics are fine. > > Ok, let's define 'special' in a more correct manner. What should be a slight offset? What does 'outstanding for some reason' mean, in a less ambigous definition? How should the offset be interpreted by the user agent? Is there any valid and exact metering for the offset? Since, by default, <b> and <i> have the same typographic semantisc as <strong> and <em>, but we're giving them a different semantics in general, let's consider them from a non graphical point of view, i.e. that of a screenreader, or a speech engine in general, and let's disregard the state of the art for such softwares, since I'm going into a somewhat formal question outstanding from the mere aural context. How should our 'non-human reader' interpret a <b>/<i> element? Is it ok to tell it can be dealt with the same way as a <strong>/<em> element? Well, if they're the same thing (but we wish they're not), perhaps we don't need redundancy here. Is it fine to tell the <b>/<i> semantics can be compared to that of <strong>/<em> on a scale where the <b>/<i> element occupies an intermediate level? Ok, let's point this out so that, by default, the reading bot can meaningfully set its parameters at the mean point between spoken plain text and spoken emphasized/important text. Is it better to state they can be set at different levels on that scale for different purposes? Ok, let's define when it occurs and why and what's the exact level corresponding to every and each case (that is, let's add a specific attribute with a set of predefined values, but perhaps such would be accomplished better through aural properties, and anyway would lead to an untrivial linguistic analysis). Is it better to say they're just different? Ok, but can we define what such should mean? what they are exactly? Does 'different' mean they're sometimes close together with <strong>/<em>, other times they're similar but closer to plain text, or at an intermediate level, while some other time they're something just different, non-important, non-enphasized, yet requiring a different inflection we can't evaluate before knowing the meaning of the text? If so, let's stop everyone! We're running into big troubles... at least on a formal pathway. The latter case defines a context-dependent semantic, which is good for a human being reading a text, because human beings uses natural languages and natural languages are strongly context dependet; it might also be good for a sentient bot, which would have a certain degree of artificial intelligence enabling it to disambiguish the language by understanding the context; but that's not good for HTML. By definition, HTML is definetly a programming language, and a programming language have to be context-free, but it seems to me that <b> and <i> are context-free just in their typographic semantics (the chance to modify such semantics via style sheets doesn't matter, from this point of view, since that's a consistent redefinition). Unless we anchored their semantics to another well defined one, establishing a somewhat relationship to make their existance meaningful and not just redundant -- and I was suggesting the idea that if <strong> expresses 'strong importance', <b> could express a 'lesser importance then <strong> text' or a 'relevance as attention focus or content outlining, helpful to improve the message understanding or to recall its theme, usually rendered with bold text and possibly requiring a voice inflection different from normal prose but not so incisive as very important content' (as an article abstract or some keywords could be classified), and if <em> expresses 'strong emphasis', <i> could express 'lesser emphasis than <em> text' or 'some change in the message context or its precisation, with respect to either its meaning or its linguistic constraints, usually rendered with italicized text and a bit of voice inflection' (as a foreign language word or a taxonomy name could indicate). 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). >>> Anyway, I'm not against a possible redefinition of <b> and <small> >>> semantics, but just aiming to deeply explore any alternative (such >>> as introducing new elements) while the specifications are in their >>> draft state. Just trying to give an alternative point of view with >>> some valid argumentations, if I can find some, nothing more (and >>> hope I'm not giving a different impression). Best regards. >>> >>> >>> No problem. Just because I disagree doesn't mean we can't argue. ^_^ >>> >>> ~TJ >>> >> Ok, let's argue ^_^ >> Now I'll throw in an even creazier idea. Let's maintain everything as is, >> and let's add two new elements the semantics of 'outstanding' and 'aside', >> which works as meta informations, i.e. they have no default style (or a >> default such as 'display:inline' and all the rest, but aureal properties, is >> inherited from the parent element) and ignore any style direclty set on >> them, but aureal styles, so they are ignored by any author not caring of >> them, but act as a shortcut for basic aureal behaviour for authors caring >> insteed, but not willing to create a whole aureal sheet, and can be helpful >> for an assistive software, regardless its support for aureal sheets, since >> their basic semantics is used as a hint on what to do despite any visual >> styling of the inner content (and of any inner <small>, <b>, <strong>, and >> so on). >> > > I'm not an accessibility maven, so I have no idea whether this would > be useful or not. I suspect, though, that having a special kind of > emphasis that you use *only* when you want to denote something aurally > but not visually is such an extreme niche case that it doesn't matter > (it sounds incoherent to me, actually). If you know and care enough > about accessibility to *use* elements that will only have an effect on > aural browsers, you know and care enough about it to set up your CSS > appropriately. > > ~TJ > Well, I told you it was a crazy idea ^_^ (and of course a niche use, but the aural features were just a stylish hint, because they're usually ignored, while a semantic-only element could be more helpful, for assistive technologies, than typography-related ones, but a semantic-only element - specifically targeting to non-visual environments - could be as bad as a typographic-only one, since would be as well poor of generality, so a real division between content and presentation - like media-targeted CSS can provide - would be favourable). Alex. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: A fine mese devi affrontare molte spese? Intesa Sanpaolo ti parla di Check-up finanziario. Prenotalo qui senza impegno Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8436&d=30-11
Received on Saturday, 29 November 2008 15:22:53 UTC