[whatwg] Semantics and related feedback

[Ian Hickson]

This is a bulk reply to a bunch of HTML5 semantics-related posts on the 
WHATWG list.

On Sun, 2 Nov 2008, Eduard Pascual wrote:
>
> Your only fault, just like me, was to believe this was a serious place 
> for discussion. But it isn't: it is just a tool: feedback "praising" the 
> spec will be kept well safe, while feedback suggesting anything that was 
> not the idea of browser vendors gets buried in side-discussions or 
> simply ignored.

I assure you that I do take all feedback into account (and indeed I 
personally reply to every substantial point made on this list, after 
considering it and adjusting the spec if appropriate).


> In the end, feedback is not being used to improve the spec, but to hide 
> the fact that it is nothing else than the tyrannical imposition of 
> browser vendors upon the entire Web. So once they go through and publish 
> HTML5 as a recommendation or standard, they will use all this filtered, 
> non-representative feedback, to claim that it was defined by the entire 
> Web community. But the truth is that browser vendors will do whatever 
> they please, just like they did before the W3C existed, only that they 
> are now also trying to attach it the "standard" tag.

While it's certainly true that browser vendors have the ultimate power of 
implementation to override anything we put in the spec, and thus that if 
we want the spec to describe reality, we have to do whatever they do, I 
assure you that I, as editor of the spec, am trying as much as possible to 
balance the needs of all parties here, not least of which regular Web 
authors. Without buy-in from Web authors, HTML5 won't succeed either.


On Sun, 2 Nov 2008, Pentasis wrote:
> 
> [HTML5 is] a new standard which is unusable in a practical sense for 
> designers.

Could you elaborate with concrete examples showing in what ways HTML5 is 
unusable? I am highly concerned about this and really wish to fix any 
problem that serious. I'm sorry if I missed examples in your earlier 
feedback.



On Sun, 22 Jun 2008, Edward Z. Yang wrote:
> 
> I was reading through the HTML5 spec the other day and I noticed this 
> tidbit:
> 
> > To represent a block of computer code, the pre element can be used 
> > with a code element; to represent a block of computer output the pre 
> > element can be used with a samp element. Similarly, the kbd element 
> > can be used within a pre element to indicate text that the user is to 
> > enter.
> 
> The implication is that document authors are recommended to use 
> <pre><code> to wrap all of their programming code instead of a lone 
> <pre>, if they wish to be fully semantic. This feels needlessly verbose 
> and abusive of <code>, which traditionally has been used to mark 
> single-liners.

This recommendation is actually just "paving a cowpath" -- there has been 
a general trend towards <pre><code> for marking up computer code, which 
seems to make sense on the face of it.


> It also makes it extremely difficult to style pre as a block for code, 
> as the only semantic indication that the contents of the pre block are 
> computer code is its child. You'd end up having to say <pre 
> class="code"><code> if you wanted to style pre as well.

Why not just style the <code>?


> At the same time, I still think the semantics of whether or not a <pre> 
> tag indicates a plaintext file, or a piece of ASCII art, or computer 
> code, is somewhat important. However, I think this information would be 
> more appropriately given as an attribute.

Well, authors are welcome to use the class="" attribute for this purpose, 
as with any HTML element. It's not clear that there is a real need to 
provide more support for this than what we have now.

Also,

   <pre><code> ... </code></pre>

...does not seem significantly more verbose than:

   <pre type="code"> ... </pre>

...so it's not clear to me what an attribute would get us here.


On Sun, 22 Jun 2008, Edward Z. Yang wrote:
> 
> Lets say I want to place a background image of a computer behind spanses 
> of computer code, but a background image of a console for emulated 
> console data using samp and kbd.
> 
> With HTML 4, I would have done <pre class="code"> (or more likely, just 
> omitted it and assumed it was computer code by default unless otherwise) 
> and <pre class="console">.
> 
> With <pre><code>, you can't do that. <code> is an inline element, and 
> the background image doesn't get applied to it in any meaningful way.

Just do:

   pre > code { display: block; background: ...; }



On Sat, 1 Nov 2008, Pentasis wrote:
> > >
> > > Yes, but this is a theoretical explanation that does not provide a 
> > > consistent, practical solution.
> > 
> > I don't understand why these solutions aren't consistent or practical.
> 
> First of all, the spec admits it itself:
> "HTML does not have a dedicated mechanism for marking up footnotes. Here are
> the recommended alternatives."
> Alternatives are not real mechanisms.

Sure, but they're still consistent and practical...


> It gives us the option of using the title attribute (which has no 
> mechanism of expansion and we cannot group them).
>
> Then it gives us the a element solution, which is how it is already done 
> in most cases but leaves much to be desired (there are plenty of 
> articles about it on the web).
>
> And last it tells us we can use the aside element. But in this example 
> there is no *direct* relation to the actual word/phrase we put in the 
> aside. It also gives us -again- no direct mechanism of expansion and no 
> way of grouping footnotes/sidenotes.
> 
> Now, I am perfectly happy for this spec not to provide a footnote 
> construct, but in that case I would strongly suggest removing these 
> alternatives and simply say it should be resolved using scripting (which 
> has much more flexibility) or not say anything at all about it.

We have received significant feedback on the topic requesting that 
declarative suggestions be given here, which would not be addressed by 
omitting the section or suggesting script-based solutions.


On Sat, 1 Nov 2008, Pentasis wrote:
> 
> [since grouping is a stylistic concern] why don't they drop the abbr, 
> dfn, cite, mark etc. elements? They can be styled through CSS as well 
> and be semantically determined by using a class-name just as sugested 
> for footnotes.

The idea is to provide ways to mark up documents that work regardless of 
the presence or absence of styling hooks like CSS. title="" provides this 
for footnotes. The grouping of footnotes isn't explicitly provided (though 
nothing stops a print UA from grouping all the title="" attributes 
together at the end), but that, as was noted, is a stylistic concern.

I don't think, therefore, that the premise of your question follows.


On Sun, 2 Nov 2008, Pentasis wrote:
> > > 
> > >   * As a style sheet selector (when an author wishes to assign style
> > >     information to a set of elements).
> > >   * For general purpose processing by user agents."
> > > 
> > > The first role is clear, it is used for styles (not semantics)
> > 
> > Ian answered to this. You'll similarly or identically style elements 
> > with similar or identical meaning; in other words, you'll attach style 
> > to semantics, so your class names are likely to markup your document 
> > with additional semantics.
> 
> That is exactly why I think it is wrong. It gives me less flexibility. 
> It means I must either style all footnotes (or whatever) the same, or 
> introduce more classes/ids to style them differently and in that case I 
> create a situation in which some classes are pure semantic and others 
> are only there for style reasons and have a less than perfect semantic 
> name ("footnote-style-1" for example).

I don't really see the problem here.


> > > the second is a bit more muddy I think, but the important part there 
> > > is: "processing BY user agents". User agents have no interest in 
> > > semantics, so I fail to see here also why classes may be used to 
> > > define semantic roles.
> > 
> > Microformats.
> 
> Don't get me wrong, microformats are a good idea, but they lack the 
> construct in standards to be used efficiently. They should not use title 
> or class attributes. They specify a role and pure semantics and have 
> absolutely nothing to do with styling on their own.

I don't understand what you are saying here.


> > > The fact that a class should be named "footnote" for example is only 
> > > so you will not get in trouble (unlike when you use a name like 
> > > "red" or "left"). But this only tells me (the author) that this 
> > > element should be styled like a footnote and for the user agent that 
> > > it should render it like a footnote. It should not tell me (or 
> > > anything else) that it IS a footnote. This would lead inevitably to 
> > > inflexibility.
> > 
> > Why not enclose your footnotes in <aside> elements?
> 
> Because it isn't an aside.

What are footnotes if _not_ asides?


> > Moreover, a note is not necessarily presented as a "footnote" (i.e. 
> > moved to the end of the "page"), it can be shown in the margin (as in 
> > the WHATWG version of the HTML5 spec) or in popup panels when you 
> > click on a word or "footnote reference" (similarly to definitions in 
> > the old HTMLHelp on Windows).
> 
> Very true, that is exactly what I have been saying. The current spec 
> does not take this into account. As it stands now, I must assign a 
> class-name to the footnote and then style (and perhaps script) based on 
> that class-reference. But it fails to give me a proper element to do 
> this. Like I said, I think the Mark element would be great, but then 
> either it should get a "role" atribute or the examples given in the spec 
> should give it a more flexible meaning. Footnotes (and the likes) fall 
> in the same catagory as definitions, so why not give it an element just 
> like it? (or broaden the meaning of the dfn-element).

I'm confused here, because on the one hand you are saying that the 
suggestions in the spec give semantics instead of making things be styled 
like footnotes, and on the other hand you are saying that what you want is 
semantics and not something style-specific.

You agree, here, that what's in the spec for notes is equivalent to a 
footnote. But <aside> was in fact invented precisely for this case. Yet 
you argue that <aside> isn't good for footnotes.

So I don't really know what to change to satisfy your feedback.


On Sun, 2 Nov 2008, Pentasis wrote:
> >
> > Why does the spec need to provide you with a "proper element"?
> 
> Because I was under the impression we want a semantic web?

That is not a-priori a goal, no. Semantics are merely a tool we have at 
our disposal to achieve our goals of making the Web more accessible, 
powerful, and so forth.



On Wed, 5 Nov 2008, Pentasis wrote:
> >
> > This would only work in new browsers and is wordy: <reference 
> > class="abbreviation" title="some description">someword</reference>.
> 
> [...] this tag can be used to mark up any possible reference-type word 
> (notes, sidenotes, footnotes, translations, meanings, definitiones, you 
> name all of them and then some). So with just one tag, I catch all 
> possible semantics within a classified wordgroup.

I don't really see how the above provides any more semantics, or solves 
any more problems, than:

   <abbr title="some description">someword</abbr>

Could you give an example of a problem faced by a user or author (or 
implementor) that your <reference> proposal solves?



On Tue, 11 Nov 2008, Tab Atkins Jr. wrote:
> On Tue, Nov 11, 2008 at 5:33 PM, Eduard Pascual 
> <herenvardo at gmail.com>wrote:
> 
> > It is a quite common practice on current web pages to style the h1..h6 
> > elements to have them blend properly with the overall style of a site. 
> > For HTML4/XHTML1 documents this is quite trivial; but with HTML5 the 
> > "number part" of the heading element doesn't reliably define the 
> > actual heading level anymore (specially when dealing with server-side 
> > includes and / or user-provided content). I have tried to figure out 
> > some CSS selectors to handle this task with HTML 5 documents and they 
> > go completely crazy before getting anywhere near to being accurate: 
> > there is an insane ammount of element-nesting combinations to keep 
> > track of. Is there any sane way to deal with this basic need?
> 
> Generally you want to decide if you're going to use the numbered range, 
> or just <h1>.
> 
> If the former, just work it like you always would.  If the latter, you 
> have to do something like "h1 ~ section h1" to match what would 
> otherwise be an h2.  This will also match deeper headings, of course, so 
> you want to put in the h3-equivalent selector as well, and possibly 
> further.
> 
> However, this is an interesting problem in general, that is perhaps best 
> served by CSS itself.  Perhaps something like a :heading(n) pseudoclass, 
> which'll match headings of the given level.  What qualifies as a 
> heading, and how they nest and change levels, would be up to the markup 
> language (html5 in this case).  Vanilla html4 would just naively report 
> <h1> as matching :heading(1), <h2> as matching :heading(2), etc.  Html5 
> would match according to the heading-depth algorithm, and take into 
> account both the <hn> number and the depth within <section>s.

Yeah, this is something for which a CSS solution might be better on the 
long term. This was raised on www-style here:

   http://www.w3.org/mid/6ea53250811171036o17a31077wee78cd303601414b@mail.gmail.com

I don't know what the way to track feedback to the CSS list is these 
days, maybe a more active member of the CSS working group could help us 
here? How do we follow this feedback through the CSSWG process?



On Sat, 1 Nov 2008, Eduard Pascual wrote:
>
> First of all, I'd like to avoid any missunderstandings: I have nothing 
> against the <mark> element itself; although I'm afraid my previous 
> e-mails may lead to think otherwise. It could be a really good addition 
> to HTML but, IMHO, it isn't yet, and I'm trying to show why I think so.
> 
> On Sat, Nov 1, 2008 at 2:57 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Sat, 1 Nov 2008, Eduard Pascual wrote:
> > >
> > > What's the difference then between <mark> and <span> then? I mean, 
> > > does the <mark> element provide anything that <span> with an 
> > > appropriate class wouldn't?
> >
> > A default style when there's no CSS support, support in accessibility 
> > tools, the ability for search engines to understand what's going on, 
> > easier round-tripping between editors, simpler rules in CSS and other 
> > selector-like environments, etc. The usual benefits of semantics.
> 
> Let's take that point by point:
> 
> -> A default style when there's no CSS support: that's entirely 
> presentational; and although I may accept it as a side-bonus, I don't 
> feel presentational arguments are a good base for including/excluding a 
> new element.

