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

fixed namespaced attributes not updating #125

Conversation

AndyOGo
Copy link

@AndyOGo AndyOGo commented Apr 18, 2018

fixes #124

Using SVG sprites with <use xlink:href="" /> will not update the icon.

The reason is that getAttributeNS and setAttributeNS DOM APIs are inconsistent in it's arguments.
E.g.: lets say 'foo:bar' ('foo' being the namespace and 'bar' the local attribute name):

@AndyOGo
Copy link
Author

AndyOGo commented Apr 19, 2018

@patrick-steele-idem
May I asked you to look into this as soon as you have some free time?
I'm happy to get your feedback:)

@AutoSponge
Copy link
Collaborator

@AndyOGo is it possible to demonstrate this with a test (one that fails under current version but passes under proposed)?

I know @patrick-steele-idem changed jobs recently, so he may not have the time to look into this.

@AndyOGo
Copy link
Author

AndyOGo commented Apr 20, 2018

@AutoSponge
Thank you for your answer.

Well, the thing is that, I faced this issue in Firefox at a customer of mine for axa-ch-webhub-cloud/pattern-library#411.
Though we are using nanomorph at above project, I figured since they borrowed a few bits from morphdom, may the same issue exists here. And indeed morphdom's code is identical.

Here are the copies from my screencasts (but baked by nanomorph):

Latest Chrome:
incremental-icon-chrome

Latest Firefox:
incremental-icon-firefox-stops

May I ask, aren't the links I provided form the official specs making the point clear enough?
For me it's obvious that the official API specification is inconsistent and there is the real bug, but I can't change that. We could only change the used API calls 😊

And I supplied the same Bugfix to nanomorph

@AndyOGo
Copy link
Author

AndyOGo commented Apr 20, 2018

PS. The reason this works in Chrome, is that SVG 2 drop <use>'s xlink:href in favour of href...

@AndyOGo
Copy link
Author

AndyOGo commented Apr 20, 2018

PPS: I also updated the related MDN article here:
https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttributeNS

Copy link
Collaborator

@AutoSponge AutoSponge left a comment

Choose a reason for hiding this comment

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

This PR needs a test which can be run cross-browser to ensure it will not fail existing functionality. Fixing firefox but breaking IE is not an option.

This also serves to explain to other developers what's expected for a given mutation.

@@ -16,9 +16,15 @@ export default function morphAttrs(fromNode, toNode) {
attrValue = attr.value;

if (attrNamespaceURI) {
attrName = attr.localName || attrName;
Copy link
Collaborator

Choose a reason for hiding this comment

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

We use || attrName because IE doesn't seem to support .localName see

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for your feedback, very appreciated.
About which version of IE are we speaking? (IE9 supports localName, see).
Microsoft officially stopped to support old IE versions until version 11

My point is that the setAttributeNS API is called with the wrong argument and I provided the official W3C specifications. May I ask you to study them yourself, look up all the technical definitions in the official DOM API glossary and then decide for yourself if I'm right or wrong.

// ref: https://www.w3.org/TR/DOM-Level-2-Core/glossary.html#dt-localname
// ref: https://dom.spec.whatwg.org/#dom-element-setattributens
// ref: https://www.w3.org/TR/DOM-Level-2-Core/glossary.html#dt-qualifiedname
fromValue = fromNode.getAttributeNS(attrNamespaceURI, attrLocalName || attrName);
Copy link
Author

Choose a reason for hiding this comment

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

@AutoSponge
I just inlined the attrName fallback just for getAttributeNS.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@AndyOGo are you saying these two blocks are different?

current

attrName = attr.localName || attrName;
fromValue = fromNode.getAttributeNS(attrNamespaceURI, attrName);

this PR

var attrLocalName = attr.localName;
fromValue = fromNode.getAttributeNS(attrNamespaceURI, attrLocalName || attrName);

Because I'm not seeing it. I'm still confused as to exactly what you think this fixes.

Copy link
Author

@AndyOGo AndyOGo Apr 20, 2018

Choose a reason for hiding this comment

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

No with my last commit I restored the original getAttributeNS function call with a fallback to attrName if attr.localName is not defined.

But the line below using setAttributeNS has changed to never use attr.localName.

// ref: https://www.w3.org/TR/DOM-Level-2-Core/glossary.html#dt-localname
// ref: https://dom.spec.whatwg.org/#dom-element-setattributens
// ref: https://www.w3.org/TR/DOM-Level-2-Core/glossary.html#dt-qualifiedname
fromValue = fromNode.getAttributeNS(attrNamespaceURI, attrLocalName || attrName);
if (fromValue !== attrValue) {
fromNode.setAttributeNS(attrNamespaceURI, attrName, attrValue);
Copy link
Author

Choose a reason for hiding this comment

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

@AutoSponge
Since I don't overwrite attrName with attr.localName || attrName anymore, setAttributeNS will always only use the full qualified attribute name, including it's namespace.

if (fromValue !== attrValue) {
// but setAttributeNS requires the fully qualified name
Copy link
Author

Choose a reason for hiding this comment

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

I also moved my complementary comments to the related API calls

@AndyOGo
Copy link
Author

AndyOGo commented Apr 23, 2018

@AutoSponge
I really want to suggest you read and understand the execution flow of morphAttrs function at runtime. My contribution is definitely NOT a noop.

Before the local variable attrName was conditionally overwritten.
By my contribution this variable is never overwritten, causing proper argument passing to setAttributeNS below.

And please stop trolling and giving me bad reputation, I develop frontend projects since decades, have studied all ECMA script specs starting with version 1 fully by myself.

@AutoSponge
Copy link
Collaborator

xlink:href is deprecated: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/xlink:href

Do not use. Without a test case to demonstrate how this affects morphdom, I'm keeping it closed. I've already blocked you but I will report if you continue this harassment and waste of my time.

@AndyOGo
Copy link
Author

AndyOGo commented Apr 23, 2018

Agreed xlink:href is deprecated and I understand this point.

I'm sorry if you interpret my comments as harassment, they don't meant to be.

My main idea is to help and to suggest an spec-conformant implementation regarding the usage of setAttributeNS. From my viewpoint it's really a general and very detailed bug in morphdom. So I made also sure to provide all official documentation regarding this issue.

Unfortunately cooperation with you is not a perfect match and therefore I can't help morphdom getting better.

Repository owner deleted a comment from LucaMele Apr 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Namespaced attributes do not update
2 participants