Selectmenu: Copy element title and accesskey attributes#1298
Conversation
|
This forum thread was about the title attribute on |
|
Oh, did I misunderstand what we want here? So, adding title for option, not for select? Or do we want both? |
|
I think the discussion was about copying the title attribute on options, but I think it makes sense for both. |
|
OK, I will update this PR. |
There was a problem hiding this comment.
I'm really not sure what you're trying to test here.
There was a problem hiding this comment.
Ah, got to the implementation. Now I see why you added this.
There was a problem hiding this comment.
Is this about title, accesskey or both?
Wanted to check if the origin state of the select is restored.
There was a problem hiding this comment.
TJ removed the accesskey atrribute in his fiddle so its not duplicated. After some research this seemed needed to me, too.
There was a problem hiding this comment.
Let's add a comment about why we're checking this.
|
Yes, we want |
|
I've added title copying for options. |
There was a problem hiding this comment.
No space before the function.
|
With the updates this looks good to me. |
There was a problem hiding this comment.
Use a single .attr() call.
|
Fixed code style issues. |
|
You added support for |
|
Ignore that last comment, the diff was just confusing because it showed the |
|
It seems accesskey for options is not fully supported in all browsers but anyway, it seems like a valid requirement. I've added support for it, let me know what you guys think... Using accesskeys on list items works (at least) in FF. Do we want to write specific test for accesskeys? Seems like a good idea as we need to make sure that the the select is updated when using accesskeys triggering our list items. Unfortunately we would need to test this for each browser separately. Or is there a helper for accesskey usage? |
|
This looks good. As far as testing |
|
Ok. I've tested some browser, can you test what's missing? I've tested on Windows 8.1, IEs (except IE11) in VM. Tested accesskey for select and for option. Latest Firefox: ok |
|
OS X:
|
|
I've tested the behavior for FF and Chrome on Win8 again:
Note: native selects do not open the menu when activated |
|
When neither copying nor removing the accesskey attributes: Firefox: accesskey does not work on select or option (option does not work natively anyway) Conclusion: At least on Win none of these browsers follows accesskeys on hidden selects and its options. Seems save to not remove the accesskey attributes. |
|
Can somebody give me a hint why the travis built failed? |
|
For reference here's the error: “Testing tests/unit/core/core.html Fatal error: spawn ENOMEM�” I'm not sure what's up. |
|
ENOMEM should be a Travis problem, not our problem. |
That's not what I'm seeing with http://jsbin.com/retuxotidero/2/edit If I click the toggle button to hide the select, I can still change which option is selected via accesskey (verified by clicking the toggle button again to show the select). |
|
I'm not thrilled about having accesskey on options cause the original select and custom select get out of sync, but since this isn't something that works cross-browser natively, I think I'm ok with this. We should, however, lobby to get both of these working everywhere (accesskey on options and accesskey on elements that aren't natively focusable). |
|
You're right, I've missed hat behavior. Note its not the case in FF. Seems like a keenly idea but yes, we really should :-) |
|
Marking as 1.12 since this is a behavior change that users may not be expecting. |
There was a problem hiding this comment.
Is this really necessary with the domEqual() check?
There was a problem hiding this comment.
Good question. I've stolen this from the autocomplete test suite.
There was a problem hiding this comment.
Where? I don't see any references to title in autocomplete.
There was a problem hiding this comment.
Anyway, there's nothing to restore because we don't modify the original element at all. I think this whole test change can be removed.
There was a problem hiding this comment.
Sorry, I think I misunderstood your intention.
Yes, seems unneeded and a more or less a leftover from the accesskey copying. Removed.
|
@fnagel Can you update this to handle the new menu item wrappers? |
Fixes #10435
fe629a2 to
9326871
Compare
|
I've squashed the commits and rebased onto master. |
Changes for #10435
Question: what about attributes for list items?