everyone

A Web for Everyone: Interviews with Web Practitioners — Fyrd

In recent posts, we’ve explained why it’s important to make the web work for everyone. We’ve spoken with several top web developers about how they do that. And in between, we’ve shown how browser makers can advance compatibility by adopting living standards. Today we’ll show how a single individual can dramatically improve the tooling space, helping to make the web work for everyone.

In 2015, we asked MDN visitors which tools they use most when working on cross-browser compatibility issues. Three quarters of respondents mentioned good reference materials. 65% of respondents said they use MDN as a cross-browser compatibility reference, and 64% said they use caniuse.com. No other reference sites came close.

Like MDN, caniuse.com is an open-source project with hundreds of contributors. Anyone can fork and PR the caniuse data or adapt it for use in a brand new tool (examples). Building new tools in this space is important and valuable: More than 25% of developers said they want to make their sites more compatible, but they don’t because they need better tools — for example, automation and linting.

Helping web developers is what motivates Alexis Deveria (a.k.a. @Fyrd), the developer behind caniuse.com. Alexis is a web developer at Adobe by day and a champion of cross-browser compatibility by night. He took a break from reading up on the latest browser esoterica to talk with us about compatibility.


Fyrd

What inspired you to build a website devoted to browser compatibility? Was there a specific experience that got it started? What motivates you to keep it going?

I started the site in 2008 because around that time various web browsers started implementing a number of interesting new technologies, especially around HTML5 and CSS3. However, support was sporadic across browsers and there didn’t seem to be a central location to find cross-browser support. So I created a page that listed about 10-15 of such features. As the page slowly became more popular I started adding to it and making it more interactive until little by little it became the full-fledged browser compatibility site you see today.

My motivation to keep it going revolves around a few things, firstly its popularity: so many people visit and rely on it today that it would feel irresponsible to give up on it. It’s also my most successful and longest-running project, something I’m very proud of. Then there’s the fact that it forces me to stay up to date with web tech developments which helps with my day job and finally there’s some ad revenue which always helps.

Caniuse includes Statcounter or Google Analytics stats to help users determine how much of their potential market can use a particular feature. Do you think most developers are basing technical decisions on a market formula like this? What percentage of feature adoption in the market do you think developers are looking for when they decide?

Yeah, I imagine a number of developers take the usage % rate to determine whether or not they can use a feature, though I suspect it’s very much relative to the different factors involved, like what type of feature it is, how important the feature is to have, whether or not it can be polyfilled, etc. My guess would be that most developers don’t just have a specific cut-off percentage for all features, but I haven’t heard one way or the other.

Have you heard from developers that they use Caniuse to help convince their bosses or stakeholders to take a particular technical direction?

I’ve heard of a few of such cases, yes. Which is great of course, especially when they can start using features they’d otherwise be uncertain about using.

What other factors do you think developers should consider — aside from the size of a feature’s potential market — when deciding whether to use a particular feature?

Being on the lookout for partial support and buggy support is important… While in general bugs aren’t blockers, it’s always good to be aware of potential pitfalls. There are also cases where a feature may be deprecated and eventually removed from a browser, particularly for proprietary technologies and features that haven’t received much cross-browser adoption. Thankfully it’s pretty rare for that to happen, but it’s still worth looking out for.

If you could magically make one feature of the web platform 100% compatible across browsers and devices, which would it be?

Wow, just one? If we’re talking just in modern browsers I would go for CSS Grid Layout. Layout’s been one of the biggest paint points in web development and I believe having 100% cross-browser support there would be brilliant. If I could also perform magic on older browsers it would be Flexbox for the same reasons. Thankfully in modern browsers it’s looking quite good already.

Caniuse is an important part of a developer’s toolkit when building cross-browser compatible sites. What other tools or techniques do you think every web dev should consider incorporating to help them build compatible sites?

Using services like BrowserStack or Sauce Labs is incredibly helpful in easily testing on older & mobile browsers, though they require a paid subscription. I’d also recommend becoming familiar with each browser’s own development tools. They’re all good, but it takes some time to understand how to do the same kind of debugging for each browser. Also when using a new technology make sure you do your research beyond Caniuse. Cross-browser support can still come with gotchas, so read MDN, search for blog posts on the subject, etc.

Browser compatibility continues to be one of the biggest challenges in web development — it’s hard! Do you think it’s something a new tool could solve? What would the tool do?

It would be cool if there was a all-rendering-engines-in-one browser where developers could easily switch between them to test their site. In particular this would be useful if it included mobile browsers and older versions… but I can’t see that being anything more than a fantasy, so tools like BrowserStack are likely the closest we’ll get to that.

More ideally, and perhaps more realistically, it would be nice if browser makers would spend more time cooperating on writing tests and ensuring reliable support for technologies so certain types of cross-browser issues wouldn’t occur in the first place.

What would you tell a brand new developer graduating from a coding bootcamp about cross-browser compatibility?

It can get ugly, messy and complicated. Don’t make any assumptions about what will work cross-browser until you’re familiar with it. The good news is that for many basic things cross-browser compatibility is so much better than it used to be. Together with the state of developer tools these days, there’s a lot to be thankful for.


Tips from Alexis’s interview

  • If you see a gap in tooling, you’re probably not the only one. Consider building or contributing to tools that help advance the practice of web development and make the web better for everyone.
  • Don’t assume new features work cross browser. Read about them and experiment with them before committing to use one on a public site.
  • When trying to understand a new web feature, cast a wide net: Look things up on caniuse.com and MDN, and pay attention to other sources (e.g. blogs) too.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

A Web for Everyone: Interviews with Web Practitioners — David Walsh

We’ve heard now from Rachel Andrew, Chris Coyier, and Belén Albeza. Each of these great web developers offered ideas for accomplishing cross-browser compatibility. The fourth interviewee in our web-compatibility interview series brings some new tools to the table.

David Walsh (@davidwalshblog) taught himself HTML, CSS and JavaScript at a young age, and soon turned those skills into a vocation. He started blogging about front-end development after landing his first job in the field. Now, a decade later, David’s blog is daily reading for tens of thousands of web developers who go there for tips, tutorials, and reflections about the life of a developer. David has spoken at JavaScript conferences around the world including LondonAJAX and BrazilJS. He works as a front-end developer and evangelist at Mozilla.


David Walsh

David, what does cross-browser compatibility mean to you?

Cross-browser compatibility means functionality and design working across not only different desktop browsers but also browser apps on different mobile devices, sometimes extending to gaming machines like the Xbox One.

How often do you have to think about cross-browser compatibility? Have you found ways to work that allow you to reduce the amount of time you think about it compared to when you were less experienced?

Working with some bleeding edge APIs at Mozilla, including Service Workers, WebVR, and A-Frame, cross-browser compatibility is something I have to think of often.

Cross-browser compatibility changes meaning but has always been present.

Earlier in my career I would also think of cross-browser compatibility but it was a different environment: IE6 had stalled, user-agent checking was commonplace, and both WebKit/Safari and Firefox were implementing features with their own prefixes, making using new features difficult.

Cross-browser compatibility changes meaning but has always been present.

What motivates you to make the extra effort to build a cross-browser compatible site?

Mozilla properties are visited by millions of users on different browsers, devices, and variant versions of each, meaning that cross-browser compatibility is a must. Also the idea that everyone deserves the same experience if possible.

Everyone deserves the same experience if possible.

Could anything convince you not to make that effort? What?

I suspect that some developers and/or organizations may see cross-browser compatibility as a bloat in time and cost. Luckily, the browsers have come together on the importance of standards and are roughly on the same timeline with features, so unless you’re using bleeding edge capabilities, cross-browser compatibility isn’t as difficult as it used to be.

Have you ever had to convince a client or boss that building a cross-browser compatible site was important? How’d you do it?

Absolutely, especially in the days that I worked at a small agency.  Cross-browser compatibility was seen as a time-consuming task, one that the analytics didn’t justify. I made the case that cross-browser compatibility would “future-proof” sites in case new browsers came along, and I was right: Chrome debuted with a WebKit engine, quickly took hold. Mac users (Safari) were no longer the only users of the WebKit engine and set of style/feature differences.

Did you ever have a specific experience that caused you to take cross-browser compatibility more seriously with your next project?

Yes — the growth of Chrome! Chrome not only used WebKit but then moved to its own engine and started implementing features on its own timeline.  This all seemed to happen fairly quickly and it was very eye-opening to me to see!

You’ve blogged a lot about tools — for example, just this summer you talked about Slimer.js, Phantom.js, and Wraith, among many others. Which tools (or techniques) would be at the top of your list for coding compatible sites or testing for compatibility?

Selenium testing is a great place to start, regardless of which abstraction you use on top of it.  I really liked Slimer.js, Phantom.js, and Wraith, as you’ve mentioned. The truth is new tools are popping up all the time!

What would you tell a brand new developer graduating from a coding bootcamp about cross-browser compatibility?

I would tell them they’re incredibly lucky to have missed the early days of browsers doing their own thing!  They should start with the mindset that cross-browser compatibility (outside of bleeding edge features) is a must, and that if they start with that attitude, they’d always have it.


Tips from David’s interview

  • Don’t overestimate the difficulty of making a site compatible across browsers. Cross-browser compatibility isn’t as hard as it used to be.
  • Try automating parts of your browser testing using command-line tools like Slimer.js, Phantom.js, and Wraith.
  • Functional testing with Selenium — using multiple browsers, of course — can make it easier to discover browser-breaking bugs in new code.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

A Web for Everyone: Interviews with Web Practitioners — Belén Albeza

For the third interview in our cross-browser compatibility series we talk with Belén Albeza (@ladybenko). Belén is an engineer and a game developer who works on developer relations at Mozilla. She is the author of several books about web development, including “Power-up Your Front-End Development with Grunt” and “XHTML + CSS ¡de una maldita vez!” She is a frequent speaker at conferences on topics such as game development, Web APIs and more. Next week she’ll speak at View Source 2016 in Berlin! She also contributes often to Mozilla Hacks.

We’ve heard from two great web developers so far about how (and why) they integrate web compatibility into their workflows. Two weeks ago, Rachel Andrew said, “I’ve always worked from the assumption that the web is for everyone.” Last week, Chris Coyier said he is motivated to make cross-browser compatible sites by a simple economic reality: “People pay for websites that work for them.”

What motivates Belén to make the web work for everyone? Read on to find out.


Belén Albeza

Belén, what does cross-browser compatibility mean to you?

It means having a website or a web app that is functional – not necessarily identical – across different browsers.

How often do you have to think about cross-browser compatibility? Have you found ways to work that allow you to reduce the amount of time you think about it compared to when you were less experienced?

You always have to think about that. It is hard, however, since it’s natural to do 90% of the development under the same system. The only shortcut to this is to use web standards, so you know that your code will have a good chance of working in other browsers and systems, but you still never know for sure until someone tries it in a real browser, on a real device.

The only shortcut is to use web standards, so you know that your code will have a good chance of working in other browsers.

What motivates you to make the extra effort to build a cross-browser compatible site?

From my point of view, cross-browser compatibility is not a nice bonus to have: it is a must. You just cannot afford to have your product not work in one of the major browsers (or OSes). So I don’t see it as “extra effort”, I see it as “mandatory effort”.

Could anything convince you not to make that effort? What?

Cross-browser compatibility is not a binary switch in which you either have it or not – it is a spectrum. I consider it mandatory to have the product work under major browsers (Chrome, Firefox, Edge, Safari, Android Browser) and in major OSes (Windows, Mac, iOS, Android). Beyond that, unless it is a client requirement – like legacy support for older systems/browsers – I think that making sure that your code complies with Web Standards is a good sanity point. Most of the time you don’t have the resources to test in every browser, on every system, on every device.

There is also the issue of needing a particular feature that is core to your product, for instance, WebRTC, Websockets, or Web Audio. In this case, you are making a conscious decision or leaving out browsers with no implementation or a partial one.

Have you ever had to convince a client or boss that building a cross-browser compatible site was important? How’d you do it?

My experience so far has been usually the opposite: clients or product owners wanting to support as many browsers and systems as possible! I have had to convince them to ditch support for obsolete browsers so our code base could be more modern and smaller.

Did you ever have a specific experience that caused you to take cross-browser compatibility more seriously with your next project?

In one of my previous jobs we were developing a web app and we used both Firefox and Chrome for development. But these were the regular versions of the browsers. We built a release candidate of our app and patted ourselves on the back… just to find out the next day that the QA team had found a really nasty bug in our web app! How that could be?

Well, it turned out that the day after we submitted the release candidate for QA, a new version of a browser was released, and it fixed a bug that we had a workaround for. And this workaround – which was no longer necessary – was causing a bug! From that day on, we added the nightly builds of Chrome and Firefox to our development stack of tools, so we knew what to expect in the future!

You’re speaking this September at View Source in Berlin. Your session is called, “You might not need a CSS framework.” Do you think frameworks make cross-browser compatibility better or worse? Does any framework stand out as particularly good for compatibility?

I think that framework creators have a huge responsibility with respect to cross-browser compatibility. If a framework only supports a subset of major browsers, and somehow it manages to become extremely popular… the Web would be doomed. My recommendation, in general, is to avoid the use of third-party frameworks except in very specific circumstances (like developing a prototype).

