On Sat, 4 Feb 2012, Boris Zbarsky wrote:
On 2/3/12 11:15 PM, Ian Hickson wrote:
I agree with you that if the author is using HTTP styles on their
HTTPS page that an attacker could screw with the page. But my point is
that fixing that is easy: just move the styles to HTTPS. In the case
On Tue, Jan 17, 2012 at 6:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/17/12 7:49 AM, Henri Sivonen wrote:
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarskybzbar...@mit.edu wrote:
Preventing _all_ loads for a document based on
some declarative thing near the start of the document, on
On 2/6/12 5:37 AM, Henri Sivonen wrote:
FWIW, I'm completely unsympathetic to this use case and I think we
shouldn't put engineering effort into supporting this scenario.
That depends on timeframes.
As far as the user is concerned, it would be much better for the site to get
its act together
On Fri, Feb 3, 2012 at 10:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/3/12 11:15 PM, Ian Hickson wrote:
No, I agree with you that if the author is using HTTP styles on their
HTTPS page that an attacker could screw with the page. But my point is
that fixing that is easy: just move the
On Mon, 9 Jan 2012, Tantek �~Gelik wrote:
WebKit supports a 'beforeload' event [1] which is supported in shipping
Safari and Chrome[2] and apparently has (enabled) the real-world
use-cases of:
1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock
extension
Extensions are
On 2/3/12 3:07 PM, Ian Hickson wrote:
OK. I have no serious problem with a beforeprocess event that fires
before processing the response, esp. if processing is defined in a
page-visible way (so e.g. you could still compile a script in the
background before firing beforeprocess; you just
On Fri, 3 Feb 2012, Boris Zbarsky wrote:
On 2/3/12 3:07 PM, Ian Hickson wrote:
OK. I have no serious problem with a beforeprocess event that
fires before processing the response, esp. if processing is
defined in a page-visible way (so e.g. you could still compile a
script in the
On 2/3/12 3:38 PM, Ian Hickson wrote:
I also believe that we have proposed this for standardization in the
past, though it seems to have fallen through the cracks a bit...
I couldn't find any mention of it in the WHATWG archives or Bugzilla,
though I did find an e-mail from sicking saying he'd
On 2/3/12 11:15 PM, Ian Hickson wrote:
No, I agree with you that if the author is using HTTP styles on their
HTTPS page that an attacker could screw with the page. But my point is
that fixing that is easy: just move the styles to HTTPS. In the case of
scripts it's not that easy because the
Le 17 janv. 2012 à 19:37, Tab Atkins Jr. a écrit :
SPDY push allows the server to send down additional resources along
with the main resource, before the client actually requests them.
When you say additional resources. Is that from the same domain?
--
Karl Dubost - http://dev.opera.com/
Le 17 janv. 2012 à 19:51, Boris Zbarsky a écrit :
On 1/17/12 7:37 PM, Tab Atkins Jr. wrote:
SPDY push allows the server to send down additional resources along
with the main resource
[…]
Ah, ok. Yeah, there's obviously no way the client can prevent that, nor
should it try.
no way the
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Preventing _all_ loads for a document based on
some declarative thing near the start of the document, on the other hand,
should not be too bad.
A page-wide disable optimizations flag could easily be cargo-culted
into
On 1/17/12 7:49 AM, Henri Sivonen wrote:
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarskybzbar...@mit.edu wrote:
Preventing _all_ loads for a document based on
some declarative thing near the start of the document, on the other hand,
should not be too bad.
A page-wide disable optimizations
On Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/12/12 9:22 AM, Boris Zbarsky wrote:
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the
On 1/17/12 7:24 PM, James Robinson wrote:
Even this scheme doesn't work with a model like SPDY push or other
bundling techniques or with more aggressive preloading that initiates
loads before the main resource is loaded.
Er... you mean it initiates loads before it has any idea whether the
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/17/12 7:24 PM, James Robinson wrote:
Even this scheme doesn't work with a model like SPDY push or other
bundling techniques or with more aggressive preloading that initiates
loads before the main resource is loaded.
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/17/12 7:24 PM, James Robinson wrote:
Even this scheme doesn't work with a model like SPDY push or other
bundling techniques or with more aggressive preloading that initiates
loads before the main resource is loaded.
On 1/17/12 7:37 PM, Tab Atkins Jr. wrote:
SPDY push allows the server to send down additional resources along
with the main resource, before the client actually requests them.
(The server, ideally, should know what resources the main resource
links to.)
Ah, ok. Yeah, there's obviously no way
On 1/17/12 7:37 PM, James Robinson wrote:
The way that these sorts of schemes work is that the server knows that a
set of resources are needed in addition to the main resource and it
starts sending them down before the client has received/parsed the main
resource. The server serving foo.html
On 1/12/12 9:22 AM, Boris Zbarsky wrote:
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the HTML5 parsing algorithm means that now
the elements are parsed into the other
On 1/13/12 2:50 AM, Roman Rudenko wrote:
True. In its current form, beforeload is not very useful for partial processing.
What if we had 'beforedownload' event specifically for resource
fetching, and constructed stub elements to feed it as event.target
when load is readahead-induced?
That
On Wed, 11 Jan 2012 15:51:47 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/11/12 6:59 AM, Simon Pieters wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297
Might not be cross-browser yet (e.g. Opera seems to run the image's
onload handler), but should work per spec I
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the HTML5 parsing algorithm means that now
the elements are parsed into the other document, eh? That's actually
pretty
On Thu, Jan 12, 2012 at 6:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the HTML5 parsing algorithm means that now the
On 1/12/12 1:27 PM, Ojan Vafai wrote:
This only works for the initial page load, no?
Yes, but does mobify use the beforeload handler after the initial page
load? They're generating new content and document.writing it back into
the document, and that new content needs to perform loads, so I
On Jan 12 10:32, Boris Zbarsky wrote:
Yes, but does mobify use the beforeload handler after the initial page
load? They're generating new content and document.writing it back into
the document, and that new content needs to perform loads, so I would
think they aren't so much.
At the moment,
On 1/12/12 2:19 PM, Roman Rudenko wrote:
For example, @media-controlled mobile view of a page
originally designed for desktop will typically include all desktop
assets. beforeload can fix that, as desktop resource loads could be
cancelled or even replaced with mobile-specific ones without
On Thu, Jan 12, 2012 at 11:32 AM, Boris Zbarsky bzbar...@mit.edu wrote:
For example, @media-controlled mobile view of a page
originally designed for desktop will typically include all desktop
assets. beforeload can fix that, as desktop resource loads could be
cancelled or even replaced with
On 1/12/12 9:23 PM, Roman Rudenko wrote:
Blocking is possible under some circumstances. Webkit differentiates
between normal parser and speculative parser. Speculative parser is
launched only if normal parser is blocked on execution of a script.
So, one could use beforeload to block resources in
On Tue, 10 Jan 2012 07:34:19 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/10/12 1:02 AM, Boris Zbarsky wrote:
I'd like to understand the client-side transformation use-case better,
in particular. What is it really trying to do?
OK, I got more context on this. The goal of the
On 1/11/12 6:59 AM, Simon Pieters wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297
Might not be cross-browser yet (e.g. Opera seems to run the image's
onload handler), but should work per spec I think. Well, the load can't
be prevented if it's speculatively loaded it
On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote:
So in WebKit this event is only good for preventing _processing_ of the data
in the page (e.g. preventing the script from executing when the target is a
script) but not much use for preventing loads, even if some people seem to
think that
On 1/10/12 1:54 PM, Darin Adler wrote:
On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote:
So in WebKit this event is only good for preventing _processing_ of the data in the
page (e.g. preventing the script from executing when the target is ascript)
but not much use for preventing loads, even
On Jan 10, 2012, at 10:59 AM, Boris Zbarsky wrote:
On 1/10/12 1:54 PM, Darin Adler wrote:
On Jan 10, 2012, at 8:43 AM, Boris Zbarsky wrote:
So in WebKit this event is only good for preventing _processing_ of the
data in the page (e.g. preventing the script from executing when the target
On Mon, Jan 9, 2012 at 10:02 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/10/12 12:48 AM, Tantek Çelik wrote:
Should 'beforeload'/'afterload' be explicitly specified and added to
the web platform?
Outside of extensions, what are the use cases? Can they usefully labor
under restrictions
WebKit supports a 'beforeload' event [1] which is supported in
shipping Safari and Chrome[2]
and apparently has (enabled) the real-world use-cases of:
1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock
extension[2]
2. Clientside transformations, e.g. Mobify[3]
As might be
On 1/10/12 12:48 AM, Tantek Çelik wrote:
Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4]
It's more like one person in a Mozilla bug has suggested that it be
implemented, while others, myself included, are a bit skeptical.
The devil, of course, is in the
On 1/10/12 1:02 AM, Boris Zbarsky wrote:
I'd like to understand the client-side transformation use-case better,
in particular. What is it really trying to do?
OK, I got more context on this. The goal of the client-side
transformation case is effectively do something like what one can do
On Tue, Jan 10, 2012 at 7:48 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock
extension[2]
Extension use cases don't require an API exposed to Web content, though.
Furthermore, IE9 has a built content blocking rule engine and
39 matches
Mail list logo
