Re: [whatwg] Scoped tabindex proposal
On Thu, 31 Aug 2006, Simon Pieters wrote: Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. In general I think the better solution would be to change the tab order from CSS using CSS3UI's features, rather than changing the tabindex in HTML itself. For the rare cases where changing the tabindex is actually useful, it seems a small cost to require that the values be changed globally. It's also not that hard, you can just set all the tabindex values to increasing multiples of 100 in tree order, and then manipulate a local group by changing the values around. Basically I don't see this as something that is useful enough to warrant a new attribute. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. It seems like this would have a pretty poor back-compat story. Here's a pointer of where this (or something similar) is called for: http://accessifyforum.com/viewtopic.php?t=6034 This can be solved just by moving the tfoot. (Thanks to all the other people who contributed to this thread and gave good feedback. I don't have anything to add to those comments.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Scoped tabindex proposal
Hi, From: Aaron Leventhal [EMAIL PROTECTED] tabindex=-1 doesn't just remove items from the tab order. It also makes items focusable via mouse click or script, which is important when designing custom container widgets like spreadsheets, etc. via Javascript. In fact any negative value does it. Indeed. Don't try to overload the tabindex attribute. tabindex=scoped is overloading indeed, but changing the tab order algorithm isn't really overloading the tabindex attribute (if we would say that all tabindex elements are scoping elements). First, the browsers currently optimize it knowing that it's an integer. I agree that tabindex should still be a long (and not DOMString). Second, the scoping is orthogonal. Then it would be better to have a separate attribute. That also allows the use of the current tab order for nested tabindex elements, and the ability to declare unfocusable scoping elements. Third, magic values are less readable. It's voodoo. Ok. Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
Hi, From: Ric Hardacre [EMAIL PROTECTED] how about allowing decimals, where by default 1 implies 1.0? : [...] This also allows you to quickly associate the grouping of an input by it's value when viewing the source: You can already do that; just use tabindex 11, 21, 12, 22 and 30. Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
tabindex=-1 doesn't just remove items from the tab order. It also makes items focusable via mouse click or script, which is important when designing custom container widgets like spreadsheets, etc. via Javascript. In fact any negative value does it. Don't try to overload the tabindex attribute. First, the browsers currently optimize it knowing that it's an integer. Second, the scoping is orthogonal. Third, magic values are less readable. It's voodoo. - Aaron Simon Pieters wrote: Hi, Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. Here's a pointer of where this (or something similar) is called for: http://accessifyforum.com/viewtopic.php?t=6034 Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
On 9/1/06, Aaron Leventhal [EMAIL PROTECTED] wrote: Don't try to overload the tabindex attribute. First, the browsers currently optimize it knowing that it's an integer. Second, the scoping is orthogonal. Third, magic values are less readable. It's voodoo. Yes, yes, and yes. Completely agreed. -- Brad Fults
[whatwg] Scoped tabindex proposal
Hi, Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. Here's a pointer of where this (or something similar) is called for: http://accessifyforum.com/viewtopic.php?t=6034 Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
Interesting proposal. I think it's a useful suggestion, but it may be easier to add another attribute that controls the scoping, rather than trying to overload |tabindex|. Something like table tabaccess=scoped could work. In this case, tabaccess=global (or something equivalent) would be the default. -- Brad Fults NeatBox On 8/31/06, Simon Pieters [EMAIL PROTECTED] wrote: Hi, Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. Here's a pointer of where this (or something similar) is called for: http://accessifyforum.com/viewtopic.php?t=6034 Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
Simon Pieters wrote: So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. The table might not be focusable, but it needs to be in the tab order in some sense in order to resolve that local tabindex=1 into a global tabindex. For example: a id=outside1 href=... tabindex=1.../a div tabindex=scoped id=container1 a id=inside1 href=... tabindex=1.../a /div div tabindex=scoped id=container2 a id=inside2 href=... tabindex=1.../a /div a id=outside2 href=... tabindex=2.../a What is the global tab order now? I could see arguments for either: #outside1 #inside1 #inside2 #outside2 (DOM order) or... #outside1 #outside2 #inside1 #inside2 (all of the explicit tabindexes first in index order, followed by everything else in DOM order) Now what if I want the elements of #container2 to be before those of #container1 in the tab order? Can I also give these DIVs a tabindex?
Re: [whatwg] Scoped tabindex proposal
Hi, From: Mihai Sucan [EMAIL PROTECTED] I don't think we want another attribute. I tend to like the idea of having tabindex=-2. IIRC -1 is already reserved for skipping the control when navigating (maybe only in some proposals?). All negative values are for taking the element out of tab order. But why can't all values mean that the element is a scoping element? Perhaps someone wants the scoping element to be in the tab order aswell (can't think of a particular use-case off the top of my head though): div tabindex=24 span tabindex=26/span span tabindex=15/span /div div tabindex=11 span tabindex=23/span span tabindex=12/span /div I can agree with tabindex=scoped - it's good enough too. But how do you deal with the .tabIndex DOM attribute? It can't be long and DOMString at the same time. Changing it to DOMString might break some sites. Currently, if you for instance do: document.body.tabIndex = scoped; ...then it results in: body tabindex=0 Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
Le Thu, 31 Aug 2006 22:25:45 +0300, Simon Pieters [EMAIL PROTECTED] a écrit: Hi, From: Mihai Sucan [EMAIL PROTECTED] I don't think we want another attribute. I tend to like the idea of having tabindex=-2. IIRC -1 is already reserved for skipping the control when navigating (maybe only in some proposals?). All negative values are for taking the element out of tab order. But why can't all values mean that the element is a scoping element? Perhaps someone wants the scoping element to be in the tab order aswell (can't think of a particular use-case off the top of my head though): div tabindex=24 span tabindex=26/span span tabindex=15/span /div div tabindex=11 span tabindex=23/span span tabindex=12/span /div Yes, good idea. One also needs to define the tab order of the groups. But tables, divs, spans are not normally focusable. I can agree with tabindex=scoped - it's good enough too. But how do you deal with the .tabIndex DOM attribute? It can't be long and DOMString at the same time. Changing it to DOMString might break some sites. Currently, if you for instance do: document.body.tabIndex = scoped; ...then it results in: body tabindex=0 True. But I don't believe many sites will break because of this. Remember many web developers don't really care about types. They don't even know much about them. IMHO the number of sites that might break makes these cases neglectable. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Scoped tabindex proposal
Hi, From: Martin Atkins [EMAIL PROTECTED] The table might not be focusable, but it needs to be in the tab order in some sense in order to resolve that local tabindex=1 into a global tabindex. For example: a id=outside1 href=... tabindex=1.../a div tabindex=scoped id=container1 a id=inside1 href=... tabindex=1.../a /div div tabindex=scoped id=container2 a id=inside2 href=... tabindex=1.../a /div a id=outside2 href=... tabindex=2.../a What is the global tab order now? I could see arguments for either: #outside1 #inside1 #inside2 #outside2 (DOM order) or... #outside1 #outside2 #inside1 #inside2 (all of the explicit tabindexes first in index order, followed by everything else in DOM order) The second one is what I had in mind. Now what if I want the elements of #container2 to be before those of #container1 in the tab order? Can I also give these DIVs a tabindex? Then it would be better to drop the tabindex=scoped idea and instead define that any tabindex element is a scoping element, so you would use tabindex=1 on #container2 and tabindex=2 on #container1. I think this makes more sense than changing tabIndex to a DOMString, and it is more flexible. Regards, Simon Pieters
Re: [whatwg] Scoped tabindex proposal
Simon Pieters wrote: Then it would be better to drop the tabindex=scoped idea and instead define that any tabindex element is a scoping element, so you would use tabindex=1 on #container2 and tabindex=2 on #container1. I think this makes more sense than changing tabIndex to a DOMString, and it is more flexible. And, I guess, tabindex=0 would be roughly equivalent to your tabindex=scoped. Seems reasonable to me.
Re: [whatwg] Scoped tabindex proposal
- Original Message - From: Simon Pieters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 31, 2006 11:20 AM Subject: [whatwg] Scoped tabindex proposal Hi, Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. It is better to use another attribute for that, say - tabgroup. It should accept exactly the same set of values as tabindex. input tabindex=1 / foo tabgroup=2 input tabindex=1 / input tabindex=2 / /foo input tabindex=3 / The order of tab traversal of inputs will be in this case as their natural order (in this case). tabgroup marked element may or may not have tabindex defined - so it can be focusable by itself. If both tabgroup and tabindex are defined and have numeric values then tabindex value is used as an index. So it will be possible to say: foo tabindex=2 tabgroup Andrew Fedoniouk. http://terrainformatica.com
