W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14531] Require that <img>s are updated when @crossorigin is changed

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Oct 2011 06:48:18 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RIao6-0003tL-Kp@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14531

--- Comment #2 from Jonas Sicking <jonas@sicking.cc> 2011-10-25 06:48:17 UTC ---
As a general rule the way a DOM behaves should depend on the current
configuration of the DOM. I.e. on the configuration of elements, children and
attributes. It should not matter how it got there. This is much more
understandable for people. This is especially the case for attribute setters
which people tend to think if as state setters, not function calls. Hence, it's
very surprising that the order of setting attributes matter.

We have very few diversions from this rule. Most of them involve <script>
elements where we simply can't undo actions when attributes or child lists are
changed. The *only* other case I can think of is changes to base URIs where
complexity was vey high and value very low to try to do otherwise (and I'd
expect that over time we'll end up adding a lot of that complexity).

Additionally, if the crossorigin attribute doesn't affect what image is
actually going to be attempted to be loaded that means we'll be carrying around
hidden state not exposed to script. In almost every situation where we do that
people end up wanting to get at that state. Which leads to more API for us, or
more complexity for them when they have to work around not having that state.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 25 October 2011 06:48:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:06 UTC