Re: [whatwg] Bandwidth media queries
Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. [1] http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/index.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=677166#c42 [3] http://trac.webkit.org/changeset/112815
Re: [whatwg] Bandwidth media queries
On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. And this is perfectly compliant, since the spec says: The user agent must set the value of the bandwidth attribute to: 0 if the user is currently offline; Infinity if the bandwidth is unknown; an estimation of the current bandwidth in MB/s (Megabytes per seconds) available for communication with the browsing context active document's domain. -Boris
Re: [whatwg] Bandwidth media queries
On Sun, 20 May 2012, Boris Zbarsky wrote: On 5/20/12 5:45 AM, Paul Irish wrote: Since no one mentioned it, I just wanted to make sure this thread is aware of the Network Information API [1], which provides navigator.connection.bandwidth It's been recently implemented (to some degree) in both Mozilla [2] and Webkit [3]. As far as I can tell, the Mozilla implementation always returns Infinity for .bandwidth. And this is perfectly compliant, since the spec says: The user agent must set the value of the bandwidth attribute to: 0 if the user is currently offline; Infinity if the bandwidth is unknown; an estimation of the current bandwidth in MB/s (Megabytes per seconds) available for communication with the browsing context active document's domain. If no one is planning on implementing this feature in a meaningful way, why is it in the spec? (yes I know this is not exactly the right list).
[whatwg] srcset javascript implementation (Respondu)
Hi guys, Just to let you all know, I've written a javascript implementation of srcset using a framework for responsive images (which I also wrote) called Respondu (I'm open to new name suggestions), I'd love it if someone could check that I've implemented srcset right. Respondu manages to process the DOM without allowing any assets (contained in the body) to load, it also gracefully degrades for non-js browsers and is fairly unintrusive (it simply wraps the contents of the body tags). Check out the github page (feedback, pull requests, lunch money etc. welcome) https://github.com/davidmarkclements/Respondu You can also see working examples at http://respondu.davidmarkclements.com/ The framework, and srcset implementation are currently in alpha - its not presently compatible the document.ready et. al., however you can simply put scripts at the bottom of the body instead (which is best practice in most cases anyway). So far, it's tested and works in ie8, chrome, firefox, and iOS safari. Let me know if it works/doesn't work in other browsers! All the best, Dave
[whatwg] Media queries, viewport dimensions, srcset and picture
When all the picture vs srcset started showing up on twitter, I was initially
behind picture. I'm sure you all know the arguments for it, and I liked those
arguments. Today though, I was reading an article about the two, and there was
a misunderstanding about how srcset was working in the comments, and it made me
realize that something closer to srcset would be ideal.
The big thing I realized is that as a developer, I do not want to write more
media queries - or anything that works at all like them - into image elements.
It's redundant. There's a good chance there's already a bunch of CSS in place
controlling the shape and size of the image element itself, why should I have
to write a bunch more, somewhere else, to control the src of the image too?
Why can't it work so that in the html I say here's an image, there's a version
of it at 150x150, and a version at 48x48, and then in the CSS I say that the
image is 25% of the width of the article it's in, which works out to 100px
wide, and then the browser can just decide that the 150x150 would be best, and
scale it down. If I change the CSS, I don't have to change the html too, the
images I provided are still only available at those sizes. With image/picture
sources set by viewport dimensions, even something as simple as adding more
padding around articles on a site could involve going through all the HTML and
adjusting the breakpoints in the tags. This way layout, units, and screen dpi,
don't matter when writing the HTML,
I've seen people get confused and think srcset work this way, instead of by
viewport size (unless I'm the confused one), and if they were right then srcset
would work well for this. It would be even nicer if there was something even
more CMS friendly, like:
img src=/img/people.jpg sizes=100x200 300x250 900x300
pattern=/tools/resizer.php?img=people.jpgamp;width={w}amp;height={h} alt=A
picture of some people.
So src would be the fallback, then sizes would say which dimensions are
available, in a fairly common format, using spaces to separate options like
class does. pattern (probably a bad name) would be a template for the URL the
browser can request the image from, replacing {w} and {h} with the requested
dimensions. There wouldn't need to be a token for the dpi/resoultion/whatever,
the browser could just request an image twice or three times or whatever the
size. There's no point in having sizes=100x100@1 100x100@2 200x200@1 when you
can just have sizes=100x100 200x200
This gives the designer/developer full control over the shape and size of the
image element (through CSS), while still allowing the browser to make decisions
based on bandwidth and whatnot.
--
Mike Gossmann | m...@c572.ca | http://gossmati.ca
