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 c
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 Tue, Jan 17, 2012 at 6:29 PM, Boris Zbarsky wrote:
> On 1/17/12 7:49 AM, Henri Sivonen wrote:
>>
>> On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky wrote:
>>>
>>> Preventing _all_ loads for a document based on
>>> some declarative thing near the start of the document, on the other hand,
>>> s
On Fri, Feb 3, 2012 at 10:47 PM, Boris Zbarsky 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 styles to
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 script
On Fri, 3 Feb 2012, Boris Zbarsky wrote:
> On 2/3/12 10:53 PM, Ian Hickson wrote:
> > Surely for the style sheets there's far less of a difficulty in
> > getting things right? I don't really understand what vulnerability
> > would be relevant here such that you'd need per-stylesheet control
> >
On 2/3/12 10:53 PM, Ian Hickson wrote:
Surely for the style sheets there's far less of a difficulty in getting
things right? I don't really understand what vulnerability would be
relevant here such that you'd need per-stylesheet control over what was
being imported.
Hmm. I sort of assume that
On Fri, 3 Feb 2012, Boris Zbarsky wrote:
> 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 Bu
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 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
> > >
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 co
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
Extensio
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
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.
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 can
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 t
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky 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.
>>
>
> Er
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky 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.
>
> Er... yo
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
main
On Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky 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 th
On 1/17/12 7:49 AM, Henri Sivonen wrote:
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky 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 easi
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky 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 something harmful
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 doc
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 still
On Thu, Jan 12, 2012 at 6:59 PM, Boris Zbarsky wrote:
> 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 executi
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 Thu, Jan 12, 2012 at 11:32 AM, Boris Zbarsky 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-spec
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 complet
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 momen
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 w
On Thu, Jan 12, 2012 at 6: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
> eleme
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 cute
On Wed, 11 Jan 2012 15:51:47 +0100, Boris Zbarsky 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 think. Well, the l
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 befor
On Tue, 10 Jan 2012 07:34:19 +0100, Boris Zbarsky 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 client-side
transformatio
On 1/10/12 3:40 PM, Adam Barth wrote:
Do they really need to block the load, or block processing of the response?
Just block processing the response.
OK. I have no serious problem with a "beforeprocess" event that fires
before processing the response, esp. if "processing" is defined in a
p
On Tue, Jan 10, 2012 at 12:15 PM, Boris Zbarsky wrote:
> On 1/10/12 2:49 PM, Adam Barth wrote:
>>
>> On Mon, Jan 9, 2012 at 10:02 PM, Boris Zbarsky wrote:
>>>
>>> On 1/10/12 12:48 AM, Tantek Çelik wrote:
Should 'beforeload'/'afterload' be explicitly specified and added to
the web p
On 1/10/12 2:49 PM, Adam Barth wrote:
On Mon, Jan 9, 2012 at 10:02 PM, Boris Zbarsky 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
On Mon, Jan 9, 2012 at 10:02 PM, Boris Zbarsky 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 like knowin
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
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 a
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
>
On Tue, Jan 10, 2012 at 7:48 AM, Tantek Çelik 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 Firefox
has a de facto
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
with
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 details;
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 expec
46 matches
Mail list logo
