Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, Oct 5, 2012 at 8:00 AM, Ian Hickson i...@hixie.ch wrote: This is specced. The UA is allowed to send the HTTP request (that's a truism, of course, nothing stops the UA from sending any arbitrary HTTP request at any time), but there's no in-DOM visible effect of that request, because event loops don't process tasks for documents without active browsing contexts, so the tasks that the fetch algorithm generates never get executed. (A clever UA can notice this and delay (forever) the HTTP requests, since the fetch algorithm allows you to wait an arbitrary amount of time before doing the request.) Note that you can append such an img to a different document later (e.g. the one that executes the script) so fetching it is probably smart. -- http://annevankesteren.nl/
Re: [whatwg] Resource loading in browsing context-less Documents
On 10/5/12 4:23 AM, Anne van Kesteren wrote: Note that you can append such an img to a different document later (e.g. the one that executes the script) so fetching it is probably smart. It can also lead to privacy leaks and very upset web developers and performance problems... So it's not quite clear cut. ;) -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, Oct 5, 2012 at 8:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/5/12 4:23 AM, Anne van Kesteren wrote:
Note that you can append such an img to a different document later
(e.g. the one that executes the script) so fetching it is probably
smart.
It can also lead to privacy leaks and very upset web developers and
performance problems... So it's not quite clear cut. ;)
Agreed. There have been bugs at Google where pages with templates
containing urls like http://www.google.com/someImageBucket/{{ id
}}/.jpg have accidentally fired resource requests and knocked over
servers with the equivalent of a DDOS attack.
-Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, Oct 5, 2012 at 1:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Oct 5, 2012 at 8:00 AM, Ian Hickson i...@hixie.ch wrote:
This is specced. The UA is allowed to send the HTTP request (that's a
truism, of course, nothing stops the UA from sending any arbitrary HTTP
request at any time), but there's no in-DOM visible effect of that
request, because event loops don't process tasks for documents without
active browsing contexts, so the tasks that the fetch algorithm
generates never get executed. (A clever UA can notice this and delay
(forever) the HTTP requests, since the fetch algorithm allows you to
wait an arbitrary amount of time before doing the request.)
Note that you can append such an img to a different document later
(e.g. the one that executes the script) so fetching it is probably
smart.
I'm not sure I get this. Generally, what you describe (pre-fetching)
is the behavior you'll get if you do the standard thing of
var img = document.createElement('img');
img.src = '/some/url.jpg';
Why is it useful to go to trouble of doing
document.implementation.createHTMLDocument('foo').createElement('img')
and have that fetch? The opposite seems true to me. It seems useful
that there's a way to create elements which explicitly are inactive.
It creates a safe playground to assemble DOM without worrying about
intermediate states triggering externally visible effects.
--
http://annevankesteren.nl/
Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, Oct 5, 2012 at 7:42 PM, Rafael Weinstein rafa...@google.com wrote:
Why is it useful to go to trouble of doing
document.implementation.createHTMLDocument('foo').createElement('img')
and have that fetch? The opposite seems true to me. It seems useful
that there's a way to create elements which explicitly are inactive.
It creates a safe playground to assemble DOM without worrying about
intermediate states triggering externally visible effects.
Yeah sure, I'm not opposed to that. But that seems like a somewhat
bigger change, no? E.g. then you would also change a.click() be a
no-op I suppose? Or form.submit(). Not just img.src has side
effects.
--
http://annevankesteren.nl/
Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, 5 Oct 2012, Anne van Kesteren wrote:
On Fri, Oct 5, 2012 at 7:42 PM, Rafael Weinstein rafa...@google.com wrote:
Why is it useful to go to trouble of doing
document.implementation.createHTMLDocument('foo').createElement('img')
and have that fetch? The opposite seems true to me. It seems useful
that there's a way to create elements which explicitly are inactive.
It creates a safe playground to assemble DOM without worrying about
intermediate states triggering externally visible effects.
Yeah sure, I'm not opposed to that. But that seems like a somewhat
bigger change, no? E.g. then you would also change a.click() be a
no-op I suppose? Or form.submit(). Not just img.src has side effects.
The spec currently describes this as Rafael suggests (if the Document has
a browsing context, networking works, otherwise it doesn't).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Path object
On Wed, Oct 3, 2012 at 10:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/3/12 11:04 PM, Boris Zbarsky wrote: I decided it wasn't worth punishing our users further if no one else in the world cared about this. (I hope the other browser vendors' rationale isn't actually not caring about it.) Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. It's not pointless: it discourages people from doing things that increase the chances of their page breaking in the future, and makes it easier for developers to ensure their own code isn't doing it by accident. (Of course, it would be nice to do this in validators, but that's not very practical with static analysis.) -- Glenn Maynard
Re: [whatwg] Resource loading in browsing context-less Documents
On 10/5/12 4:09 PM, Anne van Kesteren wrote: Yeah sure, I'm not opposed to that. But that seems like a somewhat bigger change, no? E.g. then you would also change a.click() be a no-op I suppose? Or form.submit(). Are they not already? -Boris
Re: [whatwg] [canvas] Path object
On 10/5/12 4:59 PM, Glenn Maynard wrote: (I hope the other browser vendors' rationale isn't actually not caring about it.) Some of them simply care about backwards compat more than about getting rid of the global scope polluter. But some, as far as I can tell, really don't care at all. Like don't respond to any questions on the matter. But the upshot is the same. Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. It's not pointless: it discourages people from doing things that increase the chances of their page breaking in the future, and makes it easier for developers to ensure their own code isn't doing it by accident. Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. So here we are. -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, Oct 5, 2012 at 10:56 PM, Ian Hickson i...@hixie.ch wrote: The spec currently describes this as Rafael suggests (if the Document has a browsing context, networking works, otherwise it doesn't). http://www.whatwg.org/specs/web-apps/current-work/#update-the-image-data I cannot find out how either this or the fetching algorithm terminates for no browsing context. http://www.whatwg.org/specs/web-apps/current-work/#following-hyperlinks does not seem to cover the case where there is no browsing context. submit() does indeed seem clear about this. -- http://annevankesteren.nl/
Re: [whatwg] [canvas] Path object
On Fri, Oct 5, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. Is there really a nontrivial cost to a one-time warning, the first time a window attribute is resolved this way? (Warning once per ID would be nice, but warning once per page load serves the purpose.) It sounds like a single branch at most. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. I'm a web developer, and I get annoyed at not being told when I'm doing something obviously bad, so you'll have to pick which group to annoy: people who want to write reliable webpages, or those who don't. -- Glenn Maynard
Re: [whatwg] [canvas] Path object
Can you please move this discussion to another thread and discuss the Path object on this thread? Greetings, Dirk On Oct 5, 2012, at 2:56 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Oct 5, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. Is there really a nontrivial cost to a one-time warning, the first time a window attribute is resolved this way? (Warning once per ID would be nice, but warning once per page load serves the purpose.) It sounds like a single branch at most. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. I'm a web developer, and I get annoyed at not being told when I'm doing something obviously bad, so you'll have to pick which group to annoy: people who want to write reliable webpages, or those who don't. -- Glenn Maynard
Re: [whatwg] Features for responsive Web design
Some of the e-mails on this thread were cross-posted to multiple mailing lists. Please remember not to cross-post when posting to this list. On Wed, 5 Sep 2012, Fred Andrews wrote: I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available Browser vendors don't seem emenable to this design, unfortunately. (Without good reason; it turns out that the people who care about latency are more often the users than Web authors -- Web authors often do things that are unnecessarily slow.) - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. Inlining the style here doesn't help. You don't know how many pixels em means at the time of parsing. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary). Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Zooming in post-load is a rare case compared to the case of an image being sized differently, though. On Wed, 22 Aug 2012, John Mellor wrote: ... So for example 1280.jpg 4x means that this image is 4 times larger than the given intrinsic width of 320px. So sure, it would be suitable for display on a hypothetical 4x display at 320px width; but the browser also knows that it would be suitable for display on a 2x display at 640px width, a 1.5x display at 853px width, and a 1x display at 1280px width. This isn't accurate. A trivial example of it not being accurate is a 1000 device pixel image that consists of a horiontal double-headed arrow labeled Five Hundred CSS Pixels. That image is _only_ applicable in a 500 CSS pixel double-density environment. If you sed it in a 250 CSS pixel quad-density environment, it would be wrong. This example may miss the point. If an image is to be scaled to 500 CSS pixels then this can be specified independently of the image pixel dimensions. The browser may even decide to download a much smaller image that is labeled Five Hundred CSS Pixels and scale it to the require CSS pixel size for the benefit of low bandwidth devices. Having both features seems like a lot of complexity. It's not clear to me that it is needed in practice. The art direction use case can be entirely orthogonal. It should be handled with the w/h descriptors as currently specified. What I'm proposing would operate after any w/h descriptors have narrowed down the set of allowable images, and let the browser choose between the remaining images more intelligently in the case of flexible-size images, where currently the browser has no idea which to use. Could you give a real example of this kind of thing? I'd love to study what kinds of images we're talking about here. None of the examples people posted when we were designing srcset= were like this. Here's an example of a webpage with images that scale and for which the aspect ratio of the image frame changes fluidly to fit the window width: http://london.msn.co.uk/ That's an interesting page design, thanks. For this one you really want the image whose dot width is the _device_ CSS pixel width multiplied by the device density, assuming you don't care about zooming, but do care about resizing. If you care about zooming more than latency, you really just want the highest-res image. In practice you'd probably have a medium-size image for legacy cases, a low-size image for phones, and a high-size image for high-density big devices,
Re: [whatwg] Font Resize Event
This might also be useful for us here at Mozilla (and perhaps the folks at WebKit). The reason being, if the text-size-adjust property (currently -webkit-text-size-adjust and -moz-text-size-adjust... not sure if other browsers implement this) becomes a spec, we then have to deal with the case on mobile where fonts are sized by the user agent, rather than the styling information (i.e. the author). So, firing a text resize event here might make sense, if only to let the page know that the text is undergoing a (potential) change in font size. Out of curiosity, do you handle this case (i.e. the case on mobile where fonts could be inflated due to a user agent scaling algorithm, such as mozilla's font inflation) on the site you mentioned? What happens in iOS Safari, for example, when text in the div is resized unexpectedly due to the -webkit-text-size-adjust property not being specified? ~Scott ¯\_(ツ)_/¯ On Wed 26 Sep 2012 01:41:06 AM CDT, Hugh Guiney wrote: My use case: I have a div with overflow: hidden that contains slides as part of a JavaScript carousel. It has to be overflow: hidden because otherwise the unseen slides are visible/stretch the page. And because each slide is different, the containing div therefore needs to grow/shrink in height depending on the content currently being displayed. This is trivial enough to do, by changing the height to match its contents whenever a slide change occurs, or a resize or orientationchange event is fired, but currently if I increase or decrease the font size, the content can get cut off, or there will be a ton of extra white space, since the div height is out of sync with the height of its contents. This could be easily remedied with a fontresize (or textresize) event. Some existing efforts to fill in this functionality, going back to 2005, demonstrate the utility beyond just this use case: http://www.alistapart.com/articles/fontresizing/ http://www.tomdeater.com/jquery/onfontresize/ http://wellstyled.com/en/javascript-onfontresize-jquery-plugin/ http://dev.sencha.com/playpen/docs/output/Ext.EventManager.html#onTextResize https://bugzilla.mozilla.org/show_bug.cgi?id=303405 While it's true I could use one of the existing scripts I listed, to me they are all unusable as the change detections don't always occur when a Cmd-+/- is issued.
Re: [whatwg] Resource loading in browsing context-less Documents
On 10/5/12 6:04 PM, Glenn Maynard wrote: On Fri, Oct 5, 2012 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 10/5/12 4:09 PM, Anne van Kesteren wrote: Yeah sure, I'm not opposed to that. But that seems like a somewhat bigger change, no? E.g. then you would also change a.click() be a no-op I suppose? Or form.submit(). Are they not already? a.click() is definitely not a no-op when not in a document The question is what it is when a.ownerDocument has no defaultView. The not in a document case is a different issue. -Boris
Re: [whatwg] Features for responsive Web design
On Oct 5, 2012, at 6:09 PM, Ian Hickson i...@hixie.ch wrote: Some of the e-mails on this thread were cross-posted to multiple mailing lists. Please remember not to cross-post when posting to this list. On Wed, 5 Sep 2012, Fred Andrews wrote: I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available Browser vendors don't seem emenable to this design, unfortunately. (Without good reason; it turns out that the people who care about latency are more often the users than Web authors -- Web authors often do things that are unnecessarily slow.) - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. Inlining the style here doesn't help. You don't know how many pixels em means at the time of parsing. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary). Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Zooming in post-load is a rare case compared to the case of an image being sized differently, though. On Wed, 22 Aug 2012, John Mellor wrote: ... So for example 1280.jpg 4x means that this image is 4 times larger than the given intrinsic width of 320px. So sure, it would be suitable for display on a hypothetical 4x display at 320px width; but the browser also knows that it would be suitable for display on a 2x display at 640px width, a 1.5x display at 853px width, and a 1x display at 1280px width. This isn't accurate. A trivial example of it not being accurate is a 1000 device pixel image that consists of a horiontal double-headed arrow labeled Five Hundred CSS Pixels. That image is _only_ applicable in a 500 CSS pixel double-density environment. If you sed it in a 250 CSS pixel quad-density environment, it would be wrong. This example may miss the point. If an image is to be scaled to 500 CSS pixels then this can be specified independently of the image pixel dimensions. The browser may even decide to download a much smaller image that is labeled Five Hundred CSS Pixels and scale it to the require CSS pixel size for the benefit of low bandwidth devices. Having both features seems like a lot of complexity. It's not clear to me that it is needed in practice. The art direction use case can be entirely orthogonal. It should be handled with the w/h descriptors as currently specified. What I'm proposing would operate after any w/h descriptors have narrowed down the set of allowable images, and let the browser choose between the remaining images more intelligently in the case of flexible-size images, where currently the browser has no idea which to use. Could you give a real example of this kind of thing? I'd love to study what kinds of images we're talking about here. None of the examples people posted when we were designing srcset= were like this. Here's an example of a webpage with images that scale and for which the aspect ratio of the image frame changes fluidly to fit the window width: http://london.msn.co.uk/ That's an interesting page design, thanks. For this one you really want the image whose dot width is the _device_ CSS pixel width multiplied by the device density, assuming you don't care about zooming, but do care about resizing. If you care about zooming more than latency, you really just want the highest-res image. In practice you'd probably have a medium-size image for legacy cases, a low-size image for phones, and a
Re: [whatwg] Resource loading in browsing context-less Documents
On Fri, Oct 5, 2012 at 5:51 PM, Boris Zbarsky bzbar...@mit.edu wrote: The question is what it is when a.ownerDocument has no defaultView. The not in a document case is a different issue. (See my last post.) -- Glenn Maynard
