|
Posted by Lea GRIS on April 16, 2008, 8:54 am
Please log in for more thread options
Hello,
Are there any generic and CSS standard mean of highlighting an accesskey?
I only fond a workaround by encapsulating the corresponding letter in a
<em></em> inside the label. But it is not applicable for a submit button
which label is not a content.
Here is en example:
<form method="get" action="http://example.com/cgi-bin/smokeping.cgi"
enctype="multipart/form-data" id="rangeform">
<fieldset><legend>Time range:</legend>
<label for="start"><em>F</em>rom:</label>
<input type="text" name="start" tabindex="1" value="2008-04-16
11:22" accesskey="f" id="start" />
<label for="end"><em>T</em>o:</label>
<input type="text" name="end" tabindex="2" value="now"
accesskey="t" id="end" />
<input type="hidden" name="target" value="World.Europe.France.IPv6" />
<input type="hidden" name="displaymode" value="n" />
<input type="submit" tabindex="3" name="Generate!"
value="Generate!" accesskey="g" />
</fieldset>
</form>
There would also exist another unsatisfying possibility with CSS:
input:before { content: attr(accesskey); }
But it would display the accesskey outside the label and before or after
the input field. Furthermore, there are few compatible browsers.
Regards,
--
Léa Gris
|
|
Posted by Jukka K. Korpela on April 16, 2008, 4:51 pm
Please log in for more thread options
Scripsit Lea GRIS:
> Are there any generic and CSS standard mean of highlighting an
> accesskey?
That would be a CSS question, not HTML, right? The answer is "no", by
the way, but that's off-topic.
The HTML side of the matter is that accesskeys, as defined in HTML, are
mostly useless or worse than useless, partly because they may interfere
with browser or system accesskey assignments that users are familiar
with and may really need.
So just forget them. And you (your users) don't need tabindex either, if
your form fields are in a logical order, as they whould.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
|
|
Posted by Sander Tekelenburg on April 17, 2008, 8:20 pm
Please log in for more thread options
[...]
> The HTML side of the matter is that accesskeys, as defined in HTML, are
> mostly useless or worse than useless, partly because they may interfere
> with browser or system accesskey assignments that users are familiar
> with and may really need.
In my book letting a site hi-jack browser functionality would count as a
browser bug. In that same book browser bugs should be repaired by
browser vendors, not by web publishers. The more web publishers use
accesskey, the more users afected, the more likely browser vendors will
bother to fix the bug. Thus this could be considered an argument for
using accesskey...
IMO a more valid argument against acceskey is that it's a per site
solution for something that ought to have a cross site solution. (Yep,
browser vendors again ;))
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
|
|
Posted by Harlan Messinger on April 17, 2008, 8:44 pm
Please log in for more thread options Sander Tekelenburg wrote:
>
> [...]
>
>> The HTML side of the matter is that accesskeys, as defined in HTML,
>> are mostly useless or worse than useless, partly because they may
>> interfere with browser or system accesskey assignments that users
>> are familiar with and may really need.
>
> In my book letting a site hi-jack browser functionality would count
> as a browser bug.
It's a feature provided by the HTML standard, so whatever you may think
of it, it isn't a bug for a browser to implement it.
> IMO a more valid argument against acceskey is that it's a per site
> solution for something that ought to have a cross site solution.
> (Yep, browser vendors again ;))
How can you have a cross-site solution for something that is inherently
site-specific? That isn't the problem with access keys, any more than
it's a problem that the same Ctrl key combination will serve different
purposes in different OS windows.
|
|
Posted by Jukka K. Korpela on April 18, 2008, 5:37 am
Please log in for more thread options Scripsit Sander Tekelenburg:
> In my book letting a site hi-jack browser functionality would count
> as a browser bug.
Well, maybe, and browsers _could_ actually implement accesskeys in a
manner that does not do that, but they don't. The HTML specification is
naive in its assumptions, pretending that browsers could recognize Alt+F
as a shortcut for a page-defined accesskey, as if Alt+F were not bound
to some function in most situations (and that users could use
page-defined accesskeys and would want to do that).
> In that same book browser bugs should be repaired by
> browser vendors, not by web publishers.
The fundamental flaw is in the specifications. The best browsers could
do now is to stop recognizing accesskey attributes at all.
> The more web publishers use
> accesskey, the more users afected, the more likely browser vendors
> will bother to fix the bug.
You seem to advocate a catastrophe theory. According to it, should we
start pushing vendors into implementing at least HTML 2.0? That is,
should we use all the SGML features defined in specifications HTML 2.0
through HTML 4.01, like <title/foo/ for a title element? Or should we be
modern and use native XHTML, _without_ dirty Appendix C trickery, and
naturally sending application/xhtml+xml to everyone?
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
|
| Similar Threads | Posted | | How can one put an accesskey on a Select (Drop down box) | November 18, 2004, 11:49 am |
| xhtml - accesskey for select not allowed? | December 11, 2005, 11:00 am |
| Invoking an objects accesskey functionality from javascript code. | December 15, 2006, 7:13 pm |
| Syntax highlighting in TEXTAREA - possible? | October 22, 2005, 4:59 pm |
| Highlighting image button | January 14, 2007, 10:59 pm |
| Highlighting a Link Destination | March 10, 2007, 10:25 pm |
| Simple table row highlighting - on mouseover | October 13, 2004, 10:02 am |
| Dynamic image which is highlighting/increasing the text/area when the curser moves over it? | July 20, 2006, 1:45 am |
|
XML Sitemap