On Tue, 28 Aug 2012, Boris Zbarsky wrote:
On 8/28/12 12:46 AM, Ian Hickson wrote:
I've updated the spec to not block on style sheets for nested parser's
scripts.
I'm not sure I follow. What is not going to block on what with this change?
As far as I can tell, 0 1 2 in your testcase at
Someone earlier in the thread mentioned that this feature sounds an awful lot
like rel=noreferrer, which has been in WebKit for several years:
http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/
It is also mentioned in the official link relation registry:
I overlooked that it's also in the spec itself, not just the registry:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer
Regards,
Maciej
On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak m...@apple.com wrote:
Someone earlier in the thread mentioned
James pointed out to me that the proposal explains the difference to
noreferrer, which is essential that it *does* send a referrer, but has the
rel=noreferrer behavior of nulling out window.opener.
I'm still not clear on the use case for nulling the opener but still sending
the Referer
On Mon, Aug 27, 2012 at 11:43 PM, Maciej Stachowiak m...@apple.com wrote:
James pointed out to me that the proposal explains the difference to
noreferrer, which is essential that it *does* send a referrer, but has the
rel=noreferrer behavior of nulling out window.opener.
I'm still not clear
On Tue, Aug 28, 2012 at 11:18 AM, Charlie Reis cr...@chromium.org wrote:
There are two main differences from the rel=noreferrer feature. First (as
you note), this does still send the referrer. That's useful for sites that
don't want to be affected by the newly opened page but that still rely
On 8/28/12 2:12 AM, Ian Hickson wrote:
On Tue, 28 Aug 2012, Boris Zbarsky wrote:
As far as I can tell, 0 1 2 in your testcase at
http://damowmow.com/playground/demos/document-write-and-scripts/002.html is
consistent with the following order of execution:
1) x=0
2) x1=0,x=1 (nothing else has
On Tue, 28 Aug 2012, Boris Zbarsky wrote:
Ah, I see. So is what you're proposing that stylesheets that are
inserted by a nested tokenizer not block scripts in general, but
stylesheets that are inserted by a top-level tokenizer block scripts as
usual?
Or is what you're proposing that
On 8/28/12 1:27 PM, Ian Hickson wrote:
The latter. The blocking only affects scripts that are prepare the
scripted by the top-level parser, not a reentrant parser.
OK. I see.
This requires the blocked by state to live on an individual script
instead of on the document, right?
I _think_
On 8/28/12 1:51 PM, Ian Hickson wrote:
I beg of you, let's not make it any more complicated. :-)
Amen. Just trying to catch up on what the state of things is now... ;)
-Boris
Both Gecko and WebKit support script crossorigin and allow it to
affect whether window.onerror reports are sanitized for cross-site
scripts. This allows window.onerror to apply usefully to scripts from a
CDN.
There was mention of this on this list a while ago, but the spec still
doesn't say
On Tue, Aug 28, 2012 at 11:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I just added support for link rel=stylesheet crossorigin in Gecko.[1]
Such links are subject to CORS checks if the load is cross-site, and the
sheet load will fail if the CORS check fails. If the CORS check succeeds,
I just added support for link rel=stylesheet crossorigin in
Gecko.[1] Such links are subject to CORS checks if the load is
cross-site, and the sheet load will fail if the CORS check fails. If
the CORS check succeeds, script in the page will be able to script the
cross-site stylesheet.
This
On 8/28/12 2:04 PM, Boris Zbarsky wrote:
An open issue: what to do about @import? I haven't done anything magic
here yet. Inheriting the CORS mode from the importing sheet is a bit
weird
Maybe I should explain weird.
If the CORS mode is inherited from the importing sheet, then I think the
On Aug 27, 2012, at 5:02 PM, Ian Hickson i...@hixie.ch wrote:
With JavaScript, it's certainly possible for a page author to play() or
pause() a slaved media element directly, but that author could just as
easily remove the media element from the media group / media controller.
[...]
On Thu, 7 Jun 2012, Brian Blakely wrote:
On Wed, Jun 6, 2012 at 7:49 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 27 Jan 2012, Brian Blakely wrote:
This proposal deals chiefly with standardizing the messaging around
that. The developer sets up the application to be ready for offline
On Fri, 8 Jun 2012, Silvia Pfeiffer wrote:
On Fri, Jun 8, 2012 at 6:10 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 7 Jun 2012, Silvia Pfeiffer wrote:
Can you give some examples of real-world pages where the tabindex
attribute has been used (with difficulty due to the lack of
On Fri, 8 Jun 2012, Mark Callow wrote:
On 08/06/2012 06:09, Ian Hickson wrote:
The dire warning doesn't work. I'm just saying that's the direction
that operating system vendors have been going in; that disallowing it
in the browser case is not a different direction, it's consistent with
On Sun, 10 Jun 2012, Steve Faulkner wrote:
I've used role and/or redundant ARIA within the scripting
environment to minimize calls in applications checking for roles.
Redundancy doesn't harm anything, I actively promote it, as it does
help, sometimes.
I disagree with that
On Sun, 10 Jun 2012, Scott Jehl wrote:
CSS referenced by link elements or @import has always come with the
limitation that it will block page rendering until it has finished
loading.
Not always, actually. In theory, it's not necessary. Originally, the
blocking was added to avoid flashes
Date: Tue, 28 Aug 2012 21:41:02 +
From: i...@hixie.ch
To: callow_m...@hicorp.co.jp
CC: wha...@whatwg.org
Subject: Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Fri, 8 Jun 2012, Mark Callow wrote:
On 08/06/2012 06:09, Ian Hickson wrote:
The dire warning
21 matches
Mail list logo
