- From: <bugzilla@jessica.w3.org>
- Date: Tue, 14 Jun 2011 04:26:38 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12845 --- Comment #27 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-06-14 04:26:38 UTC --- The command API _does_ work on every HTML element, because you can use tabindex="" to make any element into a Command for the purposes of the command API. There are certain elements where it isn't useful, e.g. it doesn't make sense really for <input type=range>, though it does make sense for <input type=button>, but like most of the global features, it makes sense most of the time. So e.g. HTMLTrackElement.label vs the command API label is a minor issue (you wouldn't sanely use <track> as a command, though I guess there might be some contrived situations in which you could expose its commandy behaviour if you tried and especially if you didn't care too much about whether your document was valid), but if we cared we could just make label="" be the label of the command if it's a <track> element, like we do with <option>. I haven't done that so far because it isn't ever going to be done by someone sane. Some of the other ones, e.g. disabled on <textarea> and its cousin on the command API, or label on <menu>, are less easy to deal with. Maybe better would be to have certain elements on which you cannot specify tabindex="", though so far global attributes haven't had such constraints defined (e.g. you can use hidden="" on <style> even though that would make no sense, or indeed can use tabindex="" on elements like <source> or <meta> or even <option> where it really doesn't make sense). That's orthogonal to what the DOM APIs do, though. If you want the global attributes to be less global, please file a separate bug. My intent with shadowing these at the IDL level was that only the most derived one would exist. This stuff was written before we considered (or at least before I was aware of us considering) actually having stuff on non-leaf interfaces exposed on non-leaf interface objects. It's not a big deal that they both be there though, it'll just be one of those bits of trivia that is used in programming contests... I'd be fine with making shadowing illegal so long as we introduced a feature whereby one could explicitly override something, as seen in various programming languages, e.g. from comment 0: interface Bar : Foo { attribute DOMString quux; override; } That would avoid us making unintentional mistakes. Having said that, I'm not aware of us ever having made such a mistake. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Tuesday, 14 June 2011 04:26:40 UTC