Get Element Attribute: make it actually return the attribute value

[andreastt]

We should not coerce values of boolean attributes as this is the job for
getting an element’s property. The use case for this is wanting to get
"foo" from <input disabled="foo">.

The patch also addresses getting the attribute of web element's element.

[AutomatedTester]

I don't think just returning the value here is good because <input disabled> is just going to return "" where I really think that they want the result of hasAttribute. Since boolean attributes don't actually need values. Most best practises recommend that people do hasAttribute for booleans I would rather have that as the result.

[andreastt]

That’s what calling getAttribute on a DOM element is supposed to return. Having special WebDriver behaviour for this means you wouldn’t be able to return "incorrect" from <input disabled=incorrect>, and would deviate from DOM.

If you want to check if an element is disabled we should be encouraging the use of Get Element Property. The concept of coerced boolean attributes is what the browser needs to determine if the input attribute is valid or not, in order to set the element’s disabled property.

[AutomatedTester]

With Web Components there is no reflection between attributes and properties here so people will want to known if the attribute is disabled or not.

I am ok with conflating getAttribute and hasAttribute in this call.

[andreastt]

I’m not really sure what you’re proposing here. That Get Element Attribute duplicate the behaviour of Get Element Property specifically when interacting with form control elements? All elements?

I think my primary counterargument is that attributes is a DOM concept, and the DOM doesn’t say anything about disabledness/checkedness of HTML elements. I don’t think it’s a particularly good idea if we rocked this idea, despite that HTML reflects changes to the property to the DOM.

Since it’s HTML that defines the disabled concept, what users want also isn’t hasAttribute("disabeld"), although in the particular case of calling that on form control elements it would effectively give you the same result.

I think making the change I think you’re suggesting would lead to a situation where WebDriver has a special definition of what it means to be a content attribute, different to that of DOM and HTML. It would effectively mean that if users actually wanted the actual, correct value of the content attribute, they’d have to call Execute Script, asking for arguments[0].getAttribute("disabled"), which yet again proves why we shouldn’t overload the “attribute” concept. It’s hard enough to explain what Get Element Attribute does in Selenium WebDriver as it is.

I’d rather we keep the primitives close to existing web platform technologies instead of inventing our own behaviour and especially overload existing terminology. If local ends wish to implement a behaviour that diverges from the web platform, they are able to do so with the primitives we provide them with.

[jgraham]

Per my comment on the Wires bug, I don't actually see how to implement the currently specified behaviour without a list of boolean attributes in the implementation. That's because it isn't possible to tell whether a specific content attribute is actually a boolean attribute through DOM APIs.

[andreastt]

@AutomatedTester r?

[andreastt]

Rebased again.

[AutomatedTester]

I have spoke to @andreastt about this and think that this will be a good point to discuss at TPAC. Leaving open for now.

[AutomatedTester]

this was decided to remain as is