The `img` element remains one of the biggest challenges for website performance, especially in responsive designs. In this excerpt from Image Performance, Mat Marquis tells us why, but he also shines a light on the solution.
JavaScript's ability to access and modify elements on the page is undeniable, and the Document Object Model is an essential component of that. In this excerpt from Mat Marquis' new book, JavaScript for Web Designers, Mat shows us how to manhandle the DOM to get better results from our scripts.
One person focuses on HTML, CSS, and JavaScript. Another writes JavaScript tests all day. And they both have the same job title: front-end developer. Mat Marquis talks about why that’s okay, and introduces our latest event, “The State of Front-End Dev”.
Media queries have been the go-to tool in building responsive sites, allowing us to resize and recombine modules to suit multiple contexts, layouts, and viewports. But relying on fixed viewport sizes can quickly twist stylesheets into Gordian knots. We still need a future-friendly way to manage responsive CSS. Mat Marquis explores the problem and the progress toward the solution—and issues a rallying call.
A decade ago here in A List Apart, we published a radical article by Peter-Paul Koch arguing for custom attributes in markup. Today, Mat Marquis takes a look back at how times have changed, and shows how PPK’s idea has worked its way into the web.
Ready for something new? We're excited to announce ALA: On Air, community-focused events where our readers can get to know our authors, staff, and others who are shaking up our industry. Mat Marquis shares all the details, and has specifics on our first event, Designing for Performance, coming up on February 26.
Building enormous websites means us shifting the burden of our mistakes onto every single user that visits our site. It’s us saying that we’re willing to build something that isn’t for some users, because that’s most comfortable for us—no different from “best viewed in Internet Explorer 5.5” or “best viewed at 600x800,” but much more costly.
At long last, the native picture element isn’t just coming: it’s here. The picture element has landed in Canary—Google’s “beta” channel for upcoming Chrome releases—and we can try it out for ourselves right now. Now, we need to test it out, look for bugs, and file issues.
After almost three years in pursuit of a standardized solution to the problem of responsive images, the Responsive Images Community Group is excited to announce that the picture element is officially coming to a browser near you. Once it lands, we’ll see the trend toward massive, bandwidth-heavy responsive websites begin to slow—and hopefully, reverse—over time.
The revival of the picture element—the responsive images proposal that has seen the most support from the developer community—is exciting news, but there are still some outstanding questions about how the element will really work. Marcos Caceres and Yoav Weiss have put countless hours into the Responsive Images Community Group’s efforts, and are now working toward picture implementations in Firefox and Chrome, respectively. Mat Marquis asked them some questions.
The picture proposal is back with a vengeance—boasting new improvements for web developers and browser developers alike—and Mozilla is officially on board. The picture element is now on the Mozilla DOM Team’s roadmap for 2014.
A List Apart gets back to its roots: building community, giving a platform to new voices, and getting people excited about the web. We’re making changes to the way we work—starting with our decision to open-source the code that powers alistapart.com itself—and we want you to participate. Our Mat Marquis invites you to contribute code and concepts via GitHub, get to know our acquisition scouts, and use ALA and its editors to share your ideas and insights with the whole web design and development community.
The dust has begun to settle after Google’s announcement that Chrome would soon be using their own divergent fork of WebKit as a rendering engine. Now that things have calmed down a bit, I’ve asked Paul Irish to share some of the Chrome team’s plans for the near future.
The W3C announced today that it intends to publish the controversial Encrypted Media Extensions extension specification despite highly outspoken resistance, paving the way for native web DRM.
If you’re looking for a thorough JavaScript style guide for your team, Rick Waldron’s Principles of Writing Consistent, Idiomatic JavaScript is a great place to start.
Google has announced that they will be moving away from WebKit in favor of their own rendering engine—“Blink”—in future versions of Chrome, and Opera is following suit.
The @supports rule recently added to the CSS Conditional Rules Module and landed in WebKit stands to be a powerful tool in a web developer’s belt, but there are some major doubts. UAs aren’t known for claiming “support” only when they truly support a feature in a fully interoperable and bug-free way. Could this potentially
Ben Kamens, lead developer at Khan Academy breaks down the clever method Amazon.com uses to prevent their drop-down menus from misfiring when users move their cursor to the revealed submenu—without introducing any delays.
Just like tweets, you can now embed ALA comments anywhere you like. This is one of those features that we’ve been wanting for our own purposes, and then we figured: as long as we’re building it, let’s give everyone the ability to embed comments.
This morning’s announcement that Opera intends to abandon its Presto rendering engine has left designers and developers with a number of questions. I sent a few over to Opera’s Bruce Lawson to shed a little light on the situation.
One of jQuery’s strengths is that it allows one to act on entire groups of elements without writing out a for loop or using jQuery’s each method to iterate through every element. Those loops are still taking place behind the scenes though, and we can use that abstraction to help—or hinder—the efficiency of our code.
Responsible responsive design demands responsive images, images whose dimensions and file size suit the viewport and bandwidth of the receiving device. As HTML provides no standard element to achieve this purpose, serving responsive images has meant using JavaScript trickery, and accepting that your solution will fail for some users.
Then a few months ago, in response to an article here, a W3C Responsive Images Community Group formed, and proposed a simple-to-understand HTML picture element capable of serving responsive images. The group even delivered picture functionality to older browsers via two polyfills: namely, Scott Jehl's Picturefill and Abban Dunne's jQuery Picture. The WHATWG has responded by ignoring the community's work on the picture element, and proposing a more complicated img set element.
Which proposed standard is better, and for whom? Which will win? And what can you do to help avert an "us versus them" crisis that could hurt end-users and turn developers off to the standards process? ALA's own Mat Marquis explains the ins and outs of responsive images and web standards at the turning point.
With a mobile-first responsive design approach, if any part of the process breaks down, your user can still receive a representative image and avoid an unnecessarily large request on a device that may have limited bandwidth. But with several newer browsers implementing an "image prefetching" feature that allows images to be fetched before parsing the document's body, some of the web's brightest developers are abandoning responsive images in favor of user agent detection, at least as a temporary solution. For us standardistas, UA detection leaves a bad taste in the mouth. More importantly, as the number and kinds of devices continue to grow, UA detection will quickly become untenable—just as browser detection did back in the bad old days before web standards. What's really needed, argues Mat Marquis, is a new markup element that works the way the HTML5 video element works. Sound crazy? So crazy it just might work.
