Re: [whatwg] Script preloading
On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote: On browser preloading: There seems to an inherent conflict between 'indiscriminate' Pre-parsers/ PreloadScanner and responsive design for mobile. Responsive designs mostly implies that everything needed for a full screen desktop is provided in markup to all devices. The pre-loader is a tradeoff, it's aiming to increase network utilisation by speculatively downloading resources it can discover. Some of the resources downloaded may be not be used but with good design and mobile first approaches hopefully this number can be minimised. Even if some unused resources get downloaded how much it matter? By starting the downloads earlier, connections will be opened sooner, and the TCP congestion window to grow sooner. Of course this has to be balanced against visitors who might be paying to download those unused bytes, and whether the unused resources are blocking something on the critical path from being downloaded (believe some preloaders can re-prioritise resources if they need them before the preloader has downloaded them) Although we talk about *the preloader*, it's worth remembering different browsers (and versions) have different preloading approaches - compare the connection view charts (at bottom of page) for www.channel4.com in Chrome, Firefox and IE10 and you'll see subtle differences: Chrome http://www.webpagetest.org/result/130713_0J_PC1/1/details/ Firefox http://www.webpagetest.org/result/130713_P2_PBZ/1/details/ IE10 http://www.webpagetest.org/result/130713_9A_PBW/1/details/ Isn't the Pre-parsers/PreloadScanner's inability to take into account the display[none:yes] factor be a potential significant blow to 'mobile' performance. Use case: What if I have a set of images in an element set as display:none; only designated to be show on desktop or tablet screens and not on mobile phone? What if I have an inline script in that node? Isn't the PreloadScanner loading a lot more than I need, a problem here? Challenge with this approach is the browser has to build the render tree before it can decide whether to download a resource i.e. download HTML, parse it, build a DOM, download CSS, parse it, build CSSOM, then build render tree. In addition to the need to preload, with responsive design taken into consideration, and for lack of not being able to remove part of the body before the browser parses the document. I see an increasing potential need for the ability to indicate to the browser not to load selective assets before DOMReady and suppress such preload. The proposed lazyload attribute should help here https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html Yoav Weiss has raised the idea of being able to use media queries with scripts and other resources too. Responsive design is young, I think we still have a lot to learn and it's going to take a while before we really understand what features we need. Cheers Andy
Re: [whatwg] Script preloading
On 9 July 2013 20:39, Ian Hickson i...@hixie.ch wrote: A topic that regularly comes up is script loading. I sent an e-mail responding to related feedback last year, though it didn't get any replies to the script loading parts of it: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html Pretty sure the cases I mentioned are met by the proposed lazyload attribute
[whatwg] Safari, Opera and Navigation Timing API
Anyone know when Safari and Opera are likely to support the Navigation Timing API? http://www.w3.org/TR/navigation-timing/ Being able to measure actual page load times in the browser is really important if we want to improve the end-users' experience in the real world. Yes we can hack around the lack of Navigation Timing to get some basic information but it's no where near as good as the information that can be exposed directly by the browser. Cheers Andy
Re: [whatwg] input type=barcode?
On 27 August 2012 20:25, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@hixie.ch wrote: True, so this is perhaps closer to an IME hint, as has been suggested for a couple of other input types. Do you mean something like inputmode=barcode? Can you elaborate on how that would work? It's an intriguing idea, but I'm not sure I follow quite how to specify it. Yes, something like that. In terms of the table in the spec: Keyword: barcode State: Barcode Fallback State: Default Description: Text input in the user's locale, with keys to activate the system's built-in barcode reader to retrieve a value instead. When you say barcode I'm presuming you're referring to barcode in all it's forms e.g. barcode, QR code, datamatrix etc? Some of these can contain up to 4,000 characters but many imagers have problems reading them. BTW there's an interesting introduction to barcodes from Data Logic here: https://easeofaccess.scanning.datalogic.com/public/marketlit/Send.aspx?file=EB-THEARTOFTHECODE-EN Cheers Andy
Re: [whatwg] Features for responsive Web design
On 9 August 2012 17:01, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 9, 2012 at 1:16 AM, Andy Davies dajdav...@gmail.com wrote: Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS The image-set() function already includes this functionality. You can include a fallback color, and if the UA decides it doesn't want to download *any* of the images, it can just create a solid-color image and use that instead. Thanks I see it now - must have missed it when first scanned the CSS4-images spec Andy
Re: [whatwg] Features for responsive Web design
On 8 August 2012 17:44, Edward O'Connor eocon...@apple.com wrote: Hi Markus, You wrote: Anyway, with your proposal, would this be valid, to address the bandwidth-only use case?: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x You don't need the , normal.jpg 1x because src= has an implied 1x. The above could simply be done like so: img src=normal.jpg alt=appropriate alt text srcset=high.jpg 2x I know it's there for graceful degradation reasons but doesn't setting the 1x image via src and the others via srcset just add to developers confusion? Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS Cheers Andy
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
In Scott Jehl's latest example of a responsive image polyfill (https://github.com/scottjehl/picturefill), he produced a variation that allows a non-retinae image to be downloaded by default with the user having the ability to then choose the download the retina version of image if then wanted. Which ever solution to the responsive image eventually get's incorporated into the spec I think we need to account for this behaviour at the user-agent level i.e. if the UA decides to download a non-retina image because the user is on a cell network, then they need a way of easily choosing to download the retina image if they want. Any thoughts? Andy
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
Doesn't this section of the HTML spec already allow for what Scott wants: http://www.whatwg.org/specs/web-apps/current-work/#the-link-element For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available even if the resource is not applied. To obtain the resource, the user agent must run the following steps: If the href attribute's value is the empty string, then abort these steps. Resolve the URL given by the href attribute, relative to the element. If the previous step fails, then abort these steps. Fetch the resulting absolute URL. User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied. Looking at waterfalls for a page loading Android 2.3 and iOS 5, it appears that iOS does defer the non-applicable stylesheets - question is why don't more browsers? iOS 5 - http://www.blaze.io/mobile/result/?testid=120615_J6_927 Android 2.3 - http://www.blaze.io/mobile/result/?testid=120615_2D_929 Cheers Andy
[whatwg] Spec for downloading stylesheets
I'm under the impression that a UA has to download all stylesheets regardless of whether they will be used e.g. print, mediaquery may never match etc. I've had a crawl through the specs but can't find the behaviour specified. Is my understanding right and if so can someone point me at the relevant spec? Thanks Andy
Re: [whatwg] Spec for downloading stylesheets
Thanks Tab, I presume it's this - http://www.whatwg.org/specs/web-apps/current-work/#the-link-element For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available even if the resource is not applied. To obtain the resource, the user agent must run the following steps: If the href attribute's value is the empty string, then abort these steps. Resolve the URL given by the href attribute, relative to the element. If the previous step fails, then abort these steps. Fetch the resulting absolute URL. User agents may opt to only try to obtain such resources when they are needed, instead of pro-actively fetching all the external resources that are not applied. On 16 June 2012 15:46, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Jun 16, 2012 at 1:23 AM, Andy Davies dajdav...@gmail.com wrote: I'm under the impression that a UA has to download all stylesheets regardless of whether they will be used e.g. print, mediaquery may never match etc. I've had a crawl through the specs but can't find the behaviour specified. Is my understanding right and if so can someone point me at the relevant spec? The relevant spec is just HTML, which pays no attention to the @media attribute when parsing link rel=stylesheets. Without anything explicitly saying Don't download X unless condition Y is met, you just download them all. The reasoning for this is that the set of stylesheets that you need for a document is not static - users *do* resize their browser, for example, and browsers would like to apply the relevant CSS immediately, not wait a second or so to kick off and finish a download. It also lets us keep the invariant that, if you use matchMedia or something to see if a MQ matches, all the styles are correct for the state of the world as you see it. ~TJ
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 22 May 2012 10:43, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 22, 2012 at 10:21 AM, Markus Ernst derer...@gmx.ch wrote: I am somehow surprised that there are no reactions to this proposal. To me as a humble author it looks like it would address the main issue of both picture and @srcset, as it leaves the MQ to CSS, and thus separates design from content. 1. It does not address the pixel density use case. 2. A pattern-based approach was actually mentioned in Ian Hickson's email when he announced the srcset attribute. It doesn't address the art-direction use case either - http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ Andy
Re: [whatwg] Features for responsive Web design
On 18 May 2012 15:28, Glenn Maynard gl...@zewt.org wrote: Only if there are actual problems solved by doing so, which there don't seem to be. Instead, people seem to be hunting for excuses to use parts of the other proposal just for the sake of using them, not to solve any actual problem. (That's not a good reason to do it? Hold on, let me try to come up with another...) Perhaps but I think the real problem may be this... The other proposals have been knocked around by various parties who wanted to solve a problem, they had time to discuss it, digest it and see how it grew to meet their needs. Now srcset was dropped on them as a surprise, they're still trying to understand it, they keep being re-assured it meets their needs but no-one who developed the srcset proposal has really come out and explained to them how it meets their needs so they keep asking questions... I wasn't involved in the picture discussion so have no particular attachment to it, I think both picture and srcset have problems in that they move breakpoints into the markup, srcset's microsyntax is pretty horrible and the picture syntax has issues too. The thing that really astounds me about the responsive/adaptive images hullabaloo is: The responsive image problem has been discussed for at least a year with plenty of ideas / workarounds floated around (only got to look a slidedecks form Mobilism, Breaking Development etc. for this) yet WHATWG seemed pretty unaware of it. When WHATWG did decide to do something about it they just dropped it on the people who wanted it by surprise without talking to them first even just to say this is our proposal, this is how we think it solves your problem, what do you think? I can understand why some of the authors are upset and I still thing the srcset needs explaining clearly rather than them having to chew through the spec. Cheers Andy
Re: [whatwg] Bandwidth media queries
Hi Matt, You really want to know what the throughput is rather than just the bandwidth and throughput is a bit of a PITA to work out in web conditions... Throughput is a mixture of available TCP connection time, bandwidth, latency and packet loss, etc. In theory you could measure it from the browser but there are a number of issues, here are some examples: A typical webpage is made up of many components, which are retrieved via short, bursty conversations between the browser and server. The initial TCP connections go though a 'slow-start' phase while the client and server determine what's the optimal number of packets that can be sent without being acknowledged. The number of packets inflight and the latency effective set a cap on the throughput. So measuring the resources that are downloaded first would probably under report the available throughput Multiple (sub-) domains confuse things further... Assume you can effectively measure throughput from the first resources to be downloaded (HTML, CSS etc), what happens if the images are on a different domain e.g. a CDN? The throughput that's just been measured isn't applicable to the CDN's domain. Caching further complicates things as you can't use anything that's in the cache to measure throughput (or can you?) Although slightly tangential it's worth having a read of Mike Belshe's More Bandwidth Doesn't Matter (Much) - http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/ I'm not sure I'd agree with Tab's comment that authors aren't the best people to make decisions on what content should appear under different throughput conditions though. If they aren't I'm not sure who is? If it's the browser then the author still has to signal their intent to the browser so they are effectively making the choice. Cheers Andy @andydavies
Re: [whatwg] Defaulting new image solution to 192dpi
On 17 May 2012 13:05, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 12:52:47 +0100, Andy Davies dajdav...@gmail.com wrote: My suggestion is that the srcset (or picture) should assume that images are 2x scale by default. Doesn't this makes the assumption that pixel density is the most likely reason for needing the alternative image rather than viewport / image dimensions? Those two cases are orthogonal — one doesn't exclude the other, and I'm not claiming that it solves the art-directed case. srcset can be used to offer alternatives for higher or lower DPI, and/or larger or smaller viewports so I'm still not convinced that an assumption that somehow it should assume that the srcset images are 2x scale by default really helps. Much of the usage I've seen for responsive images so far has concentrated on providing images that change with viewport size rather than DPI. Cheers Andy
Re: [whatwg] Defaulting new image solution to 192dpi
On 17 May 2012 14:19, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 13:47:12 +0100, Andy Davies dajdav...@gmail.com wrote: srcset can be used to offer alternatives for higher or lower DPI, and/or larger or smaller viewports so I'm still not convinced that an assumption that somehow it should assume that the srcset images are 2x scale by default really helps. Much of the usage I've seen for responsive images so far has concentrated on providing images that change with viewport size rather than DPI. Let me reiterate: it doesn't matter. Those are *separate* issues. Responsive image is a bad term as it conflates two distinct problems (screen density adaptation and physical screen size adaptation) into one. It's not either-or choice. Both have valid use-cases. Support for high DPI displays is an absolute necessity. Don't look at current or past. Think how web development is going to look like in 5, 10 or 20 years. There will be no low-res displays in the future. Everybody is going to have Retina displays and everybody will hate that img or picture inserts crappy pixelated images. Try browsing the web on the new iPad today. That's how every display is going to look like in 10, maybe 20 years. Then DPI negotiation will not be an option, it'll be absolute requirement for *every* *single* image. HTML5 is designed for the next 50-100 years. The last line is exactly why baking in an assumption on the defaults isn't the right way to go. I don't disagree that higher DPI resolutions will be come the norm but then what are we going to do about lower DPI devices, serve them a higher DPI than needed image and let them work it out rather than serve them appropriate images? The Zombie Apocalypse is coming there will be plenty of lower DPI screens around for a long time... Cheers Andy
[whatwg] So if media-queries aren't for determining the media to be used what are they for?
Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. Andy