A default style is specifically not what is generally considered 
"presentational", in that the default style can (and will) vary from UA to 
UA. The point is that there is _a_ presentation, though what it is may 
vary. This is the same reason <em> is not the same as "italics" and thus 
not the same as <span> with some CSS rules.


> -> Support in accessibility tools: that's plain daydreaming: what kind 
> of support can an AT provide without any hint on whether the <mark>'ed 
> text is a search term, or the line of a code snippet that caused a 
> crash, or the total price of the orders in a shopping cart, or whatever 
> other usage authors may come up with?

An AT (indeed any Web browser) can provide a list of all <mark> elements 
and allow the user to jump to them directly. (In a visual browser one 
would imagine this as marks in the scrollbar widget, for instance.)


> -> The ability for search engines to understand what's going on?? 
> Comming from someone else, I'd think they are simply wrong, but comming 
> from Ian I really hope you were joking: besides a SE would be as 
> clueless on that aspect as an AT; this would extremelly easily abused by 
> "black hat" SEO, to the point of making the element completely 
> meaningless for SEs: just a "mark { display: none; }" rule and a site 
> becomes able to freely spam "highlighted" keywords across the entire 
> page. And, although many SEs are capable of checking CSS sheets, it's 
> almost trivial to achieve the same from JavaScript, and even to 
> obfuscate the script if any SE managed to figure the trick out.

I think <mark>'s only use from a search engine perspective is allowing 
text to be marked up specifically _without_ it affecting the weight given 
to it by styles. For example, a search engine might well, if it 
deteremined in some sense that the markup of the page was trustworthy, 
give more weight to keywords found in <strong> or <b> elements; but it 
would be bad to give more weight to words marked with <mark>.


> -> Simpler rules in CSS and other selector-like environments: I simply 
> can't believe that this came from an editor of the CSS3 Selectors 
> module. How much simples is "mark" than ".match", ".crash_line", 
> ".total", and so on? The only difference is a single dot; plus the fact 
> that classes give much more flexibility that directly styling (or 
> selecting on any other similar environment) could ever allow. And 
> finally, it's worth to mention that, as soon as a page needs to use 
> <mark> for two or more different purposes, there is no other way to 
> differentiate them in selectors than classes (and no way at all for ATs 
> or SEs to differentiate then, BTW).

Avoiding the use of classes, whether you think it is significant or not, 
is a simplification.


> -> The usual benefits of semantics. Honestly, that's a really good 
> purpose; it's only that it's not achieved. If you look again at the 
> counter-arguments above, you should be able to notice that they are 
> nothing else than the usual drawbacks of lack of semantics. Because, 
> simply put, the semantics defined for <mark> are so vague that, in 
> practical terms, they are the same as no semantics at all. Pentasis's 
> initial proposal would be a simple and efficient solution to this issue: 
> with some sort of type/role/whatever attribute (based on a well-defined 
> list of allowable values), an AT could tell the user why some text is 
> marked, a SE could figure out what's really going on, and a designer 
> could rely on that attribute upon selection instead of defining classes 
> with an entirely presentational purpose.

I don't really follow. Could you give some concrete examples of what you 
mean here?



On Sun, 23 Nov 2008, Benjamin Hawkes-Lewis wrote:
> 
> Does DD have an implicit P, much as it has an implicit Q/BLOCKQUOTE?

On Sun, 23 Nov 2008, Geoffrey Sneddon wrote:
> 
> [...] a run of text nodes (and phrasing content elements) is a 
> paragraph, much like an explicit one created by the p element. 
> <http://www.whatwg.org/specs/web-apps/current-work/#paragraphs> details 
> this in-depth.

What G said.


On Mon, 24 Nov 2008, Lachlan Hunt wrote:
>
> All elements currently defined to be in the heading content category 
> (h1-h6 and header) are also included within the flow content category. 
> It seems that it would be easier and more consistent to state the 
> definition of heading content that:
> 
>   All heading content is also flow content. Any content model that
>   expects flow content also expects heading content.
>
> And then remove "Flow content" from category lists for those elements, 
> as it would be implied by "Heading content".

I've instead made all the phrasing elements also say they're flow 
elements, and then made the subset relationships explicit in the content 
section but non-normative.


> Additionally, to improve readability, it would be useful to add a note 
> to the definition of flow content that it includes all of heading 
> content, phrasing content and embedded content; and a similar note in 
> the definition of phrasing content that it includes embedded content.

I've actually removed all the comments to this effect, as it was getting 
kind of confusing. Instead:

> Finally, it would be useful if the spec eventually included some kind of 
> diagram that illustrated the relationships between each of the 
> categories.

I've included a diagram. If anyone can make a better one, please feel 
free!


On Mon, 8 Dec 2008, Calogero Alex Baldacchino wrote:
> Ian Hickson ha scritto:
> > What terminology would you prefer rather than "subtree"? (We can't say 
> > document, since we are also trying to define conformance rules for 
> > disconnected subtrees handled from scripts.)
> 
> I was thinking again on that. Let me suggest something like the 
> following (and just do suggest, I'm far from wishing to impose my point 
> of view, and don't want to be pedantic, but I belive deeply exploring 
> every alternative may improve the specification).
> 
> "The _id_ attribute represents an element unique identifier in the 
> subtree within which the element finds itself and must contain at least 
> one character. In this context, a subtree is either a whole document 
> tree, or a tree of Node instances containing HTMLElements and 
> disconnected from any HTML document; a subtree of a document tree is 
> contained in a subtree of the first type, thus id values must be unique 
> in the containing document (e.g. a duplicate id inside a document tree 
> is always illegal, even if a branch of the document can be isolated 
> where the id is unique, unless such branch is removed from the 
> document).
> 
> This specification requires the _id_ attribute value to be unique in a 
> subtree of the former type, thus a subtree of the latter type (e.g. a 
> document fragment manipulated by a script) to be inserted into an HTML 
> document must fulfil such requirement, as well as any other requirements 
> defined in this specification for conformance purpose. Any API dealing 
> with ID properties in any type of subtree must consider the _id_ 
> attribute value of an HTMLElement as the element's default ID property; 
> however, this specification doesn't preclude an element having multiple 
> IDs, if other, API-specific mechanisms can set an element's ID in a way 
> that doesn't conflict with the id attribute" - then the rest.

I've instead invented the term "home subtree" and used that.


