[whatwg] accesskey=""

[Ian Hickson]

After many years of pondering on the issue, I have checked in a definition 
of the accesskey="" attribute.

On Thu, 20 Sep 2007, Maciej Stachowiak wrote:
> 
> Keyboard shortcuts are useful for a number of reasons:
> 
> - They are important to usability of normal desktop applications. The 
> typical native application includes a number of keyboard shortcuts and 
> experienced users often make use of them in preference to the mouse or 
> tab cycling. For instance, many Mac OS X desktop applications feature 
> Cmd-Z as a keyboard shortcut for undo, and this is faster than picking 
> the command from a pull-down menu.
> 
> - Keyboard shortcuts can be an aid to accessibility for users who cannot 
> readily operate a pointing device such as a mouse, due to motor or 
> vision difficulties.
> 
> - Many mobile devices have a pointing device that is very awkward for 
> anyone to use.

These are good reasons to have a feature for keyboard shortcuts.


> HTML 4.01 has a feature for keyboard shortcuts, the accesskey="" 
> attribute. But it has many problems:
> 
> - It is tied to a specific control in the page. But in native 
> applications, many keyboard shortcuts do not have a direct one-to-one 
> correspondence with a specific control element. For example, you may 
> want a shortcut to focus an element that is also capable of activating, 
> or vice versa, but accesskey can't let you choose which to do. Or you 
> may want increment and decrement commands where the in-page UI is a 
> slider control.

I have allowed the  element to be given an access key, which 
allows any scriptable behaviour to be given a keyboard shortcut.


> - Keyboard shortcuts are not discoverable. It's not obvious looking at a 
> web application whether it even has keyboard shortcuts, let alone what 
> they are.

I have provided an API that returns a string representing the keyboard 
shortcut that a particular element has assigned to it, so that scripts can 
expose keyboard shortcuts without having to guess as to the platform 
conventions.

I have also added the right hooks for user agents to provide the feature 
that you propose (not quoted here) for putting the commands into the 
menubar of the application.


> - There are barriers to the UA making keyboard shortcuts discoverable. 
> Putting a marker on elements with an accesskey value at all times messes 
> with the appearance of the page as intended by the designer of the page. 
> Having a visual indicator that appears when the user depresses the 
> appropriate secret modifier key is only discoverable if the user knows 
> the secret modifier, which is unlikely to be the case.

This is now addressed by those aforementioned hooks, which basically make 
any activatable or focusable element with an accesskey="" attribute into a 
command that can be exposed in a menu.


> - There are barriers to the web app making keyboard shortcuts 
> discoverable. The web app does not know what modifier keys the UA will 
> add, if any, so it cannot display the true shortcut in the page or in 
> help materials.

The aforementioned DOM attribute now enables this.


> - The set of keys available for shortcuts is not the same across 
> different devices, operating systems and browsers, but the syntax for 
> accesskey requires choosing one. For example, 0-9 are the only keys that 
> could reasonably be available on a mobile phone with only a numeric 
> keypad. But in Safari on Mac OS X, 0-9 with the normal modifier key for 
> keyboard shortcuts are taken by the browser itself.

I have addressed this by making the accesskey="" attribute take a 
space-separated list of characters, and requiring the user agent to use 
the most useful one. For compatibility with legacy UAs, providing just one 
character is naturally still supported, but as user agents support the 
new feature, authors will be able to transition to providing more than 
one shortcut character.

For future extensibility, I have also required tokens with more than one 
character to be ignored for now. We can later add identifiers for various 
purposes, e.g. accesskey="help" to mean that the user agent's default 
"help" key should be used, whatever that is.


> - The UA may wish to present a list of available keyboard shortcuts to 
> the user in some sort of list, but there may not be a good label 
> available. All the UA can use is the label of the control, but a label 
> that's good in the context of the page may not be very good in an 
> out-of-context list. For example,  has two 
> buttons labelled "Go" at the very top, one of which performs an Amazon 
> search and the other of which performs a Web search. I'm not sure either 
> of these buttons is a great choice for a keyboard shortcut, but if there 
> were a list giving their shortcuts you'd really want the labels in the 
> list to be "Search Amazon" and "Search the Web" respectively, not "Go".

This is resolved partially by allowing the author to put the accesskey="" 
attribut

[whatwg] example of serialization problems

[Shelley Powers]

Review of HTML5 document:

Here's a good example of a potential point of confusion for readers of 
the spec when it comes to serialization:


In section 4.5.8 you introduce the ul element, and then demonstrate it 
with a several child li elements, each of which is shown with an HTML 
serialization.


In second 4.5.9, you introduce the li element, and then demonstrate the 
li element using a serialization approach that would work with both 
XHTML and HTML serializations.


And still later, in section 4.5.13.1, you again demonstrate li elements 
using only the HTML serialization format.


In all of this is an implicit assumption of the capabilities of your 
audience, that they understand the differences between the two. Yet, 
this isn't stated as a prereq for the audience of the document. In fact, 
you state that a familiarity with XML is helpful, but not required. And 
as far as I've been able to see, though I may have missed it, 
discussions about closing tags doesn't take place until section 8.


My suggestion would be to include both HTML and XHTML serializations, 
carefully differentiating between the two. Or to provide separate 
documents detailing the elements and their serialized form, HTML version 
and XHTML version, if you want to inter-mix model and serialization 
technique.


As for Section 8, that really is for user agent developers, only. 
Seriously, I doubt you expect typical web developers or designers to get 
much from this section. I would almost expect this to be a separate 
document. What would be helpful is to bring this section up one level in 
complexity, specifically focused at web developers/designers.


More later

Shelley

[whatwg] section 3 top headers

[Shelley Powers]

More on HTML5 draft review:

Your top level section headers in Section 3 don't make a lot of sense.

In particular, you insert a section on the paragraph element, at the 
same top level that you reference all HTML elements. Why did you plunk 
the paragraph in as a separate section? And I'm also assuming I misread 
the bit about other elements straddling paragraphs. I'm assuming you 
don't mean that something like


And let's look at the section headers:

Introduction
Documents
Elements
Content Models
Paragraphs
APIs in HTML documents
Dynamic Markup insertion

There's no cohesive pattern to this section. One moment you're talking 
about Elements in the DOM, the next paragraph elements. And you're 
actually defining the paragraph element, but the elements are described 
fully in Section 4. Where you also describe the paragraph element.


That's a lot of jumping around for folks.

More later

Shelley

[whatwg] Section 3 semantics and structure

[Shelley Powers]

More general comments on the HTML5 draft:

In section three, you mix structure and semantics, but the two are not 
necessarily compatible.


For instance, we see an introduction to the Document, and then 
immediately proceed into a description of Documents in the DOM. Frankly, 
I don't see how a description of the DOM fits either structure or 
semantics. To me, structure would be the structure of the markup in the 
document, and the semantics would be the, well, it's hard to say what it 
would be, you apply semantics to elements, such as section and header. 
Whatever it is, it's not DOM related.


Then you follow up with Security. What does this have to do with 
structure or semantics?


Perhaps if the intro section was filled in, we would have an 
understanding of what you mean by structure, and semantics. Right now, 
though, I see what is basically a bucket of information, somehow grouped 
under this heading, perhaps because it doesn't fit anywhere else.


Now you do a nice description of what you consider as semantics in 
section 3.3.1, and I would expect this, then, to be followed by a 
listing of the elements, but again, there's the DOM. There's no cohesive 
pattern to the document, especially when the different document levels 
are mixed so haphazardly.


I think of a document as a communication between writer and audience. 
Now there are probably three audiences for HTML5:  user agent 
developers, such as browser companies; web developers, interested in  
the DOM, scripting events, and so on; and designers or others, more 
likely interested in the markup.


I, as a web developer/designer, am not really interested in the user 
agent aspects of the specs. Another person who is a designer, may not be 
interested in the developer or UA aspects. But all of us are forced to 
go through material addressed to all three audiences just to find the 
information we need.


I, a designer interested in learning about the new semantic elements, 
have to wade through sections on the DOM and security, including 
cookies, because I'm not sure when I'll be getting to the bits I need. 
There's no clear demarcation between audiences in the document.


More later

Shelley

[whatwg] notes on current HTML5 draft

[Shelley Powers]

Per Ian Hickson's request, first of my notes on the current HTML 5 draft

Section 1.6.3, where you compare HTML5 with XHTML2 and XForms, you write

"However, XHTML2 and XForms lack features to express the semantics of 
many of the non-document types of content often seen on the Web. For 
instance, they are not well-suited for marking up forum sites, auction 
sites, search engines, online shops, mapping applications, e-mail 
applications, word processors, real-time strategy games, and the like.


This specification aims to extend HTML so that it is also suitable in 
these contexts."


This sounds more like marketing speak than something one would find in a 
specification. If it's important for an individual to know why they 
might want to use HTML5 over XHTML2, then the information should be 
given in detail, rather than in one vague paragraph.


In addition, I've not found that the HTML5 specification answers the 
claims given in the above paragraph. For instance, why would HTML5 be 
better for a mapping application than XHTML2? Or an auction site?


In section 1.7, you write

"The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot all 
represent the same content. For example, namespaces cannot be 
represented using "HTML5", but they are supported in "DOM5 HTML" and 
"XHTML5". Similarly, documents that use the noscript  feature can be 
represented using "HTML5", but cannot be represented with "XHTML5" and 
"DOM5 HTML". Comments that contain the string "-->" can be represented 
in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth."


"And so forth", is not something one wants to read in a specification, 
because we expect precision, and "and so forth" is vague, and imprecise.


Since the HTML5 supposedly represents both a HTML and a XHTML 
serialization technique, perhaps the document can take a lesson from the 
RDF community and provide a separate document, or at least a section 
detailing the two different serialization techniques. This would go far, 
too, in clearing up the confusion regarding XHTML. Too many people are 
making assumptions that "XHTML is dead" because the XHTML serialization 
of HTML5 is not spelled out as clearly as it could be.


You actually do mix the differences between the two throughout the 
document, but that, to me, seems to 'clutter' up the spec -- making it 
difficult to determine what's new in the spec. If the HTML5 document is 
a new model for web page markup, then the model aspect of the spec 
should be detailed separately from its various serializations, and that 
includes any API.


Right now, it's difficult to read the specification because it jumps too 
frequently between the abstract and the implementation, sometimes in one 
sentence.


More later.

Shelley

Re: [whatwg] About Descendent Tags

[Christoph Päper]

Ian Hickson:

On Fri, 1 May 2009, Christoph Päper wrote:

Ian Hickson:

I've renamed the old  to .

Did you consider using 'h' instead?


I think that would be confusing for people who have heard of  
XHTML2's 

(since it is quite different; HTML5's  is the better match there).


Well, "the rank of an |hgroup| element is the same as for an |h1|  
element", but to superset XHTML2's |h| more or less, |h|/|hgroup|  
would have to work, i.e. have a text for outlines, without |h#|  
descendants.


  Foo,
  FooBar,
  BarFoo,
  Foo and
  Foo

would all have to add "Foo" as a highest rank entry to the document  
(or section) outline.


Anyhow, I just wanted to make sure the option was considered. I don't  
care much either way. It's more important that |header| now matches | 
footer| better.


(And I certainly don't want to reopen the can of worms that is |hr|,  
which I still would expect to be treated like an empty |section| (or | 
h#|/|h|/|hgroup|), not like an empty |p|, thus possibly closing  
implicit sections.)