User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5 Steps to reproduce: Created a page that has <script crossorigin="anonymous" src="..."></script> in the markup. The page also dynamically creates a script element, sets its crossOrigin property to true, and inserts it into the document head. Actual results: Opened the Web Console to inspect the properties of the two script elements. The parser-inserted script's crossOrigin property was undefined, but getAttribute('crossorigin') returned "anonymous". The script-inserted script's crossOrigin property was true, but getAttribute('crossorigin') returned null and debugging tools like the built-in Inspector and Firebug did not show an empty crossorigin attribute in the markup. Expected results: The parser-inserted script's crossOrigin property should have been set to "anonymous". The script-inserted script should have the "crossorigin" content attribute set and visible to debugging tools.

My UA is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120402 Firefox/14.0a1"

There's actually just no crossOrigin IDL property at all. I didn't add one in bug 696301. You're right that we should add one.

Comment on attachment 612657 [details] [diff] [review] Add a .crossOrigin IDL property. that the content attribute is crossorigin (lowercase) in SVG, hence the need to have different Review of attachment 612657 [details] [diff] [review]: ----------------------------------------------------------------- We should use 'using' more to fix the hiding problem for setattr

Is this in a spec somewhere?

> We should use 'using' more to fix the hiding problem for setattr That leaves the question of which one to 'use'. I'm not sure I want to deal with that.... > Is this in a spec somewhere? Not yet. I did raise it on whatwg at some point, but not much response. WebKit did add an IDL property for at least HTML; dunno about SVG.

i think you can just say "using parentclass::SetAttr;" and you'll get them all.

Yes, but parentclass is different for all the subclasses, no? So I can't put that in the macro; I'd have to sprinkle it all over the tree. Still worth it?

I think it's something we should do, but it doesn't need to be done here. In fine with landing what you have.