You’ve done quite a bit of work with HTML5 games. What special compatibility challenges do HTML5 game developers face? Do you use a different set of tools for preventing/debugging compatibility issues in HTML5 games?

It is challenging in many ways: performance varies across browsers, across devices… There are also some quirks you need to be aware of: for instance, different browsers support different formats for audio files, some mobile browsers require a user interaction to be able to play sounds, etc. But you have similar issues when creating native games, because not all devices are equal, do not perform the same and have different hardware capabilities!

When working on a commercial game there is usually a QA stage where the game is tested on different devices and OSes – you would “just” need to add different browsers as well. Now that I make games on my own, I pick a game framework which is known for good cross-browser compatibility (Phaser) and test the game on the handful of devices I have at home.

What would you tell a brand new developer graduating from a coding bootcamp about cross-browser compatibility?

This is not an option, it is a must. You cannot afford to lose 50%, 40% or 30% of your potential audience. You have to care! And caniuse.com works wonders 😉

You cannot afford to lose 50%, 40% or 30% of your potential audience. You have to care!


Tips from Belén’s interview

  • Cross-browser compatibility does not mean making things look identical in every browser — it just means making them usable for everyone.
  • The only shortcut for building a cross-browser compatible website is to stick to standards.
  • Remember to test your site or application on the nightly versions of browsers, which include features soon to land in release channels.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

A Web for Everyone: Interviews with Web Practitioners — Chris Coyier

This is the second in a series of interviews about web compatibility with web practitioners. This week we caught up with Chris Coyier (@chriscoyier), prolific web developer and writer behind CSS-Tricks, Digging Into WordPress, and the ShopTalk Show. Chris is one of the founders of the code-snippet demo site CodePen. He recently published a book about SVG. And now he’s here to talk about web compatibility.

These interviews follow up on our recent article, “Make the Web Work for Everyone,” urging developers to build cross-browser compatible web experiences in order to maximize exposure and market size; prevent interface bugs that drive users away forever; and demonstrate professional mastery.

In our first interview, Rachel Andrew said making a website work across browsers is part of doing her job well; she said it can even be “fun and liberating” to use new browser features without breaking the web. Let’s see if Chris Coyier agrees.


 

Chris Coyier

What does cross-browser compatibility mean to you, Chris?

I think the term itself is pretty clear: Make stuff work in many different browsers. What those browsers are is certainly different from team to team. Even people whose goal is extreme cross-browser compatibility have limits. Not a lot of people worrying about Netscape Navigator these days.

How often do you have to think about cross-browser compatibility?

I think about it less and less over time I think, but that’s not due to my skill in fixing cross browser issues increasing, its more that browsers are more and more consistent all the time. It’s still pretty easy to waggle fingers at certain inconsistencies, but it would be hard to argue we’re worse off now than we were a few years ago.

Still, I’d say in my life of “actually building stuff” it’s at least a weekly occurrence that some cross-browser consideration needs to happen. And because of working on the content on CSS-Tricks, it’s almost a daily consideration. On a reference site, it’s poor form to talk about browser features without mentioning support.

Last summer, Geoff Graham wrote on CSS Tricks that, “It’s rather expected of us that we know how to build websites that can work cross-browser.” Do you think employers and the market really demand this knowledge from developers? Do they expect it of junior devs, or is it more of a senior-level skill?

Front-end web development is a job. Knowing about, testing for, and fixing cross browser issues is part of that job. I’m not sure I would expect a junior dev to be super skillful at dealing with cross-browser issues out of the gate, but I would expect them to be open to learning about and dealing with those issues. And at levels beyond junior, it would be a pretty big red flag if a front-end dev could or didn’t want to deal with cross-browser issues.

What motivates you to make the extra effort to build a cross-browser compatible site?

Money. People pay for websites that work for them. Here’s a little example: Just last week we were working on some drag-and-drop functionality in a new part of CodePen. Worked great in Chrome, didn’t work in either Firefox or Safari. Tim Holman, one of our front-end devs, had to spend a good part of a day implementing different fixes for both. Good thing we did that before launch, otherwise we surely would have turned some potential customers off.

I don’t feel compelled to fix cross-browser issues because of some holy decree that all experiences be created equal. It comes down to money and customer satisfaction.

Could anything convince you not to make that effort? What?

If the cost-benefit guess is way off. If I guess that fixing a cross-browser issue will take a month of development and help 0.1% of customers, I can do some scratchpad math and probably come up with a decision not to do it. Thankfully most issues aren’t that far off.

Even though I do believe “it’s part of the job,” I would also say that it’s a rare developer that really loves doing that kind of work. I can say for myself, I enjoy the moment of solving the problem and closing the ticket, but the journey there can be demoralizing. I’d be cautious about doling out too much of that work to any one dev.

Have you ever had to convince a client or boss that building a cross-browser compatible site was important? How’d you do it?

It’s usually the other way around. It’s been me making a site only to send it to a client and have it not work the way I thought it would for them. So it’s them schooling me on cross-browser compatibility.

If I had to be part of a “convincing” session, I’d probably approach it as pragmatically as I could. Let’s look at some data and pick a reasonable spread of browsers to support and hit those targets.

Can you think of a particularly vexing or interesting compatibility bug you’ve encountered? On what site/product? Did it go live, or did you catch it before it went live?

One came up for me a few weeks ago. A person wrote in to me telling me that CSS-Tricks was very hard to scroll. I’ve never experienced it before and I was having trouble replicating it. I’m aware that I only have one dev machine and it’s a pretty souped up MacBook Pro, so I wasn’t doubting anything, I just couldn’t replicate it or dig into fixing it.

She sent me videos of the issue, which made it very clear. Chrome was fine. Firefox was fine. It was a special browser she was using called Pale Moon. It’s only for Windows and it’s not available through my normal “test stuff on Windows” tool.

In reading about the browser a little, it talks about how one of its features is optimizing resource usage. I’m sure that’s a great thing in most cases, but it made me think that if somehow CSS-Tricks was asking for more memory than Pale Moon was willing to give it, that might cause the issue. What is painted up and down the entire page? The background! The background on CSS-Tricks is a combination of CSS gradient and SVG. Not particularly memory-light unfortunately. To test, I had her set a user stylesheet to remove the SVG, and it worked great.

I probably won’t change the current design just for Pale Moon, but in a redesign, it will probably push me toward doing something simpler for the background.

Did you ever have a specific experience that caused you to take cross-browser compatibility more seriously with your next project?

I feel like every time I run into a cross browser issue, it pushes me toward doing less and less fancy things. I love experimenting with new stuff, then when it comes to production stuff, my typical thought is, “what’s the most basic tried-and-true way we can pull this off?”

Are there parts of your process / toolchain / etc. that make it easy for you to incorporate or test for compatibility that you would recommend every web dev incorporate into their own?

Modern browser developer tools have gotten pretty good at simulating different viewports, connection speeds, and emulating mobile headers, but what they support feature-wise is pretty baked in. I know I open up my iOS Simulator a lot to get a “true look” at Mobile Safari quite a bit, and the fact that I can use Safari’s developer tools to poke around in there is great.

I really dig how BrowserSync allows me to open a dev site on a local network with any other device, so I use that a good bit.

My main cross-browser testing tool though is CrossBrowserTesting.com. It’s pretty amazing.

What would you tell a brand new developer graduating from a coding bootcamp about cross-browser compatibility?

If your job is front-end development, this stuff is definitely your job. If you roll your eyes at it, it might not be the job for you. There is a certain amount of empathy required in all things web, so if you can’t extend yours to understand that people use different browsers/platforms/version, this does not bode well.


 

Tips from Chris’s interview

  • When debugging a compatibility bug, the first step is to completely understand the browser environment it appears in. What OS? What device? What screen size/orientation? What browser? What version?
  • If in doubt about whether a feature will work for your audience, look for more “tried and true” ways to implement the necessary functionality.
  • Learn to use the advanced features of modern browser developer tools. They can emulate connection speed, screen size, and header differences.

 

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

A Web for Everyone: Interviews with Web Practitioners — Rachel Andrew

A recent article on Mozilla Hacks, “Make the Web Work for Everyone,” explored challenges and opportunities in browser compatibility. In that post we urged developers to build cross-browser compatible web experiences in order to maximize exposure and market size; prevent interface bugs that drive users away forever; and demonstrate professional mastery.

Today we’re kicking off a series of interviews with web developers who have earned widespread admiration for their work on the web. Do these professionals at the top of their field take web compatibility as seriously as we do? Why or why not? And how do they go about achieving it?

We’ll start by talking with Rachel Andrew (@rachelandrew).

Rachel Andrew

Rachel is a founder and managing director of edgeofmyseat.com, the company that builds Perch CMS. She has worked on the web since 1996; in that time she’s authored numerous books about CSS and HTML5. She is a frequent speaker at web development conferences (you can see her talking about CSS layouts at View Source 2016 in Berlin, September 12-14). She blogs at rachelandrew.co.uk.


