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

Make Attr inherit from Node again #299

Merged
merged 5 commits into from Aug 19, 2016
Merged

Make Attr inherit from Node again #299

merged 5 commits into from Aug 19, 2016

Conversation

annevk
Copy link
Member

@annevk annevk commented Aug 16, 2016

Unfortunately AttrExodus never quite became the success we all wished
it would be and the benefits with Attr no longer taking children (yay)
are rather marginal anyway.

The biggest change is to the compareDocumentPosition() algorithm. Other
noteworthy changes are that all attribute creation now needs to set a
node document.

Fixes #102.

@annevk
Copy link
Member Author

annevk commented Aug 16, 2016

I think one big thing that is not yet considered here is what should happen with certain existing APIs, such as mutation observers' observe(). Should that throw a TypeError if node is an attribute?

Are there other such APIs we need to consider?

@cdumez @foolip @smaug---- @Ms2ger @nox review appreciated.

@Ms2ger
Copy link
Member

Ms2ger commented Aug 16, 2016

All APIs that take Node should throw when passed an Attr, IMO. Don't care much about which exception; some may historically have been defined as throwing InvalidNodeTypeError or HierarchyRequestError or something.

@annevk
Copy link
Member Author

annevk commented Aug 17, 2016

Most APIs will already throw HierarchyRequestError indeed. observe() doesn't seem to throw in implementations, but doesn't do anything either since we only ever queue attribute mutation records for elements. @smaug---- @dominiccooney @travisleithead @cdumez should we make observe() throw when passed an Attr node or just let it be useless as it is today?

@annevk
Copy link
Member Author

annevk commented Aug 17, 2016

More concretely, given that the current patch matches implementations, I recommend we go with this (ideally with review though) and do any "normative changes" in a follow up.

@smaug----
Copy link
Collaborator

I guess not throwing is good here. We don't throw when one tries to observe attribute changes using document and subtree: false either, or we don't throw observing childList changes when target is a textnode etc. So there are already many possibly ways to observe something which will never happen.

@@ -1490,7 +1490,7 @@ can be used to explore this matter in more detail.

<h3 id=node-trees>Node tree</h3>

<p>{{Document}}, {{DocumentType}}, {{DocumentFragment}}, {{Element}}, {{Text}},
<p>{{Document}}, {{DocumentType}}, {{DocumentFragment}}, {{Element}}, {{Attr}}, {{Text}},
Copy link
Member

Choose a reason for hiding this comment

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

Attr doesn't actually participate in any tree though, it can't be appended to anything nor have any children.

Copy link
Member Author

Choose a reason for hiding this comment

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

For the purposes of event dispatch it needs to say it does. I guess I should add a note.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, maybe it doesn't.

@annevk
Copy link
Member Author

annevk commented Aug 18, 2016

Anything else?

@@ -3827,6 +3819,10 @@ the empty string instead, and then do as described below, switching on <a>contex
<li><p><a>Replace all</a> with <var>node</var> within the <a>context object</a>.
</ol>

<dt>{{Attr}}
<dd>
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 extra <dd> intentional?

Unfortunately AttrExodus never quite became the success we all wished
it would be and the benefits with Attr no longer taking children (yay)
are rather marginal anyway.

The biggest change is to the compareDocumentPosition() algorithm. Other
noteworthy changes are that all attribute creation now needs to set a
node document.

Fixes #102.
@@ -4175,57 +4157,80 @@ returns as mask:
<li><dfn const for=Node>DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC</dfn> (32, 20 in hexadecimal).
</ul>

The <dfn method for=Node>compareDocumentPosition(<var>other</var>)</dfn>
method must run these steps:
<p>The <dfn method for=Node><code>compareDocumentPosition(<var>other</var>)</code></dfn> method,
Copy link
Member

Choose a reason for hiding this comment

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

Here or later, wrap contains(other) below in <code> as well so that it's also orange?

Copy link
Member Author

Choose a reason for hiding this comment

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

@foolip
Copy link
Member

foolip commented Aug 18, 2016

Wow, compareDocumentPosition is so weird. @cdumez, care to review those bits for sanity?

In Blink (and WebKit still I presume), if both nodes attributes attached to different elements, things behave as if the attribute nodes are children of their elements, where attributes are considered to be before the real child nodes:
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4402

<li>Otherwise, <a lt="change an attribute">change</a> the
<a>context object</a> from <a>context object</a>'s
<a for=Attr>element</a> to the given value.
<li>Otherwise, <a lt="change an attribute">change</a> <var>attribute</var> from
Copy link
Member

Choose a reason for hiding this comment

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

Internal dialog: "What does it mean to change the value from an element to something, the value wasn't an element to begin with?!"

This wasn't new in this PR, but maybe "To change an attribute attribute of an element element to value, run these steps" would result in more natural language at the call site?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't like the call site stating the types. And "an" makes it even worse I think since these are very specific instances. Perhaps at some point we can change the way this is done, or adopt the abstract operation syntax from ECMAScript (I think I'd favor that).

@foolip
Copy link
Member

foolip commented Aug 18, 2016

OK, I've gotten through all of the changes now, great job I must say 👍

Some follow-up will probably be needed as weird things are discovered, but that's OK.

@@ -6697,23 +6715,19 @@ method, when invoked, must run these steps:

<pre class=idl>
[Exposed=Window]
interface Attr {
interface Attr : Node {
readonly attribute DOMString? namespaceURI;
Copy link

Choose a reason for hiding this comment

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

So this stays on Attr instead of going to Node?

@cdumez
Copy link

cdumez commented Aug 19, 2016

Nothing from me. Looks good.

@annevk annevk merged commit 625a074 into master Aug 19, 2016
@annevk annevk deleted the attr-odyssey branch August 19, 2016 12:44
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.

None yet

5 participants