On Thu, Nov 21, 2013 at 10:48 AM, Anne van Kesteren wrote:
> At the moment Safari has the document.domain property defined with
> configurable set to false. ([Unforgeable] in IDL.) Should we adopt
> this in the specification or just leave things as is?
>
> It's been suggested some sites might rely
On Thu, Nov 21, 2013 at 10:48 AM, Anne van Kesteren wrote:
> (In other news, Object.getOwnPropertyDescriptor(document, "domain")
> does not work in Gecko or IE10...)
Please ignore this, it works with s/document/HTMLDocument.prototype/.
The bug is in WebKit/Blink for not having it defined on the p
At the moment Safari has the document.domain property defined with
configurable set to false. ([Unforgeable] in IDL.) Should we adopt
this in the specification or just leave things as is?
It's been suggested some sites might rely on document.domain being
trustworthy, though I don't have data for t
I'm resending this (slightly updated) message because the first didn't
appear to get delivered. Concerning responsive images, I will make the case
that:
* Art-direction & matching media features/types should not be part of a
responsive image solution.
* The benefits of a preload-scanner are overra
On Wed, 20 Nov 2013 22:27:52 +0100, Tab Atkins Jr.
wrote:
We don't need to actually limit the MQs which are allowed in
. The preloader is just an optimization in the first place;
we *want* the image to be preloaded, but if it isn't, the image will
still work, just slower. We can provide a n
On Thu, Nov 21, 2013 at 3:53 AM, Kornel Lesiński wrote:
>
> An element will be de-facto required for a while as a fallback, but
> could it be optional eventually? I think that even if browsers implement
> using , the element itself should be hidden in shadow
> DOM.
>
That would eliminate the n