So Rachel, what does cross-browser compatibility mean to you?

Doing my job properly! That’s it really.

How often do you have to think about cross-browser compatibility? Have you found ways to work that allow you to reduce the amount of time you think about it compared to when you were less experienced?

I think about it a lot less now than I used to. The main core things we want to do work cross-browser in a consistent way. We don’t have wildly buggy behaviour as we had in the past. New developers should go look at positioniseverything.net/explorer.html to see the stuff we used to have to deal with!

Where I do need to think about it is when I am using a new specification, something that isn’t fully implemented perhaps. Or something that hasn’t yet been implemented in all browsers, in that case I need to be sure that my usage of that technique for supporting browsers does not cause a problem for people in a browser that hasn’t got that feature yet.

What motivates you to make the extra effort to build a cross-browser compatible site or product?

I’ve always worked from the assumption that the web is for everyone. I’m also old enough to understand how fast this stuff changes. As far as I can see the absolute best way to ensure that things work well for people now and a year down the line is to get them working in the biggest possible number of browsers and devices today.

Could anything convince you not to make that effort?

Not really, because it is so ingrained into how I work. I also know from experience that when someone says the site only needs to work in a certain browser, look a year down the line and that might change.

Also, in a world of evergreen browsers, working cross-browser can actually mean improving the future experience for the people using the browser with the biggest market share. Here’s an example: position: sticky, enabling sticky headers on tables and navigation has been in Firefox for a good while. It is currently behind a flag in Chrome. Over 50% of my users are in Chrome, however the sticky headers on a table are a nice enhancement so I might use position: sticky to add that little touch for Firefox users who have support.

When Chrome ship their support, suddenly all those users will get that nice enhancement. The site will get better for them without me having to ship any code. So being aware of what is shipping in different browsers means you can take advantage of new stuff and leave these enhancements in your site for other browsers to grow into.

We think of cross-browser being dull grunt work, battling with old browsers and weird bugs. However it can also be pretty fun and liberating, especially right now. There is new stuff shipping all of the time, you miss out if you don’t take a look at who is shipping what.

Can you think of a particularly vexing or interesting compatibility bug you’ve encountered?

Not really, of course I’ve had them. No matter how much testing you do you can be sure that something subtle or not so subtle will happen at some point. What you find is that the more time you have invested into understanding why things work as they do, the more these issues just become a bit annoying rather than giant showstoppers. Actually practicing working cross-browser in non-stressful situations means that when something baffling does occur you have the ability to take a step back and debug it, figure out how that user could possibly be seeing what they are seeing and get it fixed.

Have you ever had to convince a client or boss that building a cross-browser compatible site was important? How’d you do it?

Even back in the days of the browser wars I never mentioned it, I just did it. It’s how we work.

Did you ever have a specific experience that caused you to take cross-browser compatibility more seriously with your next project?

Not really, I’ve been doing this for a long time! However I used to do a lot of troubleshooting of work done by other people. Rather than starting from a baseline of solid experience and enhancing from there, they would have all started with something that only worked in one browser and then tried to retrofit compatibility for the others. Fixing the mess often meant going right back to basics, figuring out the core experience that was needed and then building back up the desired result in those browsers that supported the full experience.

In your post, “Unfashionably Profitable,” you say, “Everything should be possible without JavaScript.” Do you think over-reliance on JavaScript has made the web less cross-browser compatible?

I think that people will often reach for JavaScript earlier in the process than they need to. Even if they are not building the whole thing as a JavaScript application there is a tendency to assume JavaScript is required for all sorts of things that can be achieved without it, or where a baseline experience can be developed without JavaScript to be enhanced later.

I’m not saying “don’t use JavaScript” but the fact is that as soon as you bring JavaScript into the mix you have a whole host of new potential compatibility problems. A development practice that brings these things in one at a time and encourages testing at each stage makes the whole process much much easier.

Are there parts of your process/toolchain/etc. that make it easy for you to incorporate or test for compatibility that you would recommend every web developer incorporate into their own?

I’m pretty old-school when it comes to tools, however I am a big fan of BrowserStack, mostly because I travel a lot and can’t fill that laptop with virtual machines or drag several devices around with me.

What would you tell a brand new developer graduating from a coding bootcamp about cross-browser compatibility?

Everything gets easier if you start by figuring out what the core thing the site or application or feature you are building needs to do. Build that, make sure it works in a few browsers. Then, and only then start to add the bells and whistles. Don’t get everything working in one browser and then a day before launch think, “hmm maybe I should test this in another browser”. That is when cross-browser becomes difficult, when you try and do the retro-fitting.

Start out right and you probably won’t have to think about it too much.


Tips from Rachel’s interview

  • Experiment with upcoming or partially-implemented browser features, but use them only to enhance basic functionality, not to deliver basic functionality.
  • Add new features one at a time and test their compatibility as you go. Don’t wait to test at the end.
  • If you don’t have access to all the machines and devices you need to test on, test in one of the online browser testing tools.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Make the Web Work For Everyone

Millions of websites have compatibility problems on one or more of the major browsers, leading to a poor user experience. The web developer community can fix this.

The web has changed immensely in the past 20 years. In 1996 there were roughly a million websites; now there are more than a billion. Back then there were roughly 50 million internet users; today there are more than 3 billion. We have more content than we ever dreamed was possible. People are enjoying it on 8.1 billion connected devices, including more than 24,000 distinct mobile device types.

Statistics illustrating explosive growth in the number of sites, users, and devices.

This explosive growth in content, devices and users has made cross browser compatibility even more essential than it was in 1996. Stack Overflow has almost 55,000 questions that include the string “cross-browser”, and hundreds of thousands of questions about things that work fine in [Browser X]. Any question about how a particular browser handles a particular site is a potential compatibility question.

Statistics showing the number of questions on Stack Overflow that relate to cross-browser compatibility.

So yeah, cross-browser compatibility is still a thing. It’s a thing we care about at Mozilla, and we think you should care about it too. Why? Well, your users probably aren’t on the same browser as you. They have different abilities and needs than you think. They won’t change browsers if your site breaks for them. Serving them well is one way to demonstrate mastery of your craft. And modern tools make it easier than ever.

What causes cross-browser incompatibilities? It’s complex. Here are some of today’s top culprits:

  • Developers who use browser-specific features (e.g. vendor-specific prefixing) to achieve certain effects without fallbacks or polyfills for other browsers.
  • Browser vendors who rush to implement features developers want before they are standardized.
  • Browser vendors who are slow to implement standards and fix bugs in their browsers.
  • Sites that employ user agent sniffing to serve different content to different browsers.
  • Developers who are over-reliant on a single toolset (which sometimes only reliably supports a single browser) and may miss cross-browser compatibility bugs.
  • Growth in the industry — intense demand has encouraged many new web developers to join the field, which means developers overall are less experienced on average than they were a few years ago.

Statistics suggesting that browser implementations, developer experience, and developer browser choice may affect cross-browser compatibility.

Some of these challenges have been with us since the early days of the web. But since those days, web development has made great progress. Best practices and modern tools can help us build vibrant experiences on every browser.

So, developers, here are a few things to inspire you to make your next web site work for everyone.

More people use that other browser than you think

Many developers believe the browser they use is the only browser that anyone really uses, therefore they should just develop for it. By some measures, 70% of web developers use Chrome on the desktop. But only about 45% of the general population use Chrome across all device types, and only about 57% of the general population use Chrome on the desktop. Building and testing on Chrome alone ignores almost half of global users.

And browser use varies by geography. Chrome, Firefox and IE/Edge are the top browsers in many locales, but the proportion of users on each varies. German users favor Firefox over Chrome. IE is big in Japan. Quite a few Australians choose Safari. More than 1 in 5 Vietnamese users run a fork of Chromium called C?c C?c. Building and testing on just one browser ignores these market differences.

Finally, features present in your browser may not be present in other browsers. Browser vendors implement features on different schedules, so a cool new API in your favorite browser might be missing for a lot of users.

These factors combine in unexpected ways: Choosing an API that isn’t supported in all browsers, testing your site only in one browser, and launching in a market where that browser isn’t dominant could mean excluding substantially more than half of your potential audience. Leaving money on the table. Leaving customers out in the cold. That’s worth making the extra effort to avoid.

Compatibility intersects with accessibility

Building cross-browser compatible web sites means designing and coding for unknown client environments, in order to make content available to the widest possible audience. And that audience undoubtedly includes people with disabilities — probably more than you think. If your web site works in every browser but falls apart in a screen reader, you’re missing a powerful opportunity.

People with disabilities represent a significant market share. For example, in the U.S. alone, there are more visually impaired internet users than all Canadian internet users combined. Modern web features address this audience’s needs; you just have to implement them.

