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
goog.dom.dataset.set does not work on IE11 sometimes #396
Comments
@liolick Interesting. I can confirm this is happening on IE11 (but not, for example, Chrome). I'd like to get a better understanding of the IE11 bug before patching Closure. Stepping through your example in a debugger, the dataset API is always being used—it's just not propagating to the CSS for some reason. A quick web search didn't turn up an existing IE bug. Could you dig around some more? |
I'm just find some links (not sure if they are usefull): |
This is an interesting problem. Assuming we force a repaint by toggling a unique generated CSS class on the element, we can work around the issue, but that may have an unwanted performance impact in applications that make heavy use of datasets. We will have to test the speed of doing that. I think there are 3 solutions we can consider: 1: Check for IE via User Agent and toggle a class 2. Use a independent define and toggle a class 3. Add a documentation warning, do nothing and have users implement their own fix. |
After some investigation, toggling an unrelated unique class does not cause IE to propagate the 4: Restrict IE to This returns functional behavior to IE. The performance hit is relatively minor and can be avoided if desired by overriding the define during compilation. In my opinion, those users seeking the highest possible performance will/should opt for using other non-DOM-based data storage anyway. |
In IE (up to and including IE 11), setting `element.dataset` in JS does not propagate the values to CSS. This breaks CSS expressions such as `content: attr(data-content)` that would otherwise work. Ensure that IE uses the `element.setAttribute` code path instead. Provide a define (`ALWAYS_USE_DOM_STRING_MAP`) to override this behavior and always allow. Closes google#396.
In IE (up to and including IE 11), setting `element.dataset` in JS does not propagate the values to CSS. This breaks CSS expressions such as `content: attr(data-content)` that would otherwise work. Ensure that IE uses the `element.setAttribute` code path instead. Provide a define (`ALWAYS_USE_DOM_STRING_MAP`) to override this behavior and always allow. Closes google#396.
I work on the Internet Explorer team and noticed this behavior some time back; recently I seeded Stack Overflow with a question and answer to assist others running into this issue. We're aware of the issue and have a bug filed internally for tracking it. I'll add this Issue to that ticket as an indicator that this is impacting live sites. With regards to the work-around, I'd suggest avoiding |
@jonathansampson I was originally looking for a "current but not future" property in the hopes that the bug is fixed in IE by the time the property disappears. Do you have an expected relative timeline for the removal of |
On internal builds we have already removed support for |
In IE (up to and including IE 11), setting `element.dataset` in JS does not propagate the values to CSS. This breaks CSS expressions such as `content: attr(data-content)` that would otherwise work. Ensure that IE uses the `element.setAttribute` code path instead. Closes google#396.
Thanks @jonathansampson. We'll avoid using the |
IE11 has support of 'dataset' property on Element.
But sometimes it is not working properly, while old setAttribute works fine.
goog.dom.dataset.set uses 'dataset' attribute first, so it is also working bad.
The case is:
.inputHint:before
{
content: attr(data-content);
}
var testSpan = document.getElementById("spanTest");
test.testSpan['content'] = 'some val';
// test.testSpan['content'] = '';
Nothing changes in IE11 here.
Test: http://jsbin.com/pumejubowu
The text was updated successfully, but these errors were encountered: