Difference between revisions of "Oblivion XML Reference/Traits"
m
→Behavior: formatting fix
imported>DavidJCobb (revisions and reorganizations) |
imported>DavidJCobb m (→Behavior: formatting fix) |
||
| Line 141: | Line 141: | ||
:This trait has something to do with indicating whether a tile is a list container, a list item, or (by default) neither. Vanilla code comments wrongly describe this as a Boolean even when the values supplied are not Booleans (or numerically equivalent to Booleans under the hood). The trait should be set to &xlist; for a list’s immediate container and &xitem; for generated list items. | :This trait has something to do with indicating whether a tile is a list container, a list item, or (by default) neither. Vanilla code comments wrongly describe this as a Boolean even when the values supplied are not Booleans (or numerically equivalent to Booleans under the hood). The trait should be set to &xlist; for a list’s immediate container and &xitem; for generated list items. | ||
:This trait influences how keyboard navigation works: if a keyboard navigation trait is processed and “leads” to a tile whose ''xlist'' trait is set to &xlist;, then Oblivion will instead attempt to focus a list item inside of the tile. The precise operational definition of “list item” with respect to the previous sentence is not known at this time, but testing and disassembly indicate that “list items” work for this purpose if they have an ''xdefault'' trait (set to any value), are visible and ''target''able (a requirement for receiving keyboard focus), and if their xlist trait is set to &xitem;. The result of this functionality is that you can place keyboard navigation traits (e.g. ''xleft'' and ''xright'') on two list containers, with each container’s trait pointing at the other, to allow keyboard navigation between the two lists; Oblivion will remember which list item previously had focus in each list, and will return focus to that list item if the user navigates back to its containing list. | :This trait influences how keyboard navigation works: if a keyboard navigation trait is processed and “leads” to a tile whose ''xlist'' trait is set to &xlist;, then Oblivion will instead attempt to focus a list item inside of the tile. The precise operational definition of “list item” with respect to the previous sentence is not known at this time, but testing and disassembly indicate that “list items” work for this purpose if they have an ''xdefault'' trait (set to any value), are visible and ''target''able (a requirement for receiving keyboard focus), and if their xlist trait is set to &xitem;. The result of this functionality is that you can place keyboard navigation traits (e.g. ''xleft'' and ''xright'') on two list containers, with each container’s trait pointing at the other, to allow keyboard navigation between the two lists; Oblivion will remember which list item previously had focus in each list, and will return focus to that list item if the user navigates back to its containing list. | ||
:All of this is necessary because for a number of reasons, it is impossible to target generated list items by name for keyboard navigation. The biggest obstacle is that if the list items are not renamed after being generated from a template, then they will all have the same name; if they are renamed, they will be renamed to an executable-defined string that will likely vary based on the generated content (e.g. for an inventory item in the RepairMenu, a sanitized version of the item name with certain characters replaced). Aside from this, ''src'' attributes and selectors seem to only be processed at final parse time (templates are kept “half-parsed” and parsing finishes each time tiles are generated from them), so attempting to reference any generated list item from outside of its list will fail (because the list item does not exist at parse time). | |||
;xdown | ;xdown | ||
;xleft | ;xleft | ||