On Thu, 17 May 2012 14:16:24 +0100, Matthew Wilcox <m...@matthewwilcox.com> wrote:

That particular solution is, to my mind, the most flexible and useful
implementation I've seen, because it's really about breakpoint
management and abstraction - which is what all responsive elements
need in order to work together well and be future-friendly.

It does, no doubt, have some technical considerations and implications
I'm not aware of. I would love to see this worked on more, I don't
think there's much more I can add to it from my authors perspective,
it needs work from an implementor perspective. But as a pattern, it
has a lot of plus points going for it.

I'm trying to figure out how it's going to work in other situations than the happy case.


What if you want to provide copy&pasteable code snippet with an adaptive image? (like W3C Validator badges)

What if you're creating WYSIWYG editor for CMSes and want to have button for inserting adaptive images, but have no access to <head>?

What if you want to insert a single image with custom/unique breakpoints (say an infographic prepared by an agency which used different breakpoints) on a website that already has its own breakpoints defined?

I see no nice solution for case when authors put <meta breakpoint> in <body> — it'd either have re-evaluate and potentially reload images (wasted requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly closes <head> or when people want to work around lack of access to the <head>)

How do you work with URLs you have no control over? e.g. you'd have to name your breakpoints "40" and "80" to have adaptive size of gravatar.com URLs.

What do you do when you have only two breakpoints for sidebar, but more for the main content? (mostly fixed-width sidebar with fluid main column) or if your page header adapts to portrait orientation, but images in main content only adapt to width?

--
regards, Kornel Lesiński

Reply via email to