Skip to content
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

Value attribute contains "###[P0LYFlLLed]###" on IE 11 #63

Open
wattry opened this issue Sep 11, 2019 · 6 comments
Open

Value attribute contains "###[P0LYFlLLed]###" on IE 11 #63

wattry opened this issue Sep 11, 2019 · 6 comments
Assignees
Labels

Comments

@wattry
Copy link

wattry commented Sep 11, 2019

When I access the value attribute on the option I receive "###[P0LYFlLLed]###" inserted between my value. and my

My value strings contain commas which may be the reason this is being split and concatenated.

The data attribute 'data-originalvalue' is being set to the value, resulting in inconsistent behavior between IE and the rest of the browsers I support.

@mfranzke
Copy link
Owner

mfranzke commented Sep 11, 2019

@09wattry, thanks for your feedback.

This is actually (the solution for) a feature. It's mainly related to aspects reported via #36 and #39 (and in Microsoft EDGEs platform issues), that it doesn't work to "Search both the value and label, using substring matching; currently it searches both the value and label, but uses prefix matching".

As requested with #36 we wanted to even also enrich the experience within the "newest" IE versions (10 & 11) and EDGE browsers that provided basic support, but not the substring matching for users input. In this case the technical solution has been to manipulate the values in a way that the browser could actually handle that functionality as well, by including the users input at the beginning of the value after a substring matching to the original value, followed by a unique string for preventing any inconsistencies, followed by the original value itself, in this case for the sorting of the entries (this is mainly done in the updateIEOptions function around line 191 to 200 of the code).

So totally agreed, this actually leads to a different behavior for the developers on the value property of each option elements within the datalist element for IE & EDGE, but on the other hand provides a better UX for IE & EDGE users by a consistent behavior for the user.

I'll make further notes on this topic within the documentation/README.

@mfranzke mfranzke assigned wattry and mfranzke and unassigned wattry Sep 11, 2019
@mfranzke
Copy link
Owner

made some comments by the commits da604d8, f68cf3f, 8736ae9, f68cf3f (I feel like I'm a little chatty at this time of the day ... )

@mfranzke
Copy link
Owner

I'm currently thinking about whether it probably makes sense to at least change the value to the original value after the user leaves the input field, but I would need to think that through and check on it another time.

@wattry
Copy link
Author

wattry commented Sep 12, 2019

@mfranzke I've recreated a sample in jsfiddle only to see IE is not supported. Honestly, if we could rid ourselves of IE I'd be a happy man, but users.

You're 100% right the improvement in user experience outweighs the cost of getting the originalvalue attribute. That is the main reason I sought out this polyfill in the first place.

Interesting though above, personally I think if it is easily to implement and not a big performance hit.

@wattry
Copy link
Author

wattry commented Sep 12, 2019

Would it not be possible to just swap data-originalvalue and value when the user moves focus?

@mfranzke
Copy link
Owner

mfranzke commented Sep 12, 2019

Most likely yes, that should be possible. It would still be inconsistent if some script for whatever reason is trying to get those values while the user is focusing that field.

I once had some user implementing a script that was retrieving values on the fly via httprequest on users input - actually my first thought was that this is what datalist ifself is for, but he convinced me that especially on a huge amount of data and to at least reduce the options initially makes perfectly sense. On the other hand, he replaced all of the existing elements with the new ones anyhow, but still related to the delay out of request/response and the user focus within the field, there might be edge cases that result out of things like this or similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants