DZone
Web Dev Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Web Dev Zone > Responsive Images/Leave HTML Alone

Responsive Images/Leave HTML Alone

Niels Matthijs user avatar by
Niels Matthijs
·
May. 22, 12 · Web Dev Zone · Interview
Like (0)
Save
Tweet
3.69K Views

Join the DZone community and get the full member experience.

Join For Free

responsive images ... the holy grail of modern (responsive) web design no doubt. every self-respecting web-design/front-end magazine has written at least one article about it. things are moving forward quickly now that standard organs are taking over and are trying to introduce a spec, but one can only wonder if this isn't just a quick fix that we'll regret five or more years down the line. from what i've read about it ( a list apart ), we're clearly heading in the wrong direction.

the proposed spec

there are many use cases to consider and there are as many different opinions as there are people in the front-end business. art direction, performance and implementation methodologies are all part of the problem that make or break a responsive image technique ( chris coyier made a nice overview). the problem with the proposed spec isn't so much the syntax (or variations of it) though, but the choice to make it part of the html spec. i'm clearly not the only one that thinks responsive images shouldn't be part of the html spec , the question is if there is still time left to do anything about it.

responsive lives in css

up until now responsive behavior lived primarily in css files. sure there are some back-end options (particularly when certain content is excluded from smaller resolutions), but for the bigger part it's always been about css breakpoints and changing css rules. no actual html changes are needed to make a decent responsive version of your site and that's awesome, because responsive is all about displaying content and performance, which suits css just fine.

html on the other hand is about structure and semantics, and those are not impacted when you want to serve a responsive image. sure enough there may be some art direction involved between the different sizes, but even that doesn't go beyond cropping and resizing. you may end up loading a different image file, but the content of that file is semantically the same as the related responsive images.

site version 2.0

what bugs me the most is that redesigns including new breakpoints could have a major impact on the html code. if a new breakpoint is introduced and it impacts the images, you're bound to end up fiddling with the html code, which just plain sucks. it's not very future-proof, it's expensive development and it is completely unnecessary. cmses will need to be extended to allow for this behavior and control over responsive will be spread even further between the different levels of front-end development.

it's a shame to see that a solution like this will hamper my (our) quest for unified, robust and reusable html. it's another html setback that shouldn't be allowed, if only because css has been putting enough strain on html already these past couple of years. it's time to revert that sentiment and go back to the good old separation of content,style and functionality paradigm to actually improve our profession rather than try to fix it mcguyver style. it's hard enough (i'd say almost impossible) to stay on top of everything these days and further mixing responsibilities isn't going to help us in the long run.

performance concerns

while i understand that performance is a big motivator these days, it's equally important to realize that it's a very context-dependent and contemporary issue that is impacted by every technological move forward. it's good to have build-in options that allow us to optimize performance for certain contexts, but it's also good to realize that in two (or three, or five) years time some or most of those concerns could be obsolete.

conclusion

i don't even care much about the final syntax, as long as it becomes a part of the html spec i'll be pretty damn disappointed with whatever working group or standards organ that approves this solution. it's definitely not a good move and one i'm certain we'll regret at a later time. then again, some people may start to think that's part of the charm of our profession.

i feel this is a clearly a result of the "pragmatic" vibe that has been running through our community. while it definitely brought us some good, i'm equally confident that it will introduce it's own set of drawbacks when time is due. sometimes it's just better to think something through then to apply a quick fix that may save your hide for a couple of months but will kill you when it really matters.

HTML IT

Published at DZone with permission of Niels Matthijs, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Real-Time Supply Chain With Apache Kafka in the Food and Retail Industry
  • SDLC Vs STLC: What's the Difference?
  • Evolving Domain-Specific Languages
  • Unit Vs Integration Testing: What's the Difference?

Comments

Web Dev Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo