[Bug 27267] New: Removal of DOMAttr.ownerElement breaks XPath functionality

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27267

            Bug ID: 27267
           Summary: Removal of DOMAttr.ownerElement breaks XPath
                    functionality
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: DOM
          Assignee: annevk@annevk.nl
          Reporter: toms.seisums@gmail.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

Today I was greeted in my Chrome's console with this:

    'Attr.ownerElement' is deprecated and has been removed from DOM4
(http://w3.org/tr/dom).

Having quickly skimmed through the document, and finding out that "Attr"
interface no more has the property, I did a quick Google search, which resulted
in:

    http://stackoverflow.com/questions/24214188/attr-ownerelement-meaning

Specifically, this:

    "ownerElement" This property has been removed from Firefox 29. Since you
can only get Attr objects from elements, you should already know the owner.

But this is wrong, really wrong. What about XPath, which allows us to query for
nodes of specific type?

For instance, this query:

    descendant-or-self::*/attribute::*[starts-with(name(), "data-bind")]

Which does, something like "selects all attributes which names start with
"data-bind" (data-bind, data-bind-something, data-bind-other) that are defined
on either the context or any of the context node descendants". Emphasis on
"selects all attributes" - this returns a result set of "Attr" nodes.

For instance, I have a JS model -> element binder library. I run the query,
providing my element as the context and in return, I get all attributes that
are responsible for binding.
By iterating over each of them and getting their type ("data-bind" as value
binder and "data-bind-*" as attribute binder) and values, I can easily change
"innerHTML/nodeValue" or "setAttribute" on the boundable element by utilising
"Attr.ownerElement":

    if (attribute.name === 'data-bind')
    {
        attribute.ownerElement.innerHTML = providedModelData[attribute.value];
// Using the attributes' value as key here.
    }
    else
    {
        var targetAttributeName = attribute.name.replace('data-bind-', '');
        attribute.ownerElement.setAttribute(targetAttributeName,
providedModelData[attribute.value]); // Again, using key and remainder of
attributes value.
    }

XPath is the only option that allows us to query for attributes with wildcard
names. And the combination of XPath, Attr and ownerElement is a magical one.

Clearly, the claim "Since you can only get Attr objects from elements, you
should already know the owner." is wrong, at least in XPath context. Yes, with
document.querySelector we will only get Element nodes, but hey - we got other
querying possibilities!

Yes, I know that in my example, I can query for elements, that have the
matching attributes, but then I have to loop through all of the attributes and
filter them by names. Feels wrong, given that the current
XPath/Attr/ownerElement combo can help us handling such case.

Maybe I have overlooked something and XPath will return a different Attr
interface? Though, I highly doubt it.

To be honest, I'm really shocked.

I agree that separating Attr from Node is needed due to useless properties,
but, please, oh please, leave the ownerElement intact.

P.S. A working example can be seen here:
http://jsfiddle.net/psycketom/0cucudgk/

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 7 November 2014 11:32:11 UTC