Re: [WF2] new attributes that often conflict with actual pages

Hallvord R. M. Steen schreef:
> Hi,
> I've seen these new attributes cause problems for real-life websites. 
> I think we shold discuss re-naming them to make conflicts with 
> existing content less likely:

Just for the sake of clarity: are you talking about XML attributes or 
DOM properties here?

> INPUT action
>  - breaks web applications frequently. Both GMail and Yahoo mail (the 
> new Oddpost-based version) use input/button.action and were seriously 
> broken by WF2's action attribute.
> I propose renaming it "actionurl".

And still there are people who claim that namespaces and XHTML are 
useless :).

> SELECT data
> FORM data
>
> These break
> a) scripts that set them, read them back and are confused because they 
> turned into resolved URLs

I think changing XML attribute values when they’re set is very bad 
practice (and impossible to implement properly in a standard DOM). It 
might in some instances be necessary for ‘compatibility with the web’ 
(aka IE), but IMO should be avoided otherwise.

I still remember that at some point Opera used to resolve all src and 
href attributes (on <link>, <a>, <script> elements, etc.). That was one 
of the Opera compatibility issues our product had back then (Backbase), 
because it was not really possible to retrieve the original values.

Only the DOM properties corresponding to the attributes should resolve 
the URLs.

I looked at the specification, and I could not find where it specifies 
that the data attribute values have to be replaced with their resolved 
versions. If someone could point me there, I would appreciate that, and 
I would like this to be changed. Otherwise, it seems that the browser 
that you tested (which?) is wrong and should correct its behaviour.

However, I did see that the DOM ‘data’ property does not explicitly 
state that it should be a resolved absolute value [1]. I think this 
should happen, similar to similar DOM properties such as a 
HTMLFormElement.action [2] (note: does not explicitly state it either, 
but browser do implement it this way), HTMLAnchorElement.href [3] (does 
explicitly state it must return an absolute uri), etc..

Can I get an acknowledgement that these comments are noted by the editor?

> b) scripts that define global functions called data and try to call 
> them with a SELECT or FORM element in scope (for example from event 
> handlers)
>
> I propose renaming it "dataurl"

But all in all, I’d say that the cases you are citing contain very 
sloppy code, and deserve to break. It seems obvious that adding such 
obvious custom attributes without prepending a prefix of some kind is a 
compatibility problem just waiting to happen. I am not in favour of 
renaming these attributes and properties for the sake of those sites.


~Grauw

[1] http://www.whatwg.org/specs/web-forms/current-work/#data1
[2] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-74049184
[3] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-88517319

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.