# Paul Irish Published articles for Paul Irish. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Video Stabilization with \`ffmpeg\` and \`VidStab\` DevFeed: [Video Stabilization with \`ffmpeg\` and \`VidStab\`]() Original publisher: [Read original article]() Author: Paul Irish Published: 2021-04-30T18:33:00Z Content type: tutorial Language: en Sources: [Paul Irish]() Topics: [FFmpeg (Fast Forward Moving Picture Experts Group)](), [Homebrew](), [Linux](), [make]() Tags: [commands](), [comparison](), [diy](), [ffmpeg](), [guide](), [install](), [installation](), [linux](), [mac](), [mac-os](), [make](), [video]() ### AI overview A practical guide to stabilizing video with FFmpeg and VidStab. It covers installation on Mac OS and Linux, the two-pass detection and transformation workflow, and commands for creating vertically stacked or side-by-side comparison videos. ### Source excerpt Way back in Dec 2015, @maxogden wrote a nice guide on stabilizing your own video with ffmpeg. I return to it on occasion and have updated my gist comment to offer some updated commands. Since enough has changed regarding installation and use, I figure a new, spiffy, and working guide deserves a non-gist home. Presenting the 2021-era guide to pretty easy DIY video stabilization! On Mac OS, install ffmpeg and vidstab from homebrew: 1 2 brew install ffmpeg brew install libvidstab On linux, you can sudo make install. Run stabilization in two passes There are plenty of options for libvidstab, like shakiness, accuracy, smoothing. The defaults are good, but you may want to experiment. There's even a visual diagnostic mode. Assuming the source video is named clip.mkv... 1 2 3 4 5 6 # The first pass ('detect') generates stabilization data and saves to `transforms.trf` # The `-f null -` tells ffmpeg there's no output video file ffmpeg -i clip.mkv -vf vidstabdetect -f null - # The second pass ('transform') uses the .trf and creates the new stabilized video. ffmpeg -i clip.mkv -vf vidstabtransform clip-stabilized.mkv You now have a clip-stabilized.mkv! Bonus: create a comparison video Use the vstack or hstack filter, depending on if you want them stacked vertically or side-by-side: 1 2 3 4 5 # vertically stacked ffmpeg -i clip.mkv -i clip-stabilized.mkv -filter_complex vstack clips-stacked.mkv # side-by-side ffmpeg -i clip.mkv -i clip-stabilized.mkv -filter_complex hstack clips-sxs.mkv Double bonus: A two-liner that does everything (because repeating these filenames gets annoying) 1 2 export vid="sourcevid.mkv" ffmpeg -i "$vid" -vf vidstabdetect -f null -; ffmpeg -i "$vid" -vf vidstabtransform "$vid.stab.mkv"; ffmpeg -i "$vid" -i "$vid.stab.mkv" -filter_complex vstack "$vid.stacked.mkv" ## rAF Internals & Node Debugging Guide DevFeed: [rAF Internals & Node Debugging Guide]() Original publisher: [Read original article]() Author: Paul Irish Published: 2018-02-28T20:33:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Node.js](), [Chrome](), [debugging](), [Tooling]() Tags: [chrome](), [console](), [debugging](), [guide](), [js](), [metrics](), [node](), [performance](), [tooling]() ### AI overview An article covering requestAnimationFrame scheduling and a guide to debugging Node.js with Chrome DevTools, with additional references to Lighthouse, performance metrics, tooling, and DevTools. ### Source excerpt I've published a few articles on Medium that may interest the reader here: requestAnimationFrame Scheduling For Nerds Understand how rAF callbacks are scheduled and why its very reasonable to have multiple callbacks execute within the same frame. Debugging Node.js with Chrome DevTools The canonical guide to using the Chrome DevTools UI for debugging Node.js. It definitely beats console.log. ;) Aside from that, I've been busy working on Lighthouse, performance metrics, tooling, and DevTools. ## Advanced Performance Audits with DevTools DevFeed: [Advanced Performance Audits with DevTools]() Original publisher: [Read original article]() Author: Paul Irish Published: 2015-03-27T15:46:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [developer tooling](), [Chrome](), [browser](), [Front end](), [Latency](), [infinite scroll](), [Google]() Tags: [audits](), [case-study](), [chrome](), [frontend](), [google](), [infinite-scroll](), [latency](), [performance](), [profiling](), [tooling]() ### AI overview An advanced performance audit of real-world mobile and desktop websites using profiling and the 1000/100/6 performance model. It examines scrolling on CNET, CNET input latency, responsive challenges on Time.com, and infinite scroll on Google Play, with findings intended to improve developer practices, browser APIs, Chrome DevTools, and the Blink rendering engine. ### Source excerpt Recently, I've spent some time recently profiling real-world mobile websites. Using the 1000/100/6 performance model1, and spelunking deep into each app, the findings have been fascinating. I've written up case study documents for each, incorporating all the findings: Illustrated diagnoses for the poor performance What actions the developer should take How Chrome's tooling should improve Questions and insights for the rendering engine (Blink) ➜ Perf Audits: CNet, Time, Google Play In this doc, we look at the scrolling of CNET, input latency on CNET, some very interesting challenges on the responsive Time.com, and infinite scroll on Google Play's desktop site. The intended audience is browser engineers and performance-minded frontend developers. It's fairly advanced, but I'm spelunking deep to identify how the sites butt heads with the browser APIs and architecture. Lastly, we're using this research to improve Chrome DevTools and what you hear from Chrome. Wikipedia eng team scrutinizing their performance millisecond by millisecond. (Yes, it's a long paper printout of the Chrome DevTools timeline flamechart :) Photo by Ori Livneh, CC BY 4.0 (BTW, use this link to view the same doc but with comments enabled) 1 - More on this performance model later. Stay tuned. ## WebKit for Developers DevFeed: [WebKit for Developers]() Original publisher: [Read original article]() Author: Paul Irish Published: 2013-02-28T10:53:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [WebKit](), [browsers](), [web browser](), [Parsing](), [Web platform](), [Chromium]() Tags: [android](), [apple](), [browser](), [browsers](), [chrome](), [chromium](), [css](), [developers](), [html](), [javascript](), [mac-os](), [parsing](), [safari](), [web](), [web-browser]() ### AI overview This article explains WebKit as an open browser engine and examines how WebKit-based browsers share components while differing across platform-specific ports. It covers parsing, layout, rendering, networking, hardware acceleration, and WebKit's use in Safari, GTK-based environments, and mobile browsers, while preserving a historical snapshot from early 2013. ### Source excerpt Feb 2015: A lot's happened since I wrote this post two years ago. Chrome forked WebKit and started Blink, Opera adopted Chromium, and node-webkit became nw.js. This post describes a complexity of defining WebKit that doesn't exist much anymore; with Chrome's departure the WebKit world is more simple and clear. WebKit is deployed through iOS Safari and Mac Safari, and the active GTK community leverages WebKit inside the GNOME Platform. Some smaller mobile browsers use WebKit, some Chromium, some use forks of either, and many just use the system WebViews that are both powered by up-to-date version of iOS WebKit and Android Chromium. The post below is kept intact and represents a snapshot of history in early 2013, rather than the modern WebKit landscape. For many of us developers, WebKit is a black box. We throw HTML, CSS, JS and a bunch of assets at it, and WebKit, somehow.. magically, gives us a webpage that looks and works well. But in fact, as my colleague Ilya Grigorik puts it... WebKit isn't a black box. It's a white box. And not just that, but an open, white box. So let's take a moment to understand some things: What is WebKit? What isn't WebKit? How is WebKit used by WebKit-based browsers? Why are all WebKits not the same? Now, especially with the news that Opera has moved to WebKit, we have a lot of WebKit browsers out there, but its pretty hard to know what they share and where they part ways. Below we'll hopefully shine some light on this. As a result you'll be able to diagnose browser differences better, report bugs at the right tracker, and understand how to develop against specific browsers more effectively. Standard Web Browser Components Let's lay out a few components of the modern day web browser: Parsing (HTML, XML, CSS, JavaScript) Layout Text and graphics rendering Image decoding GPU interaction Network access Hardware acceleration Which of those are shared in WebKit-based browsers? Pretty much only the first two. The others are handled by individual ## Why moving elements with translate() is better than pos:abs top/left DevFeed: [Why moving elements with translate() is better than pos:abs top/left]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-12-20T08:00:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [CSS](), [modern web development](), [developer tooling](), [Chrome](), [HTML5 and CSS3 tricks]() Tags: [chrome](), [css](), [examples](), [html5](), [laptop](), [layout](), [performance](), [pixel](), [update](), [writeup]() ### AI overview This article compares moving elements with CSS 2D transforms such as translate() against absolute positioning with top/left. Using Chrome DevTools evidence, it explains that transforms can move an element on a GPU-composited layer, reducing per-frame paint work and producing smoother animation, while noting that pixel snapping can sometimes make top/left appear visually preferable. ### Source excerpt Update (2016): The more canonical writeup of this technique is at High Performance Animations - HTML5 Rocks. TL;DR: Only transform & opacity; never top/left! In modern days we have two primary options for moving an element across the screen: using CSS 2D transforms and translate() using position:absolute and top/left Chris Coyier was asked why you should use translate. Go read his response which covers well why it's more logical to move elements for design purposes (with transform) independent of your element layout (with position). I wanted to answer this with Chrome and get some good evidence on what's going on. I ended up recording a video on the experience: It's a good watch and dives into Chrome DevTools' Timeline, compositing, paint cost, accelerated layers, and more... but if you want the abbreviated text version, read on: First thing, Chris made some simple demos to try things out: This sorta works, but there is such low complexity in this situation that it's all going to look pretty great. We need something closer to a complex website to properly evaluate the two (thx joshua for the macbook!): Now we're starting to get closer, but immediately I get distracted by something. Distraction: Pixel snapping If you run the demo above you might notice the top edge of the MacBook looks a little bit better in the top/left one. (And here I am writing a post about why translate is better! Preposterous!) So this is due to the absolute positioned macbook sticks to pixel positions, whereas the translate()'d one can interpolate at sub-pixel positions. One of the Chrome GPU engineers, James Robinson, called this the "dubstep effect", as these pixels appear to be getting pounded by bass. Here's a closeup of the effect... watch the top white edge of the macbook in each: On the left, you see stair-stepping down three pixels and back up again. This pixel snapping may result in a less distracting transition in this case, though this wouldn't be so noticeable if you were moving object ## Chrome Canary for Developers DevFeed: [Chrome Canary for Developers]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-11-02T15:16:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Chrome Canary](), [Chrome](), [Front end](), [Chromium](), [Developer Tools](), [Web platform](), [Instrumentation](), [shaders](), [WebRTC]() Tags: [chrome](), [chrome-canary](), [chromium](), [developer](), [developers](), [experimental](), [front-end](), [install](), [instrumentation](), [jpeg](), [linux](), [mac](), [shaders](), [update](), [web-platform](), [webrtc](), [windows]() ### AI overview The article recommends Chrome Canary for front-end developers who use Chrome as their development browser. It highlights daily builds, early DevTools and web platform features, experimental capabilities, side-by-side installation with Chrome Stable, and the value of monitoring upcoming changes before they reach stable users. ### Source excerpt If you do front-end web development and already use Chrome as your development browser, I encourage you to use Chrome Canary. A new Chrome Canary build is available daily (we cut at 2am PST and take the best of last 40 revisions, to be specific). Running fresh builds gives you great goodies to look forward: Chrome DevTools features $_ (for the Console's most recently evaluated result) Styled console logs (see The Breakpoint ep #2) JPEG decoding time instrumentation in Timeline Lots more: read Beverloo's WebKit updates and the Web Inspector commits RSS feed Features for the web platform HTML5 Rocks, peter.sh, and @chromiumdev are wise news sources for this. CSS Shaders, holla! Large, experimental features (go visit about:flags) Right now, there's exciting stuff like Web Component's Shadow DOM, WebRTC's Peer Connection, and more. Canary runs side by side The other reason why Canary is great is because it can run side-by-side with your other Chrome install. In fact this is why the URL for Canary's download page is "sxs". I recommend running Chrome Stable and Canary. That's how most of the Chrome Developer Relations team does it. You never need to update your browser, you can watch the new stuff coming at you (and file bugs if it breaks) and still see what your users see. 11 Weeks From Canary to 310M Users Fun fact: when a feature lands in Canary, it's only a short 11 week trip down to shipping to all 300+ million Chrome users on stable. That is, as long as everything is on schedule and the feature doesn't need to bake a little longer on dev channel before making its way down. Given that, it's a smart move as a dev team to watch as features (and sometimes bugs) trickle down to have time to adapt. When a new stable Chrome is ready, all users will have it within just a few days. Canary is available for Mac and Windows, but sadly not Linux. :( But luckily there are packages that track the dev channel Chromium that'll keep you up to date on a weekly basis, so you can have a ## Interview On Treehouse DevFeed: [Interview On Treehouse]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-10-29T12:07:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [frontend development](), [Web Development](), [Boilerplate](), [Tooling](), [HTML5]() Tags: [development](), [frontend](), [html5](), [interview](), [tooling](), [web-development]() ### AI overview An interview with Treehouse discusses frontend development, the author's background, HTML5 Boilerplate, and tooling. It highlights HTML5 Boilerplate features, fallback scenarios in web development, and whether developers should understand abstractions and their underlying mechanisms. ### Source excerpt The great folks at Treehouse sat down with me for 30 minutes to talk about frontend development, my background, HTML5 Boilerplate and tooling. A few highlights: 3:40 Where'd I grow up? What was I into? (Also, the supercool IE4 DHTML event I went to!) 14:45 What's my favorite feature inside the HTML5 Boilerplate? 18:34 Will web development even out where we don't need to fuss over so many fallback scenarios? 22:52 Are abstractions okay? Should you always learn what's going on under the covers first? I've also updated the interview listing on my About page. <3z ## Why I'm so excited about Web Platform Docs DevFeed: [Why I'm so excited about Web Platform Docs]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-10-08T20:09:00Z Content type: opinion Language: en Sources: [Paul Irish]() Topics: [Documentation](), [Web platform](), [web-standards](), [Web Development](), [browser](), [browsers](), [CSS](), [HTML](), [Canvas](), [Document Object Model (DOM)](), [HTML5](), [SVG]() Tags: [article](), [blog](), [browser](), [browsers](), [bugs](), [community](), [contribute](), [css](), [desktop](), [docs](), [google](), [html](), [html5](), [js](), [mobile](), [standards](), [svg](), [ui](), [web](), [web-platform]() ### AI overview The article celebrates the launch of Web Platform Docs as a shared effort by browser vendors, companies, technical writers, and the community to consolidate documentation for client-side web technologies. It explains that the project should make browser and device compatibility information easier to find and invites contributions of writing, support data, bug fixes, and content strategy expertise. ### Source excerpt I absolutely love developing for the clientside of the web. Delivering the actual interactions and UI that all users feel is an absolutely gratifying experience. However... it's not a piece of cake to develop for all desktop browsers, mobile browsers, and all the device/OS combinations within. It's hard to track down accurate info, but hey we get by with an unruly combination of Mozilla's MDN, StackOverflow, HTML5 Please, W3C/WHATWG specs, Wikipedia, and a mental inventory of blog posts, tweets and articles strewn over the internet. Today's announcement of Web Platform Docs, an initiative that's been well over a year in the making, is huge. A few reasons why I'm pumped: All browser vendors are working together to document the all of the clientside web: DOM, CSS, HTML, SVG, Canvas, HTML5, JS, ES5... They've already contributed much of their content: all of the MSDN IE reference docs, the Opera Web Standards Curriculum, many HTML5 Rocks articles, Full-time technical writers from Google, Microsoft, Adobe and others authoring content around new features in addition to the strong community contributions. And obviously, a much more cohesive documentation situation, making it easier for us to develop with all the information we need. Mozilla's MDN content can be contributed! The content is still alpha, but we now have a single place to document the web platform. How can you help? "Upstream" your writing. If you've written a widely cited article exploring a feature or documenting cross-browser bugs, gotchas, certainly you can help a educate a vastly wider audience. Contribute browser support data. We thrive on knowing the mobile/desktop compat story. PPK will be publishing his compat tables there, and you can upstream compat facts from other sources freely. Fix bugs! Already a few bugs/annoyances have been unearthed. Please report them but more importantly, we'd love help fixing them! Attach a patch to a bugzilla ticket and we can push it live ASAP. Poke around the WPD: prefixe ## A browser benchmark that has your back: RoboHornet DevFeed: [A browser benchmark that has your back: RoboHornet]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-09-24T21:51:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Benchmark](), [browser](), [Web Development](), [JavaScript](), [Document Object Model (DOM)](), [API](), [SVG](), [Canvas](), [jQuery](), [Ember](), [Handlebars](), [LocalStorage]() Tags: [api](), [benchmark](), [browser](), [issue-tracker](), [javascript](), [performance](), [selectors](), [speed](), [svg](), [tests](), [web](), [web-development]() ### AI overview RoboHornet is an open-source, cross-vendor browser benchmark designed to measure real-world web performance problems rather than only raw JavaScript speed. It uses developer-submitted and community-selected tests covering bottlenecks such as DOM operations, API methods, SVG, canvas, storage, and rendering. ### Source excerpt The past few years' browser focus on speed has been great for us and our users. We've seen a huge and dramatic performance boost on benchmarks like Sunspider, Kraken, and Octane. But, these benchmarks, often crafted by JavaScript VM engineers, test raw JavaScript performance, which is rarely the bottleneck we have in our apps. These days, our performance bottlenecks are oftentimes DOM, API methods, SVG. Those are our priorities. So then why do we see all browser vendors competing on raw JS when we are hacking our way around to avoid the actual performance pain points? So we wanted to solve that with RoboHornet. Today, a cross-vendor collection of developers, led by Google, is open-sourcing RoboHornet. As project lead Alex Komoroske put it, "it's a living, dynamic benchmark that aims to use the collective efforts of the web development community and ultimately get browser vendors to fix real-world performance pain points." Let's look at how RoboHornet will hopefully flip the above situation on its head. Web app developers identify and isolate a specific pain point in their app That issue is reduced down to a solid benchmark Propose it to a committee of JavaScript experts from JSPerf, YUI, Google, Facebook, and others Everyone votes for which issues should make it Of the top voted items, as long as the committee thinks they are good, they head into the benchmark The RoboHornet Suite now better represents the web app developer communities biggest priorities for performance Browser vendors compete on their RoboHornet score, optimizing the slow behaviors that developers prioritize Everybody wins. Yay ice cream for everyone! What's in there now The current items that RoboHornet tests captures the major pain points of jQuery, Google Apps, Google Maps, Ember, Handlebars and Cappuccino: Adding rows to an existing table Adding columns to an existing table Descendant selectors at different DOM depths Converting a 2D canvas to a data URI Clearing a 2D canvas Table rend ## Academic research on browsers, frontend development, and debugging DevFeed: [Academic research on browsers, frontend development, and debugging]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-09-13T15:45:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [browsers](), [frontend development](), [debugging](), [Development](), [JavaScript](), [web applications](), [Document Object Model (DOM)](), [Ajax](), [Security](), [Mobile](), [LocalStorage](), [Node.js]() Tags: [academic-research](), [browser](), [browsers](), [debugging](), [debugging-tools](), [development](), [frontend](), [frontend-development](), [javascript](), [mobile](), [node-js](), [performance](), [realtime](), [research](), [security](), [web-applications]() ### AI overview An English developer article curates academic papers, talks, and researchers focused on browsers and frontend development. It covers browser capabilities, DOM events, client-side validation, mobile performance and energy use, web-application race detection, debugging tools, Node.js performance visualization, and browser security research. ### Source excerpt University-level education has never really touched too directly on what we do as frontend developers. I know I was self-taught in the ways of the browser, as were all of my friends. Luckily the sort of webapp work we do these days is quite sophisticated so those CS graduates bring much of the great ideas to the JavaScript community. (Alex Sexton has been a personal inspiration here) Early last year, something clicked in my head when I saw this video: Crossing the Chasm: Pitching Security Research to Mainstream Browser Vendors. You mean.. there are academics... who are doing research on browsers.. in universities? My my! You mean bright minds think about the same things as us and don't publish them on Octopress? ;) Turns out it's quite an active area of research. So, I've put together a list of academic papers, talks, and researchers all centered around frontend development and browsers (Please chime in on the comments if you know of more): Webapps Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX UC San Diego, Microsoft Research, Univ. of Singapore, 2012 Modeling and Reasoning about DOM Events Brown University, 2012 Don't Repeat Yourself: Automatically Synthesizing Client-side Validation Code for Web Applications University of Illinois at Chicago, 2012 Performance Who Killed My Battery: Analyzing Mobile Browser Energy Consumption Stanford, 2012 How far can client-only solutions go for mobile browser speed? ACM Digital Library, 2012 Race Detection for Web Applications Sofia University & ETH Zurich & IBM T.J. Watson Research Center, 2012 Leo Meyerovich - Berkeley Rsearch UC Berkeley, 2009 (Parallel Browser Execution, Security) James Mickens - Microsoft Research Microsoft, 2004- (Performance, localStorage, Mashups, Speculative Execution James Mickens, the Galactic Viceroy of Research Magnificence at Microsoft Research, does awesome work. The above shot is from his MIX11 talk Making Better Web Apps For Today's Browsers. Debugging & Tools Timelapse - Interactiv ## Developers We Admire. DevFeed: [Developers We Admire.]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-08-17T18:46:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [front-end-development](), [Open Source](), [Front end](), [CSS](), [HTML5](), [SVG](), [Document Object Model (DOM)](), [debug](), [API](), [browsers](), [Graphs](), [data]() Tags: [accessibility](), [api](), [articles](), [css](), [developers](), [front-end](), [front-end-development](), [graphs](), [html5](), [javascript](), [open-source](), [svg](), [web-browsers]() ### AI overview An appreciative survey of front-end developers whose teaching, open-source contributions, research, and evidence-based opinions have benefited the web development community. It highlights work involving Modernizr, polyfills, DOM APIs, source maps, HTML5 Boilerplate, CSS, browser compatibility data, accessibility, JavaScript libraries, and SVG. ### Source excerpt One of the good things about having the eyeballs of many people is that you now have the ability to throw other people into the limelight that completely deserve to be in it. Divya Manian and I have been, for a while now, putting together a list of people in the front-end development community who, in our opinion, could use more broad acknowledgment and attention. They're also inspiring because... They are excellently skilled in their area of expertise and go out of their way to teach others how to gain these skills They participate in open source projects that fuel the community's knowledge and productivity They have independent opinions that are derived out of testing, and evidence-based fact finding worthy of learning from So, here is a list of people we admire: Ryan Seddon: @ryanseddon aka the CSS Ninja develops Modernizr, writes polyfills, and explores the edge of DOM APIs. His recent exploration of source maps lays a lot of groundwork for future web debugging potentials. Hans Christian Renl: @drublic started contributing extensively to HTML5 Boilerplate and has been actively engaged in other projects we have worked on. He also maintains a blog where he shares his learning experiences and explorations of advanced CSS features. Alexis Deveria: @fyrd maintains caniuse.com, and contributes to svg-edit, the open source svg editor. He also created & maintains the canonical timeline of web browsers which has been the basis of other browser history graphs since. He also upstreams all the data from caniuse.com to its API, is used to power sites such as api.html5please.com and html5rocks.com Jason Kiss: @jkiss's notes on accessibility are like a breath of fresh air into the dense field of accessibility. He tests in as many accessibility technology tools as available and bases his opinions on findings from his research. His articles are extremely valuable to web developers who have long had to base how to do the right thing on superstition and fact-free opinions. Kit Cambr ## The Skinny on IE's Update Policy DevFeed: [The Skinny on IE's Update Policy]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-06-29T17:47:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [browsers](), [Microsoft](), [Web](), [Windows](), [HTML5]() Tags: [australia](), [brazil](), [browsers](), [china](), [developers](), [microsoft](), [update](), [upgrades](), [web](), [windows]() ### AI overview The article explains Microsoft's Internet Explorer autoupdate policy and its implications for web developers. Important updates are installed automatically by default, moving users on older Windows versions from IE6-IE8 toward newer IE releases, while allowing users and enterprises to opt out. The policy aims to reduce the number of users on obsolete browsers, though enterprise intranet compatibility and remaining regional holdouts continue to limit its impact. ### Source excerpt Every month, WebKit, Firefox and Opera are shipping incredible features; IE10 is also going to settle up and even out those HTML5 Test scores (plus some features they may debut, like Grid Layout!). But while these features are becoming available in some browsers, most of us can't use them because we have a sizable audience who have been left behind on old browsers. A while ago I made a big fuss about IE's lack of solid upgrade path and how it meant we'd end up with 10 major versions of IE in the wild. But luckily, things took a turn for the better when Microsoft announced a new autoupdate policy for IE. I wanted to take a moment to explain what this IE update policy means for us web developers. The big change is how IE now interacts with Windows Update: Before you had to opt-in to have "Recommended" updates installed automatically. It's likely few folks did. Now, IE upgrades are shipping as "Important" and this class of updates are defaulted to install automatically. A user can still opt-out and immediately after the announcement of this feature they also published details on how enterprises can opt-out. But still, this is a good move, it helps. The policy manifests as: Windows XP holdouts on IE6 or IE7 get the boot up to IE8 Windows Vista and 7 users still on IE7 or even on IE8 get shunted up to IE9 IE10 only works on Win7+, and while no policy has been published for Win7 users, it's likely any IE8/IE9 users will be moved up to IE10. A very smart policy call was that this update policy also includes all of China, which is important because most of their Windows installs are not genuine. Microsoft decided they should get the IE bump anyway, which is great because China has been dominated by IE6 and IE8 for ages. This update procedure was scheduled to start in Australia and Brazil in January 2012. If we look at what happened in Brazil, we have a good shift of users but it's flattened out with a nontrivial amount of left behind users: (see the two blue lines in the ch ## Accessibility and Developers DevFeed: [Accessibility and Developers]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-06-01T07:19:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Accessibility](), [aria](), [browsers](), [Usability](), [Web Development]() Tags: [accessibility](), [aria](), [browsers](), [developers](), [usability](), [web](), [web-developers]() ### AI overview The article argues that web developers need practical, experience-based guidance on accessibility. It emphasizes keyboard navigation as a crucial first step, explains that accessibility should not be equated with JavaScript-disabled functionality, and highlights the importance of understanding how screen readers, browsers, and ARIA markup affect users. ### Source excerpt Jacob Thornton has an inspiring slide deck on accessibility that brings to fore some of the concerns that web developers have with implementing features around accessibility. For a very long time, developers have been told about making websites 'accessible'. Like it is a faucet that should be turned on or off. Till Victor Tsaran's demonstration of using a screenreader (which was in 2007 - a very long time since accessibility evangelism began) - very few web developers had any idea of the real immediate impact of implementing accessibility features. During a Nicholas Zakas & Victor Tsaran talk years ago I finally grokked the easiest rule for a first step towards accessibility. For such a long time, we conflated functionality while JavaScript-disabled with "being accessible". It took me years to learn that making it keyboard-navigable was the top priority. Just as a datapoint, The WebAIM survey results (published yesterday) reveal 98.6% of screenreader users have javascript enabled. What we need People like Jason Kiss and Steve Faulkner who detail the behavior and support in browsers and screenreaders are providing the developer community with invaluable knowledge, stuff that is far more worthwhile than publishing a yet another list of you-should-do-these-things. (See also my resources list in the semantics post). Most developers have no idea what effect adding ARIA markup to our documents has on people using screenreaders. We need that. Actual before-and-after video stuff makes this topic real. See zomigi's recent post: videos of screenreaders using ARIA, for great examples. Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience. Just like it's valuable to witness an a11y usability session where you see how disabled people use your site, I think it'd be useful for the accessibility community to see how developers build, because thus far there has been a disconnect in communicati ## Talk: Tooling & The Webapp Development Stack DevFeed: [Talk: Tooling & The Webapp Development Stack]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-05-01T16:57:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Tooling](), [Development](), [Front end](), [Web Development](), [Web app](), [Testing](), [Optimization](), [Framework](), [Boilerplate](), [mvc](), [Instrumentation](), [Integration testing]() Tags: [code](), [components](), [developers](), [development](), [front-end](), [instrumentation](), [integration-testing](), [mvc](), [optimization](), [testing](), [tooling](), [tools](), [workflow]() ### AI overview This article presents a talk about the tooling ecosystem for front-end web application development. It organizes tools by development phase, covering boilerplate, authoring abstractions, frameworks and application stacks, iteration and testing, performance tuning, build optimization, and deployment. ### Source excerpt One of the things I recognize at Google is how productive developers surround themselves with powerful tools for iterative development and debugging. For us front-end developers, the ecosystem of tools has exploded in the past two years, as we have a lot more software and libraries beyond Firebug and jQuery to help us build webapps. In the talk below I walk through the current ecosystem of tools and how they can make your development experience a more enjoyable one. My slides: Because there are so many tools around, I wanted to break them down somehow. I think contextualizing the tools as to what phase of development that assist with works well: (You could think of the Y-axis here as the amount of code in a project..) Looking at our tools this way we end up with: Boilerplate You likely start a project with more than a single blank text file. Authoring Abstractions CSS preprocessors, Languages that transpile to JS, Templating Frameworks and Application Stack Clientside MVC, UI Components, Widgets Iteration Workflow Browser Devtools, Browser/Unit/Integration Testing Performance Tuning Profiling, Memory mgmt, browser instrumentation Build & Optimization Minifiers, Concat, Image compression... Deploy Continuous Integration, Continuous deployment I've been thinking a lot about workflow and integrating these tools together. Screencasts like Andrey Tarantsov's Sublime Text Workflow really excite me and I'm eager to see more people exploring a robust development setup. 2012.05.16: Mr Jon Kemp wrote up an outline of my talk with all the links, for easy clickability: https://gist.github.com/2713513 ## Vendor prefixes are not developer-friendly DevFeed: [Vendor prefixes are not developer-friendly]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-03-05T07:06:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [CSS](), [Developer experience](), [web-standards](), [Web Development]() Tags: [compatibility](), [cost](), [css](), [developer](), [developer-experience](), [standards](), [tool](), [web-developers]() ### AI overview The article argues that CSS vendor prefixes conflict with practical developer workflows. It describes inconsistent use of prefixed properties, the maintenance burden of updating production CSS, and how tools tend to prioritize unprefixed declarations, potentially undermining the purpose of prefixes. ### Source excerpt or... The premise of prefixes makes unrealistic demands on how developers maintain sites There's a lot of conversation about making prefixes work (by changing policy), but I believe they already are at odds with the developer workflow. In this proposal I hope to show that: prefixes are not developer-friendly recent features would have been in a much better state without prefixes implementor maneuverability is not hampered without prefixes The developer experience If I'm using a feature that's prefixed, I have a choice of using a tool to help me manage outputting the various prefixes I need or I'll do it myself. Based on my informal poll last week it looks like 40% of developers are not using tools. Without tool usage, authors are not including -ms-, -o- or the unprefixed variants. Page 4 of Mozilla's prefix report verifies this; developers don't write necessary prefixed properties about half the time (e.g. -o-transform) and in fact, they already write out the unprefixed variant well before the spec goes to CR (and do this well before adding in -ms- or -o- compatibility). Data summarizing prefixes' failure with developers [Mozilla's prefix report, page 4] This matches my experience as well. I don't want to return to this code to maintain it, so I'm going to add the unprefixed version. There is less of a cost to me leaving the unprefixed version and assuming I won't need to change it vs. returning to my CSS of shipped-to-production work to add unprefixed variants each time a feature hits CR. Any successful evangelization plan for prefixes relies on tools, but all tools prioritize the unprefixed state. prefix-free, compass, and css3 please (I'm a tool vendor, too) all heavily suggest starting with the unprefixed state. So any successful evangelization push will just result in the unprefixed version being 100% deployed from the get-go, which ties implementors hands anyway and defeats the purpose of the prefix. I don't have data to show that developers are not returning to ## \* { box-sizing: border-box } FTW DevFeed: [\* { box-sizing: border-box } FTW]() Original publisher: [Read original article]() Author: Paul Irish Published: 2012-02-01T17:11:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [CSS](), [Front end](), [browser](), [WebKit](), [polyfill](), [jQuery]() Tags: [browser](), [chrome](), [css](), [firefox](), [front-end](), [layout](), [padding](), [polyfill]() ### AI overview This article recommends applying a natural border-box sizing model to all elements by setting box-sizing on html and inheriting it through elements and pseudo-elements. It explains how this keeps declared widths stable when padding is added, discusses browser support and required prefixes for older Firefox, iOS, and Android versions, and notes compatibility with jQuery, Chrome DevTools, and mobile devices. ### Source excerpt One of my least favorite parts about layout with CSS is the relationship of width and padding. You're busy defining widths to match your grid or general column proportions, then down the line you start to add in text, which necessitates defining padding for those boxes. And 'lo and behold, you now are subtracting pixels from your original width so the box doesn't expand. Ugh. If I say the width is 200px, gosh darn it, it's gonna be a 200px wide box even if I have 20px of padding. So as you know, this is NOT how the box model has worked for the past ten years. Wikipedia has a great history of this box model. Jeff Kaufman also dove into the history Anyway, I have a recommendation for your CSS going forward: 1 2 3 4 5 6 7 /* apply a natural box layout model to all elements, but allowing components to change */ html { box-sizing: border-box; } *, *:before, *:after { box-sizing: inherit; } Update August 2014: This code was updated to match new box-sizing best practices. Also prefixes are pretty much dead. This gives you the box model you want. Applies it to all elements. Turns out many browsers already use border-box for a lot of form elements (which is why inputs and textareas look diff at width:100%;) But applying this to all elements is safe and wise. Browser support Due to browser support, this recommendation is only for projects that support IE8 and up. (Full browser compat at MDN) Firefox <= 28 still needs the -moz- prefix, and <= iOS4, Android <= 2.3 need the -webkit-, but everyone else uses the unprefixed. You can find more info about a box-sizing polyfill for IE6 & 7 at html5please.com/#box-sizing (which was developed with * { box-sizing: border-box!). Is it safe to use? Totally. jQuery works pretty great with it (except this). As mentioned, browser support is excellent. And a number of projects use this layout model by default, including the WebKit Web Inspector (aka Chrome DevTools). I heard from Dutch front-end developer Yathura Thorn on his experience: We've ## Moving The Web Forward DevFeed: [Moving The Web Forward]() Original publisher: [Read original article]() Author: Paul Irish Published: 2011-12-04T03:33:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Web](), [Web platform](), [GitHub](), [frontend development](), [Front end](), [IRC](), [jQuery](), [Boilerplate]() Tags: [community](), [contribute](), [developers](), [development](), [frontend](), [frontend-development](), [github](), [html5](), [open](), [platform](), [project](), [repo](), [resources](), [standards](), [team](), [web](), [web-platform](), [web-standards](), [writeup]() ### AI overview The article introduces Move the Web Forward, an initiative that helps people channel their interest into practical contributions to the web community and web platform. It describes the initiative's collaborative creation through design, frontend development, IRC, etherpad, and GitHub, and highlights examples of participants contributing to web standards, Firefox, BuddyPress, and documentation. ### Source excerpt This Wednesday, me and a ragtag team of like-minded developers launched Move the Web Forward, an initiative to direct people's passions into productive efforts that assist not only the web community but the entire web platform. People often feel the need to "give back", but when it comes to contributing it's a challenge to find the right place. This is something I've seen happen firsthand in the jQuery and HTML5 Boilerplate communities. The MWF effort was inspired by a tweet by WebKit extraordinaire Dimitri Glazkov. If you want to help out with Web standards, you could wear a blue beanie once a year. Or you could start hacking on WebKit/Gecko. -- Dimitri Glazkov (@dglazkov) December 29, 2010 Me and Divya started brainstorming on an etherpad. We rounded up some folks on Google+ and IRC and started collecting a lot of excellent resources. Soon after a design was in the making and we started working in an open repo on github... At this point, I want to call out Mat Marquis aka @wilto, in particular, for really taking early ownership of this project and spearheading the design and frontend development. His efforts really made the site communicate its content effectively. Naturally the site is on github if you'd like to contribute. We have a few issues open that we'll be improving the site with. (Also, let me just say for projects like this, a cron job to pull latest from Github makes for such a relaxing workflow.) Thanks to Divya, Mat, Aaron Forsander, Connor Montgomery, Stephanie Rewis (great writeup!), Nicolas Gallagher, Addy, and all these awesome folk. Truly a socially developed site; everyone collaborating on IRC, etherpad and github (with as many having commit rights as possible). Fun project to work on and I hope to see everyone find the right place for them to get more involved in actively making the web as awesome as you want it to be. 2011.12.02: #movingwebforward in action! Beyond all the people who signed up (with the avatars) on the site to commit to things.. ## Web browser, frontend and standards feeds to follow DevFeed: [Web browser, frontend and standards feeds to follow]() Original publisher: [Read original article]() Author: Paul Irish Published: 2011-11-22T03:57:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Front end](), [frontend development](), [browser](), [Web](), [JavaScript](), [GitHub]() Tags: [blog](), [blogging](), [browser](), [development](), [frontend](), [frontend-development](), [github](), [javascript](), [news-reader](), [standards](), [web]() ### AI overview A curated collection of frontend development, web standards, browser news, and large web application feeds, organized into downloadable OPML bundles for import into a news reader. The article also encourages durable blogging and recommends several weekly newsletters. ### Source excerpt While a lot of conversation has moved to twitter and G+, hugely useful information is still published regularly to blogs. I've shared collections of frontend development feeds twice before. Now I'm back, but with three choices: Download this: frontend-feeds.opml 2013.07.26: Poor Reader. :'( Here are the three below bundles grouped up into an OPML file. Your new news reader can import them in one go. Also, do not forget the most important site that has no feed: webplatformdaily.org. It's the best thing. (2013.09.12: It has a feed now! Added) 2013.09.12: The OPML is now on Github Frontend development exploration, techniques, tips. Lots of JavaScript. 275 feeds. Standards development and browser dev news. 56 feeds. Blogs focusing on building large webapps (new!) 22 feeds. Also, a short commentary on blogging vs tweeting.. while a lot of people have changed to twitter+jsfiddle only, tweets are not available via search after 30 days, so if you expect anything you share to last, blog it for real. :) 2011.12.02: Adding newsletters! 2012.08.09: Refreshed all the bundles. Added the frontend-webapps feed. Also please subscribe to these guys which do a great job of highlighting the top stories of the week: JavaScript Weekly Web Design Weekly HTML5 Weekly 2013.07: Added opml. ## The Fundamentals, Primitives and History of HTML5 DevFeed: [The Fundamentals, Primitives and History of HTML5]() Original publisher: [Read original article]() Author: Paul Irish Published: 2011-11-21T13:39:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [HTML5](), [Parsing](), [browsers](), [Web platform](), [Front end]() Tags: [browsers](), [examples](), [frontend](), [fundamentals](), [history](), [html](), [html5](), [markup](), [parsing](), [payload](), [platform](), [web-platform]() ### AI overview A talk about the fundamentals, primitives, and history of HTML5, including markup parsing, optional tags, unquoted attributes, and how browsers interpret HTML according to defined rules and specifications. ### Source excerpt Just gave this talk at W3Conf about some of the innerworkings of HTML5. Lots of did-you-know and cool insight into how browsers work. 37 minutes long, The Primitives of the HTML5 Foundation - Slides I do discuss optional start and end tags as well as not quoting your attributes. I concede that these ideas scare the shit out of people. In fact, when I first heard Jens Meiert propose the idea in 2009 my brain rejected it. Still, I think many of the markup parsing curiosities that can be frightening only need to be understood by HTML minifiers. Always leave it up to tools to make your frontend payload smaller; you just want the most comfortable and maintainable authoring environment possible. I shared them in this talk because 1) it can lead to writing more beautiful HTML that is easier to maintain. Leaving off 's is a good example. 2) I just want people to consider browsers less of a black box of uncertainty. There are rules and specs that define behavior, so once understood you can feel confident relying on a consistent behavior. We certainly don't have that consistency across all the web platform, but for these examples you do. In summary, I'm not advocating you write more spartan markup if you don't want to. But if it makes you feel good, by all means, go at it; you know now how the browsers work. ps. the monkey HTML shirt I wore is from a store in tokyo; solo location. but they also sell on this delightfully overwhelming site ## Semantics in practice and mapping semantic value to its consumers DevFeed: [Semantics in practice and mapping semantic value to its consumers]() Original publisher: [Read original article]() Author: Paul Irish Published: 2011-11-14T18:25:00Z Content type: article Language: en Sources: [Paul Irish]() Topics: [Accessibility](), [HTML5 and CSS3 tricks](), [aria](), [HTML](), [web-standards]() Tags: [accessibility](), [aria](), [browsers](), [html](), [html-elements](), [html5](), [implementation]() ### AI overview The article argues that practical accessibility should take priority over intricate or unstable HTML semantics. It discusses HTML5 elements, document outlining, heading structure, screen reader behavior, ARIA, browser implementation, and assistive technology accessibility APIs. ### Source excerpt Divya Manian kicked off a good bout of discussion of HTML semantics with her post Our pointless pursuit of semantic value. It called into question the amount of time we spend on identifying the Right and Best ways of marking up our content while highlighting details of some of the consumers of semantics like assistive technology (AT). Jeremy Keith responded in Pursing Semantic Value. I wanted to chime in on Jeremy's post so, I've published below my comment from the original post: Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors. Jeremy's gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1's depending on section nesting. Recent browsers do indeed style the h1's different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1's all as top level headlines or a mishmash of heading nesting levels that don't match any expected behavior (As an aside, this is completely unrelated but if anyone's curious what CSS it takes to make that new h1 styling work across browsers... feast your eyes on this beauty) Additionally,
is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke's comment digs in deeper to the messy semantic state of the outlining algorithm. semantics are hard...let's go shopping and CREATE EPIC SHIT... -- patrick h. lauke (@patrick_h_lauke) November 14, 2011 The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn'