Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On 6 February 2012 19:24, Irakli Nadareishvili ira...@gmail.com wrote: Boris, if you don't mind me saying it, I am afraid you may be missing the point of this request. In Responsive Web Design, device capabilities are used in a high-level fashion to determine a class of the device: smartphone, tablet, desktop. I'm afraid you have missed the point, not Boris. We do not care about device classes at all, those are a temporary and limited idea. We care about device capability. Right now we have to use screen-size as a clunky proxy for processor speed, gpu acceleration capabilties, bandwidth, latency, etc. The device class idea is no better than this already demonstrably ridiculous and inaccurate assumption that screen size correlates conclusivly with any of those values. There is *nothing* that states that a small screen means a mobile device. Or that a large screen means a desktop device. A phone today is much more powerful than a 8yr old desktop. A tiny screen device can be attached to a fast WIFI and a 27 iMac could be out in the sticks on a rubbish ISDN connection. This situation does not chance when a device reports some marketing-made-up class name. What's to stop a mobile class device having a quad core CPU and 100Mbps WIFI and a retina screen some 900px wide? What's to stop a desktop class device being hooked up to a 800x600 projector in farm country with poor connectivity? If you based your supplied assets on device class then you'd be doing both those users the wrong way around. Device class tells us *nothing* for certain. We are not interested in some temporary and imagined classing system; what we want are the device capabilities. Not assumptions of them based on other aspects (like screen size or this class idea). Such ideas do not hold up.
Re: [whatwg] iframe sandbox attribute
On Fri, 30 Mar 2012 23:27:38 +0200, Jonas Sicking jo...@sicking.cc wrote: I think there's a lot of logic to that. One thing that I think we should do as part of that is to drop the DOMSettableTokenList. By far more mapped attributes are normal DOMStrings. Such as? I thought the whole point was to do away with that so that authors do not have to implement the parsing logic anymore. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Wed, Mar 28, 2012 at 1:44 AM, Jonas Sicking jo...@sicking.cc wrote: Scanning over the buffer twice will cause a lot more memory IO and will definitely be slower. That's what cache is for. But: benchmarks... We can argue weather it's meaningfully slower or harder. But it seems like we agree that it's slower and harder. What? Are you really arguing that we should do something because of *meaningless* differences? I still don't understand what that benefit you are seeing is. You hinted at some more generic argument, but I still don't understand it. So far the only reason that has been brought up is that it provides an API for simply finding null terminators which could be useful if you are doing things other than decoding. Is that what you are talking about when you are saying that it's more generic? Yes, I've said that repeatedly. It also avoids bloating the API with something that's merely a helper for something you can do in a couple lines of code, and allows you to tell how many bytes/words were consumed (eg. for packed string arrays). It can always be added later, but it feels unnecessary. -- Glenn Maynard
Re: [whatwg] a download feedback
On Sat, Mar 3, 2012 at 6:53 PM, Peter Kasting pkast...@google.com wrote: On Sat, Mar 3, 2012 at 4:27 PM, Bjartur Thorlacius svartma...@gmail.comwrote: In special, a href=http://www.google.com/**url?sa=tamp;rct=jamp;q=l%C3%** B6gbergamp;source=webamp;cd=**2amp;ved=0CCwQFjABamp;url=** http%3A%2F%2Fwww.thingvellir.**is%2Fsaga%2Flogberg%2Famp;ei=** F69ST6T3OM6XOqGOnZEKamp;usg=**AFQjCNEPLku9Nm5bsA12_** oY9mV1gPH3Aegamp;cad=rjahttp://www.google.com/url?sa=trct=jq=l%C3%B6gbergsource=webcd=2ved=0CCwQFjABurl=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2Fei=F69ST6T3OM6XOqGOnZEKusg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aegcad=rja ... does not link to http://www.thingvellir.is/**saga/logberg/http://www.thingvellir.is/saga/logberg/. Google could fix this by linking directly. That, however, would allow for opting out of tracking by simply not running scripts. This is an unrelated issue, which a ping was designed to address. Not if Google doesn't want it to be possible to opt out of click tracking (which they might not, since it would reduce the information available to their search engine). But yes, that's a separate issue from what I was trying to demonstrate. (It's true that ping is another solution for this, but only for this very specific use case.) -- Glenn Maynard