Accessibility techniques don’t just benefit disabled users either — for example:

  • Pages that are more accessible to screen readers are also more accessible to search engine algorithms. Simple accessibility techniques such as using alt-text on images, using descriptive text in links, using CSS for style only (never for meaning), and using HTML5’s semantic tags improve the overall SEO of a page.

  • Transcripts of video content aren’t just good for people with auditory impairments — they are also useful for users on mobile devices in low bandwidth areas that can’t download the video, and people in noisy environments that can’t hear the video. And more text content means more opportunity for relevant keywords, so again, more SEO.

Users won’t switch browsers, they’ll switch sites

You might think that users will switch browsers to use your site. But many won’t or can’t.

Users have no patience for things that don’t work, and they’ll just go to a competitor’s site instead. Failing at a critical point could turn a potential user away forever. According to Akamai,

  • 32% of users who encounter a problem on your site are less likely to make online transactions with your company
  • 35% will have a more negative perception of your company
  • 45% are less likely to visit your web site again
  • And more than 1 in 5 users (22%) will leave for good.

What’s more, many users don’t know how to install a new browser, or even know what a browser is (many users don’t know the difference between a browser, a search engine, and a web site).

And even if users know how to install a new browser, and want to, they might not be able to. Many companies mandate which browsers their employees are allowed to use, and many people use public computers in places like libraries.

For example, Microsoft gave a deadline of Jan. 12, 2016 for users to switch to a newer version of the browser, but in March more than a third of IE users remained on outdated versions that no longer receive security updates. The 2.07% of IE users currently running IE8 are on a browser that Microsoft no longer patches; the same goes for more than three-quarters of the 1.59% on IE9 and for virtually all of the 10.95% who ran IE10 last month.

Broken web experiences drive users away. If half of your users are on a different browser, and you want to keep them, testing it in that browser is essential.

Statistics showing that browser use varies by locale, and that broken web sites drive away users.

Compatibility === Craft

Creating for the web is a skilled discipline, not just a menial task — we all want to take pride in what we do, hone our craft, and demonstrate our mastery of it. This involves:

  • Staying current with the latest technologies, frameworks, and techniques.
  • Testing carefully and implementing cross browser/platform apps including fallbacks for less capable browsers. Is the experience acceptable?
  • Making sure your web content is accessible to people with disabilities.
  • Making sure the general look and user experience of your creations is pleasant and fits in with your/your client’s brand.

So, as a web developer, launched sites are your resumé. A high quality experience is important to your users, your peers and your present and future employers.

But so often, time and business constraints get in the way of such things. You have a hard deadline to hit. Your boss only cares about how the site works on their iPad and hasn’t heard of accessibility. You don’t have time to fix that IE bug in this sprint. We do what we can most of the time, rather than what we’d ideally like to do.

It can be tempting to let cross-browser testing become a corner to be cut when deadlines loom, hoping your chosen framework’s testing will cover you. But your site isn’t purely framework code, and you’re responsible for all of it. Testing to ensure that your code works well across browsers is a corner that you should strongly resist cutting.

Writing code that stands up over time; delivering information to anyone who requests it; creating rich functionality that works for all: These are the noble goals of a great web developer.

Modern tools can help

Now you know a few great reasons to make your web site more compatible. But how do you do it?

  • If you’ve found a bug on someone else’s site, file it at webcompat.com! If you’re debugging your own site, read on.
  • Try your site in different browsers and move through it as a user might. Watch the developer console in the browser’s developer tools for errors (most modern desktop browsers have incredibly capable developer tools built in to help you debug issues, even on mobile):
  • If you find a bug that is not in your site, maybe it’s a bug in the browser! Open a bug report so your browser’s developers can fix it:
  • Integrate a popular cross-browser-testing tool into your deploy process, to make cross-browser testing automatic:
  • Understand which browsers have implemented web features before using them on your site:
    • Caniuse
    • MDN’s compatibility tables
    • Kangax’s ECMAScript compatibility tables
  • Explore coding tools that can improve cross-browser compatibility:
  • Go deep. Learn about the web’s many features and quirks. The more you know about it the more you will love it:

Delivering on the web’s promise

The promise of the web is that anyone can access content using any browser on any device. Woven into this promise are some of humanity’s greatest aspirations — self-determination, freedom, education and discovery. Designing for cross-browser compatibility opens your work up to the largest possible audience and market, advances your mastery of the craft, and is a noble end in itself.

While the modern device and browser landscape presents many challenges, modern tools offer many solutions. More than 3 billion people are out there looking for your site — is it ready for them?

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)