> One rational for the above is that, formally, a subtree disconnected 
> from any actual HTML document might be out of scope for current 
> specification, which defines conformance rules for HTML documents and 
> related contexts (such as a script context or a browsing context, both 
> applying to a 'connected' subtree, as far as I've understood), while a 
> subtree which is disconnected from a specific HTML document, but is 
> contained into another one (thus coinciding with the containing document 
> tree) is yet covered by the constraint for whole documents.

Subtrees disconnected from a document would be those held by scripts 
during manipulation of content fragments. Those are in scope.


> Another rational is that current specification, while relying on at 
> least one method affected by IDs uniqueness in a document tree (that is, 
> DOM Core Document.getElementById), does not provide, nor refers to, any 
> API which might be directly affected by the uniqueness of an id 
> attribute value in a disconnected subtree, thus such an API may be 
> indirectly related to id values uniqueness if ID properties are relevant 
> for its facilities, but the subtree itself cannot be constrained by 
> conformance rules before its insertion into an actual HTML document.

I don't follow.


> A further rational is that a disconnected subtree might contain Node 
> instances not implementing the HTMLElement interface, such as a 
> DocumentFragment node, but also MathML/SVG elements, which might be 
> embedded content elements coming from an HTML document tree, but also 
> from a document of a different kind where the embedded content was 
> represented by HTML elements, thus, without a sure knowledge on the 
> subtree origin, applying an HTML-specific conformance rule might not be 
> a correct choice, until the subtree is to be inserted into an HTML 
> document.

We want unique IDs regardless of what other vocabularies are involved. The 
arguments for wanting unique IDness are language agnostic.


> For the question related to space characters inside an id value, I'd 
> suggest,
> 
> "An ID property is not expected to contain space characters, so the 
> value of an _id_ attribute should not contain any space characters. 
> However, an id attribute can hold a decoded fragment identifier value 
> for the purpose of same-document references, thus space characters are 
> tolerated for the purpose of conformance, in order to avoid applying 
> restrictions to an otherwise legal fragment identifier value not being 
> part of a _URL_."

I don't follow. Why would we allow spaces for URL matching? Surely it's 
fine to just say that fragment identifiers with spaces in them never match 
any legal HTML5 ID? (That's what HTML4 did.)


On Wed, 17 Dec 2008, Jim Jewett wrote:
> 
> The problem is that "sub" suggests it is less than the whole document.

Well, it might well be, since there might not be a document per se. :-)


> The most natural reading is the subtree rooted at that element.  By this 
> reading, an element cannot share an ID with an ancestor, but it could 
> share an ID with a sibling.

I've clarified the meaning.


> You might handle it by just saying "tree" rather than "subtree."

I'm not sure that "tree" really conveys things more clearly here.


> When parsing:
> 
>     <p id="test1"><span>abc</span>
>     <p id="test1"><span>xyz</span>
> 
> (1)  It sounds like the UA is required to associate #test1 with the
> *first* paragraph, instead of choosing arbitrarily.  This is a
> backwards-compatibility constraint on the DOM.

No, according to CSS, "#test1" matches both, because they have have the id 
"test1".


> (2)  It sounds like interoperability requires that a CSS rule targetting
>     #test1 span
> affect both paragraphs, which does place constraints on the
> implementation of the ID map.

You don't need an ID map for CSS. CSS works the other way around, starting 
with an element and testing whether it matches an expression.


> (3)  Because of (2), it sounds like the UA parser is required to 
> remember that the second paragraph also has an id of "test1", even 
> though the DOM won't use it directly, because that (invalid) information 
> must still be made available to CSS.

Yes.



On Thu, 18 Dec 2008, Benjamin Hawkes-Lewis wrote:
> Ian Hickson wrote:
> > This is an area that has had some research done:
> > 
> >    http://24ways.org/2006/marking-up-a-tag-cloud
> >    http://microformats.org/wiki/tagcloud-brainstorming
> > 
> > I don't really see a compelling answer yet, and frankly tag clouds as 
> > a whole aren't really so important that we need dedicated markup. So I 
> > haven't put anything in the spec about it yet.
> > 
> > Generally I would recommend something like the 24ways proposal:
> 
> So would I. :)
> 
> > If people think all this is worth mentioning in the spec, I can add 
> > it. Let me know.
> 
> Given how many worse ways I see tag clouds marked up, I think it would 
> be a great idea. The more good markup patterns in the spec (and the 
> authoring guide) the better, and both of the patterns you mention are 
> preferable to nested EM or bare SPANs.

Ok, done.



> > Media independence is what we're going for here. <font>, for example, 
> > isn't media-independent.
> 
> As I think I've pointed out before, "i" for ship names and taxonomical 
> names isn't particularly media independent: they are italicised in 
> English print and English braille tends to mirror such conventions, but 
> they aren't particularly differentiated when speaking, whereas a dream 
> sequence might well be.

I'd have said the opposite, actually -- when I read a ship name, I insert 
a short pause before the name of the ship and speak it with more stress 
("They boarded the _intrepid_") whereas if I'm reading a book with 
italicised dream sequences, I don't make any changes to my speech 
patterns. Either way, it is media-independent, because UAs of non-visual 
media are allowed to style these elements, they are no longer tied to 
visual media only.

I agree that conventions differ between media, but if the author wants to 
tweak the settings for each media, CSS and class values already exist to 
take care of this. At least now there is a suitable element to do this 
with; before <i> would have made sense for visual media, but restyling it 
for other media would have been dubious by definition.


On Wed, 24 Dec 2008, Calogero Alex Baldacchino wrote:
> 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?

No, the human is central to the process. The machine is but a tool.

But this is rather philosophical, so I'll skip the rest of this topic. :-)


> > 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.

I think it would be suboptimal for a speech synthesiser to pause the 
synthesis half-way through a word to play an audio icon, certainly. I 
don't think HTML5 as written requires that though. Icons can be played 
asynchronously too.


> 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!).

