Skip to content

Selectmenu: Copy element title and accesskey attributes #1298

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

fnagel
Copy link
Member

@fnagel fnagel commented Jul 31, 2014

Changes for #10435

Question: what about attributes for list items?

@jzaefferer
Copy link
Member

This forum thread was about the title attribute on <option> elements. Can you add that to this PR?

@fnagel
Copy link
Member Author

fnagel commented Jul 31, 2014

Oh, did I misunderstand what we want here? So, adding title for option, not for select? Or do we want both?

@jzaefferer
Copy link
Member

I think the discussion was about copying the title attribute on options, but I think it makes sense for both.

@fnagel
Copy link
Member Author

fnagel commented Jul 31, 2014

OK, I will update this PR.

.selectmenu( "destroy" );

equal( element.attr( "accesskey" ), "s", "element accesskey" );
equal( element.attr( "title" ), "A demo title.", "element title" );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not sure what you're trying to test here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, got to the implementation. Now I see why you added this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this about title, accesskey or both?

Wanted to check if the origin state of the select is restored.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TJ removed the accesskey atrribute in his fiddle so its not duplicated. After some research this seemed needed to me, too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a comment about why we're checking this.

@scottgonzalez
Copy link
Member

Yes, we want title for both.

@fnagel
Copy link
Member Author

fnagel commented Jul 31, 2014

I've added title copying for options.

.attr( "accesskey", "s" )
.attr( "title", "A demo title" );

element.find( "option" ).each( function( index ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No space before the function.

@tjvantoll
Copy link
Member

With the updates this looks good to me.


var element = $( "#speed" )
.attr( "accesskey", "s" )
.attr( "title", "A demo title." )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use a single .attr() call.

@fnagel
Copy link
Member Author

fnagel commented Jul 31, 2014

Fixed code style issues.

@scottgonzalez
Copy link
Member

You added support for accesskey on the options, but you didn't add any tests for it and you're using different behavior than you used for the select.

@scottgonzalez
Copy link
Member

Ignore that last comment, the diff was just confusing because it showed the _renderItem() definition above the accesskey code in _destroy(). But this does bring up the fact that we should support accesskey for options.

@fnagel
Copy link
Member Author

fnagel commented Jul 31, 2014

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?

@scottgonzalez
Copy link
Member

This looks good. As far as testing accesskey, I'd recommend just doing a manual test in each of the browsers (let's document that here and in the ticket; let me know if you want some help testing in all the browsers). Whenever we eventually switch to WebDriver testing, we can look into automated testing.

@fnagel
Copy link
Member Author

fnagel commented Jul 31, 2014

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
Latest Chrome: ok
IE11: works on select but wont open menu and selects current item when pressing again, on option it fails silently
IE10 (Win7): like IE11
IE9 (Win7): like IE11
IE8 (WinXP): like IE11

@scottgonzalez
Copy link
Member

OS X:

  • Firefox: Can activate the select, but not the option; same as native
  • Chrome: The select opens, but doesn't get focus so keyboard use is broken at that point. For the option, the menu doesn't open, but if you manually open it, the correct item is highlighted.
  • Safari: The select opens, but doesn't get focus so keyboard use is broken at that point. Option does nothing. Both work natively.
  • Opera: Nothing happens. No native support for options.

@fnagel
Copy link
Member Author

fnagel commented Aug 7, 2014

I've tested the behavior for FF and Chrome on Win8 again:

  • Firefox: Can activate the select (gets focus) and the option (doesn't get focus, no native support for options)
  • Chrome: Can activate the select (doesn't get focus) and the option (doesn't get focus, native support for options)

Note: native selects do not open the menu when activated

@fnagel
Copy link
Member Author

fnagel commented Aug 29, 2014

When neither copying nor removing the accesskey attributes:

Firefox: accesskey does not work on select or option (option does not work natively anyway)
Chrome: accesskey does not work on select or option
IE11: accesskey does not work on select or option (option does not work natively anyway)
IE10: like IE11
IE9: like IE11

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.

@fnagel
Copy link
Member Author

fnagel commented Aug 31, 2014

Can somebody give me a hint why the travis built failed?

@tjvantoll
Copy link
Member

For reference here's the error: “Testing tests/unit/core/core.html Fatal error: spawn ENOMEM�

I'm not sure what's up.

@scottgonzalez
Copy link
Member

ENOMEM should be a Travis problem, not our problem.

@scottgonzalez
Copy link
Member

Chrome: accesskey does not work on select or option

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).

@scottgonzalez
Copy link
Member

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).

@fnagel
Copy link
Member Author

fnagel commented Sep 3, 2014

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 :-)

@scottgonzalez
Copy link
Member

Marking as 1.12 since this is a behavior change that users may not be expecting.

@scottgonzalez scottgonzalez added this to the 1.12 milestone Sep 17, 2014
.selectmenu( "destroy" );

// Check if attribute is restored after removing it to avoid duplicate
equal( element.attr( "title" ), "A demo title.", "element title" );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really necessary with the domEqual() check?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I've stolen this from the autocomplete test suite.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where? I don't see any references to title in autocomplete.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I think I misunderstood your intention.

Yes, seems unneeded and a more or less a leftover from the accesskey copying. Removed.

@scottgonzalez
Copy link
Member

@fnagel Can you update this to handle the new menu item wrappers?

@fnagel fnagel force-pushed the selectmenu-copy-attributes branch from fe629a2 to 9326871 Compare November 4, 2014 00:24
@fnagel
Copy link
Member Author

fnagel commented Nov 4, 2014

I've squashed the commits and rebased onto master.

@fnagel fnagel closed this in 9793739 Nov 4, 2014
fnagel added a commit that referenced this pull request Nov 7, 2014
@fnagel fnagel deleted the selectmenu-copy-attributes branch August 25, 2015 15:42
@fnagel fnagel restored the selectmenu-copy-attributes branch August 25, 2015 15:42
@fnagel fnagel deleted the selectmenu-copy-attributes branch August 25, 2015 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants