Comments for HTML5 Doctor http://html5doctor.com helping you implement HTML5 today Wed, 16 May 2012 21:31:49 +0000 hourly 1 http://wordpress.org/?v= Comment on HTML5 adaptive images: end of round one by musictheorysean http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25713 musictheorysean Wed, 16 May 2012 21:31:49 +0000 http://html5doctor.com/?p=4645#comment-25713 I'm a n00b to writing things with web languages and have just started looking into how to design scaled layouts. After reading a few articles about this today: I hands down want to be writing <code>picture</code> and not <code>srcset</code>. It's much more intuitive, as HTML 5 should be. I’m a n00b to writing things with web languages and have just started looking into how to design scaled layouts. After reading a few articles about this today: I hands down want to be writing picture and not srcset. It’s much more intuitive, as HTML 5 should be.

]]> Comment on HTML5 adaptive images: end of round one by Petra Gregorová http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25712 Petra Gregorová Wed, 16 May 2012 21:05:49 +0000 http://html5doctor.com/?p=4645#comment-25712 My main concern with adopting <code>srcset</code> isn't just its fugly syntax but (just like Jeremy mentioned) most importantly having risk of losing the ability sticking to mobile-first approach, which I am very much fond of and would hate for us to have to get away from. My main concern with adopting srcset isn’t just its fugly syntax but (just like Jeremy mentioned) most importantly having risk of losing the ability sticking to mobile-first approach, which I am very much fond of and would hate for us to have to get away from.

]]> Comment on HTML5 adaptive images: end of round one by Niels Matthijs http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25711 Niels Matthijs Wed, 16 May 2012 21:03:49 +0000 http://html5doctor.com/?p=4645#comment-25711 <blockquote> Instead it’s more like a media query, </blockquote> <blockquote> But if it is doing Media Queries’ job, it should look more like Media Queries. </blockquote> Am I the only one that finds it weird that with quotes likes these nobody seems to be considering actually making it a part of media queries (and css), or at least pulling all this stuff away from html where it clearly doesn't belong? Are there any good arguments why this needs to be added to the html spec?

Instead it’s more like a media query,

But if it is doing Media Queries’ job, it should look more like Media Queries.

Am I the only one that finds it weird that with quotes likes these nobody seems to be considering actually making it a part of media queries (and css), or at least pulling all this stuff away from html where it clearly doesn’t belong?

Are there any good arguments why this needs to be added to the html spec?

]]> Comment on HTML5 adaptive images: end of round one by DSKrepps http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25706 DSKrepps Wed, 16 May 2012 18:39:18 +0000 http://html5doctor.com/?p=4645#comment-25706 If I think about what I'd like using the most, I come up with this: <code> <link rel="alternate src" selector="img[src=lowres.jpg]" media="min-width:800px" href="highres.jpg" /> </code> The img tag remains unchanged. The link tag can be placed immediately before the img tag, or elsewhere, all in one place - separation of concerns. Plus, it can apply to elements other than img, while causing no trouble in older browsers but being easily polyfill-able. 'selector' is the only new attribute. Maybe somehow syntax can be created to modify urls, such as changing those that match "[src^=/lowres/]" into the /highres/ directory. That way you don't need large amounts of media queries. Maybe not even <link> is the best solution. A new element to change any attribute based on media queries? Or am I getting too out-there... <code> <adapt select="[src]" media="min-width:800px" attr="src" replace="/lowres/" with="/highres/" /> </code> Many, many use cases. Many, many abuse cases. I'm just thinking this all up as I type. Server-side solutions sound useful for some, but not all. If I think about what I’d like using the most, I come up with this:

<link rel="alternate src" selector="img[src=lowres.jpg]" media="min-width:800px" href="highres.jpg" />

The img tag remains unchanged. The link tag can be placed immediately before the img tag, or elsewhere, all in one place – separation of concerns. Plus, it can apply to elements other than img, while causing no trouble in older browsers but being easily polyfill-able. ‘selector’ is the only new attribute.

Maybe somehow syntax can be created to modify urls, such as changing those that match “[src^=/lowres/]” into the /highres/ directory. That way you don’t need large amounts of media queries.

Maybe not even <link> is the best solution. A new element to change any attribute based on media queries? Or am I getting too out-there…

<adapt select="[src]" media="min-width:800px" attr="src" replace="/lowres/" with="/highres/" />

Many, many use cases. Many, many abuse cases. I’m just thinking this all up as I type.

Server-side solutions sound useful for some, but not all.

]]> Comment on HTML5 adaptive images: end of round one by Josh T. http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25701 Josh T. Wed, 16 May 2012 16:29:53 +0000 http://html5doctor.com/?p=4645#comment-25701 I still prefer the <picture> proposal, but the arguments about why we shouldn't use media queries are good ones, and I haven't heard them mentioned before I read this. Why don't we have a compromise? <code> <picture> <source src="..." set="200w"> </picture> </code> With this method, it's much cleaner and we could still allow the media attribute for those who want it. I still prefer the <picture> proposal, but the arguments about why we shouldn’t use media queries are good ones, and I haven’t heard them mentioned before I read this.

Why don’t we have a compromise?


<picture>
<source src="..." set="200w">
</picture>

With this method, it’s much cleaner and we could still allow the media attribute for those who want it.

]]> Comment on HTML5 adaptive images: end of round one by Dale Cruse http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25698 Dale Cruse Wed, 16 May 2012 15:43:42 +0000 http://html5doctor.com/?p=4645#comment-25698 I plan to make effective use of the <yayBruce> element in all current & future projects. I plan to make effective use of the <yayBruce> element in all current & future projects.

]]> Comment on HTML5 adaptive images: end of round one by John Reading http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25695 John Reading Wed, 16 May 2012 14:46:25 +0000 http://html5doctor.com/?p=4645#comment-25695 I have a problem with the element in that it's simply too much verbosity. I can't fathom what a product grid might look like. Regardless of what is the approach, there needs to be a way to tokenize the logic that determines this. <a href="http://hellowurld.heroku.com/blog/2012/05/15/another-image-proposal-for-responsive-design/" rel="nofollow">Here's something I proposed</a> that uses the <i>link media=""</i> that we already use to tokenize the correct src attr. I have a problem with the element in that it’s simply too much verbosity. I can’t fathom what a product grid might look like. Regardless of what is the approach, there needs to be a way to tokenize the logic that determines this. Here’s something I proposed that uses the link media=”" that we already use to tokenize the correct src attr.

]]> Comment on HTML5 adaptive images: end of round one by Bruce Lawson http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25694 Bruce Lawson Wed, 16 May 2012 14:00:13 +0000 http://html5doctor.com/?p=4645#comment-25694 It troubles me, too, that the height and width syntax is pretty much duplicating Media Queries in that it suggests breakpoints to the UA but (presumably) doesn't require them. (This idea of hinting isn't new; it's part of the functionality of the preload attribute on video and audio). But if it is doing Media Queries' job, it should look more like Media Queries. It also negates the idea of the author describing the assets rather than the circumstances that the UA should use the assets. It troubles me, too, that the height and width syntax is pretty much duplicating Media Queries in that it suggests breakpoints to the UA but (presumably) doesn’t require them.

(This idea of hinting isn’t new; it’s part of the functionality of the preload attribute on video and audio).

But if it is doing Media Queries’ job, it should look more like Media Queries.

It also negates the idea of the author describing the assets rather than the circumstances that the UA should use the assets.

]]> Comment on HTML5 adaptive images: end of round one by Ian Devlin http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25693 Ian Devlin Wed, 16 May 2012 13:42:30 +0000 http://html5doctor.com/?p=4645#comment-25693 The fact that Jeremy Keith is struggling to understand what the specification says, what hope do normal (I'm not saying that you're abnormal Jeremy!) authors have? The fact that Jeremy Keith is struggling to understand what the specification says, what hope do normal (I’m not saying that you’re abnormal Jeremy!) authors have?

]]> Comment on HTML5 adaptive images: end of round one by Terence Eden http://html5doctor.com/html5-adaptive-images-end-of-round-one/#comment-25689 Terence Eden Wed, 16 May 2012 13:14:00 +0000 http://html5doctor.com/?p=4645#comment-25689 Have to slightly disagree with you there, Drew. Modern CDNs (like Akamai) do have an ability to run logic. They can even cache pages / images / etc based on user-agent. Specifically, I've used Akamai to serve an image of a different resolution to mobile & desktop. Same URL, different response based on UA. Not every browser will get updated. Of the billions of smartphones accessing the web today, very few of them will see updates from their manufacturer. That's why I'd rather see a server-side solution. I would expect to write something like <code> <img src="images/bruce" lores-scr="images/bruce-tiny" highres-src="images/large/bigbruce" /> </code> That way, the server can work out which image to serve (and do content negotiation and server phones jpg, png, svg depending on what the the user accepts) - but the browser can specifically look for high or low res images if it has been told to. (I'm using high & lo as placeholder - sure there's something more appropriate.) T Have to slightly disagree with you there, Drew. Modern CDNs (like Akamai) do have an ability to run logic. They can even cache pages / images / etc based on user-agent.
Specifically, I’ve used Akamai to serve an image of a different resolution to mobile & desktop. Same URL, different response based on UA.

Not every browser will get updated. Of the billions of smartphones accessing the web today, very few of them will see updates from their manufacturer. That’s why I’d rather see a server-side solution.

I would expect to write something like

<img src="images/bruce" lores-scr="images/bruce-tiny" highres-src="images/large/bigbruce" />

That way, the server can work out which image to serve (and do content negotiation and server phones jpg, png, svg depending on what the the user accepts) – but the browser can specifically look for high or low res images if it has been told to.

(I’m using high & lo as placeholder – sure there’s something more appropriate.)

T

]]>