My apologies for the confusion -- as editor, I have made a commitment to 
reply to all substantial feedback sent to the WHATWG list, which can lead 
to the appearance of me being behind the times as I reply to old e-mails. :-)


> > > 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?

Doesn't HTML5 do this?


> > > 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).

Ah, this may indeed be the source of confusion. I was using "important" 
here in the strict dictionary sense, as used in the spec.


> 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).

I disagree with your assessment that only the product name is suitable for 
<b> in an advertisment.

Search for "paint" on Google. Notice that the advertisements highlight the 
keyword "paint" in the ads, even when this is not part of the ad. (This 
would be a good use of <mark>, rather than <b> or <strong>.)


> [...]

I don't really understand where you are going with the rest of this 
discussion; if you have any specific requests for changes to the spec, 
please let me know. I encourage you to post essays on markup language 
theory to a blog rather than here. :-)


> > 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.

I think balancing what authors are likely to do (e.g. they wouldn't 
reliably use fine grained semantic labels) vs what is likely to be usable 
by user agents (a few different kinds of renderings) is the balance we 
have to strike. There's no point solving problems if the solutions aren't 
going to be used (thus there's no point providing formal ways of marking 
up ship names vs irony vs dream sequences), and there's no point solving 
solutions if the solutions aren't good enough to work (e.g. just having a 
<font> element with no regard to other media).

As far as I can tell, the current spec strikes a good balance here.


> > > 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 

I have no idea what "cross-media presentational semantics" means. Is it 
bad? Why?


On Wed, 24 Dec 2008, Calogero Alex Baldacchino wrote:
> 
> Just one thing: a note says a synthetic click doesn't perform the same 
> actions as required by the click() method, but those seems suitable as 
> pre-click activation steps (or post-click, if needed), eventually 
> telling the UA to take care of the synthetic click source (user's device 
> or document scripts) if such causes any difference, aren't they?

I... have no idea what you are asking here.


> And a little aside: it is said context menus should inherit, but the 
> inheritance is not yet defined

I just need to write the text for that, it's not difficult (just a matter 
of walking up the ancestor chain until one is found).


> so let me suggest a convergence with events flow: during the capture 
> phase, showing the menu might be prevented by stopping the propagation 
> of a triggering event (e.g. by the UA because of a user preference, or 
> by an ancestor's handler to make custom menus available only under 
> certain conditions -- in order to have it working, perhaps each 
> platform-dependent method might be abstracted as a 'right click', as 
> some sort of variant on synthetic clicks); at the target, if a menu is 
> provided for the element, it is shown as described, and the triggering 
> event propagation is stopped (treating the menu show as a kind of 
> post-run default action); otherwise, while bubbling, the triggering 
> event might cause a context menu being shown as soon as an ancestor 
> providing one is found (then stopping the event propagation); if no 
> custom contextual menu is provided in the element subtree, the UA takes 
> the control and shows a proper menu at the target element (if any is 
> provided by the implementation).

That seems way more complicated than necessary...


> About my half-proposal (no more than half), it was suggested to me by 
> timeless' ideas on generic commands triggered by actions a user might 
> customize AND carry from one UA to another, thus I thought on the fly to 
> something I supposed might have been consistent cross-browser and 
> potentially coexisting with developers' choices, through an embeddable 
> mechanism, either as a part of the document, or a separate document to 
> be linked, or provided as default by the UA, and with some sort of 
> cascading (or precedence) rules, on the same line as CSS; perhaps such 
> might be considered as an evolution.

I have no idea what this means, I'm sorry.


> The part I was considering more valuable was what I called (with a 
> temporary name) a 'mousebehavior' describing linear movements of a 
> pointing device: actions might be as easy as a succession of movements 
> in different directions (right, left, up and down), detected as 
> coordinates difference between a 'start' and an 'end' point (detecting 
> one direction at a time); such might be helpful, I guess, as an aid for 
> certain disabilities, in conjunction with a pointing device capable to 
> 'rectify' jugged movements, picking the start point as a mean value in a 
> certain range (the same way a mouse driver considers a 'mouse up' as 
> determining a 'click' if a 'mouse down' happened in a short range of 
> pixels), and the end point as the mean value in a range where the user 
> rests for a certain interval before moving again.

I really don't understand what you are saying here. What is the problem 
you wish to solve?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'