How to Write CSS That Works in Every Browser, Even the Old Ones | Hacker News Reader

How to Write CSS That Works in Every Browser, Even the Old Ones

hacks.mozilla.org

287 pointsausjke100 comments

It would be very appreciated if anybody who can afford to take the time watching all of these videos would like to extract the key information into a synopsis and maybe a cheat sheet or at least a list of URLs.

You can skip the first one, that is a verbose introduction that starts with CERN web history. Key message: "build for all deviecs". No more valuable info, unfortunately, and I have to spend time now on other things.

I am sure 10 minutes reading an article I would have been able to extract some more.

Advice to video tutorial makers: please value your viewers time most, make this a very high priority in your production workflow. Think twice about every sentence you write into the playbook and after one or two days write the sentences again with a target of 50% time reduction. Absolutely never just talk ten minutes something that just comes into your mind - this will just waste the viewers time. Tutorials are not for time wasting. Keep the information very precise and to the point. Always provide at least a cheat sheet of key info. Thanks!

Could not agree with this more. This is why I hate videos without a transcript or textual summary.

I think video in general is not well suited: skim, skim, skim, read that one section 3 times, skim, skip back to that section at the start to re-read, skim, .... is a lot easier to do on text than video. At least for me anyway.

I feed videos are better as you are forced to listen to the whole thing and that helps you get the complete picture. While reading the text, if we find something that is easy to grasp, our mind goes into auto-pilot mode and skips a lot of content.

I think I am the almost exact opposite of that. If I have a video on I'll be more likely to find a shiny pen of something else to do, do that while the video is plodding on in the background and come back to the video having learned nothing

While reading text it's pretty hard to be doing something else at the same time

There's also the factor of when I'm reading I read at my speed in my voice. I'm not distracted by a particularly nasally voice[0] or a slow talker rambling on

[0] Not saying the videos here are that, it's just one of those voice types that I remember being different enough to become distracted

I agree, another aspect to this is that you are forced to absorb the information at a fixed rate. You can read as fast or as slow as you want, but a video will throw the information at you at the authors own pace. This either leads to frustration or information overload.

Final edit: I skimmed all videos (the content was fluffy) and got the following links and lessons out of it. Don't consider them to be the best notes, but I feel most of this is pretty self-explanatory. Personally, I was hoping for some more technical content, but at the same time if I want to quickly hack and get the job done, then this knowledge will help.

Tip: if you want to quickly see the Video headings CTRL + F or CMD + F and type in Video so that you can highlight it. I don't know how to make proper headers on HN.

Video 2

The whole theme of video 2 is: what can I get away with?

caniuse.com

statcounter.com (caniuse.com uses it as a data source)

Use GA to see what you can get away with

chromestatus.com

developer.microsoft.com/en-us/microsoft-edge/platform/status

platform-status.mozilla.org

bugzilla.mozilla.org

Edit video 3:

What happens when a feature isn't supported and you use it?

It strikes it through. / It ignores it.

It's okay that websites don't look identical in every browser. In fact, they never ever do.

CSS is not like JS where it breaks / generates an error. It just ignores stuff it doesn't know.

shape-outside circle example: it works when it works. It is a square if it doesn't work. Users won't necessarily know that it is different.

shape-outside polygon example: it works with supported browsers and is a square when it doesn't work.

CSS Error handling: it just ignores stuff

Edit video 4:

Counting on how CSS handles is enough. Other times it is not quite enough. You want to make adjustment for browsers that do not support many things. CSS Overrides help.

Basic example: the header is the height of the viewport.

header { display: flex; height: 100vh; }

h1 { margin: auto; }

What happens in browsers that do not support display flex? The functionality gets lost. Client in said example says it wants a bigger height for older browsers.

Solution: header { display: flex; height: 500px; height: 100vh; }

h1 { margin: auto; }

caniuse viewport units caniuse flexbox

Browser supports viewport units but not flexbox. We want the headline in the middle Solution: header { display: flex; height: 500px; height: 100vh; }

h1 { padding: 2em 0; /* cannot use margin since the next line overwrites margin / margin: auto; }

Check 5:30 for all the different output examples

Firefox inspector: play with CSS.

Edit video 5: feature queries

caniuse initial-letter? Not really, only in Safari

p::first-letter { color: rgba(255, 255, 255, 0,9); font-weight: bold; margin-right: 0.5em;

  -webkit-initial-letter: 4;
  initial-letter: 4;

}
Initial-letter makes a giant initial letter.
Feature queries look like this:
@supports (initial-letter: 4) or (-webkit-initial-letter: 4) { p::first-letter { color: rgba(255, 255, 255, 0,9); font-weight: bold; margin-right: 0.5em;
-webkit-initial-letter: 4; initial-letter: 4; }
}
This means that browsers that do not support it, won't show it.
Example of grid and how feature queries help when grid isn't applied.
Code is on 7:15. It is too big to write.
8:30 is more in-depth on the syntax of @supports
There is also one bad idea to use @supports and this is: @support not
Edit video 6: feature queries advanced info
Every version of IE does not know what a feature query is. Safari also did not know it for a long time.
What they do is: they block the whole code.
There are 4 combinations:
(1) browsers that support feature queries && do understand the specific feature
(2) browsers that support feature queries && do not understand the specific feature
(3) browsers that do not support feature queries && do understand the specific feature
(4) browsers that do not support feature queries && do not understand the specific feature
We do not want (3).
Example

@supports (display: flex){ / code */ }

When using feature query know that you ignore Internet Explorer and Safari.

With older properties you might not want to use feature queries (e.g. flexbox), but for new feature queries you may want to.

Edit video 7: what happens when the browser doesn't understand the CSS?

Ask yourself: how well does a particular feature fail?

Maybe you don't want to use the property at all because it fails horribly.

Example:

h1 { writing-mode: sideways-lr; }

caniuse writing-mode? yes 94%

Yet in most browsers sideways-lr doesn't work in most browsers!

Why does caniuse lie to us?!

caniuse represents the level 3 specification of writing-mode, but she is using level 4!

go to the MDN network to checkout support

One solution to this problem is to ignore the feature and create the same output like so:

h1{ writing-mode: vertical-rl; transform: rotate(180deg); text-align: right; text-orientation: sideways; }

...you the real MVP.

Good on you dear Sir!

A BIG and humble THANK YOU! I wish you a beautiful weekend!

The Video Speed Controller browser plugin changed my life. With the key bindings you can dynamically adjust the speed to the complexity of the content and always be watching at exactly the rate you can process it.

I’ve used YouTube dl and vlc for this but sounds good as well.

I've been using this plugin for the longest time, I rebinded my keys to

[ speeddown

] speedup

v display speed settings

Speeds of 4x has audio cutoff, 16x is max playback speed

Also, enable captions on video helps out a lot when speeding through a video, in the event you misheard something at faster playbacks

I started writing CSS at around the them when you were still asked to write Hacks for IE5/5.5/6 -- and it was truly horrific -- but it made a lot of sense when you looked at the market shares.

Yes, please be good and build accessible websites, just because its actually not hard to do on a rudimentary level and your probably sucks if you don't anyway.

But actually working on CSS compatibility is such a waste of time considering how "good enough" all of the widely available options are. Yeah, you probably do not want to use the latest in web tech if you are doing a reasonably sized web project that loses actual money for every % of users that can not use the app/site. So what? Just don't. Unless it's a vanity project pick a reasonable cut off point, go with it for that project (or that iteration of the product) and then you reevaluate for the next one.

You can obviously use auto prefixer and the sorts to widen the margin -- everything you can automate, you don't have to think about, by all means, go for it. But the mental overhead you are creating by doing shit like "height: 500px; height: 100vw;" is insanity in a reasonably large project with multiple developers. I forbid you to do it.

By the time the next project comes, you can probably already set the cut off somewhere else. People are actually (being forced to) update their computer, and really enjoy throwing out their mobile devices every other year (thanks apple, I guess). I gladly reap those benefits.

"min-height: 500px; height: 100vw;"

min-height didn’t work in IE6, you had to use height instead.

I think they're commenting on setting height to VW instead of VH.

  >  "height: 500px; height: 100vw;" is insanity in a
  > reasonably large project with multiple developers.
  > I forbid you to do it.

What have happened to us? Too many post on HN show this attitude: make it cheaper to develop, don't care about the users. What happen with the "zen of the web"?

For one, I've started with the web around the time CSS was being born—2016. And in your example I see neither insanity nor large overhead, just a robust approach.

"CSS was being born-- 2016." ???

I started doing webdev in 1998 and gently suggest you check your notes.

He's basically saying don't build hacks because it's not worth the the extra maintenance costs. Justifying your time is one of the most important software engineering principles.

1. CSS and HTML are extremely resilient, they ignore your typos and unsupported features gracefully and never crash, so just daring to use them in your code, no need for exception handling comparing to JS, in that sense, if you can do it in CSS, avoid JS.

2. Leverage CSS override

3. Use browser devtools to test all browsers. No need install all older browser to check CSS. icanuse helps greatly too.

4. Use feature-queries for CSS.

These indeed can make your CSS code work for both the stone age and hottest browsers, all at the same time, without much hacking. Great videos.

Great link and thanks for the tldr!

The first point sorta sets you up for disaster, though. If you do it in css and it works in the browser you are testing, but not in an older one you support. Heaven help you if the person fixing the older browser doesn't take into account the interaction between the working css and the js they use to get it working in the older browser.

> they ignore your typos and unsupported features gracefully

I wish there was a browser version that would handle these errors loudly rather than silently. The fact that React does some of this is rather nice.

That was one of the goals of XHTML....

I find it quite baffling that we have gone to such lengths to make html/css resilient. I know of no other language/format that does this.

Can you, for example, make a half broken PDF and would it still render?

The ones doing the implementing are the browser vendors and it's a competitive disadvantage for them to not render every site on the web as best as they can. Consumers who come across a broken site will blame the browser and switch to a different one.

Haven't thought of that. It does make sense, the incentives are all wrong thinking about it. Publishers want the sites to be made quickly, browser vendors need market share and users have no patience and very low bar for acceptance.

At a previous job, a colleague was working on PDF parsing and rendering; he told me that Acrobat Reader will successfully load and display terrifyingly broken PDFs, and it's far more resilient than any of the open-source PDF-rendering tools.

So yeah, I bet you can.

Php gets away with making many things warnings instead of errors. So it seems to have been made with the same mentality as html and css.

Yes. Adobe in particular will accept a ton of crap

Browsers log CSS and JS errors. There was an Old-Firefox extension giving you error counts in the menu bar.

I have had my fun supporting Mosaic(which is basically the oldest browser that has available source) on my personal sites. You can even still run it on Ubuntu[1]. If you go back that far you can't really use much CSS though. Google's site actually works on Mosaic which is awesome.

[1]: https://github.com/alandipert/ncsa-mosaic

"your time machine is fueled up and ready to go"

lynx should also be available in every modern distribution. If the text shows up in lynx in any reasonable order, chances are that all the screen readers and other strange tools gets it right too.

IIRC my Kubuntu has 'links' (maybe really links2) but not 'lynx' and no simlink?

I'd think older browsers like Mosaic have problems with SSL/TLS, especially now that most web servers no longer support older (compromised) versions of those protocols and SNI (server name indication, allowing web servers to serve multiple domains over SSL from the same IP) wasn't a thing back in the days.

I certainly remember taking a really old version of IE (2 or 3 I think?) for a spin and running into problems because it didn't support SNI.

A lot of older browsers, like elinks or something, actually fork the process to call OpenSSL directly. So long as you update the OpenSSL library, the browser can make use of modern standards.

IE didn't support SNI until IE7 and that was only if it was running on Vista, not XP. IE8-10 don't support TLS 1.1 or 1.2 by default.

https://caniuse.com/#search=sni

https://caniuse.com/#feat=tls

I never stopped. For that matter I never stopped writing javascript the same way. Using let instead of var still breaks a few browsers. I want to move to modern javascript without the babel requirement some older browsers are not ready yet. I would like to but prefer no production bugs.

Which browsers does let break?

safari and older ie versions. 10 for sure.

Remember when console.log broke ie? Debugging was fun.

It was terrible when the only thing you could do was alert your variables!

Back in the day I used LiveConnect[1] for this and other purposes[2]. I would dump errors to an IRC server so that I could collect the results. I could also respond with code that would be eval'd making development very easy.

[1]: https://developer.mozilla.org/en-US/docs/Archive/Web/LiveCon...

[2]: http://geocar.sdf1.org/ajaj.html

> I could also respond with code that would be eval'd making development very easy

In dev only, I hope?! I honestly love the idea as a super fun hack, but the security implications for prod are terrifying.

Not sure there was much risk: The web application used a private IRC server with name+password registered users. L3 support who /msg'd a user session some JavaScript doesn't seem likely as the messages were all logged, and anyone with fileserver access could just put whatever they want in the <script> tag anyway...

Remember when console.log was available when the dev tools were open but would be undefined otherwise, so your code would break unexpectedly but then work fine when you tried to figure out what went wrong?

Oh gaahd, It's all coming back to me now. function log(msg) { if (console.log) console.log(msg) }

It doesn’t break Safari.

version 9 and below it breaks

> safari and older ie versions. 10 for sure.

This is false information about Safari. In fact, Safari was the first browser to implement 100% ES2015 support.

https://developer.apple.com/safari/technology-preview/releas...

> Using let instead of var still breaks a few browsers. I want to move to modern javascript without the babel requirement

It seems unreasonable to me to expect to run new language features on old runtimes, do you have a good reason to not use Babel and move on? I've been writing ES6 (with Babel) from > 2 years now and have never regretted the move.

I think they mean they use var instead of let as var is fully supported by all JavaScript capable browsers.

And I think allover’s point was that doesn’t matter if you use Babel to transpile back to ES5. Personally, I would never go back now that I’ve been writing ES6 in production for almost two years

ES5 doesn't cover all browsers, which is again I believe OP's point.

https://babeljs.io/docs/usage/caveats/

No, but as your link mentions you can add a polyfill to cover those gaps instead of letting IE9 dictate what you can and can't do.

Not using tooling also means no module system and no dependency management. Which likely also means no unit tests. And no minification. No linting or type checking. No third party code except maybe a few bundles you downloaded once and will never update that barf all over the global scope.

I get the appeal of partying like it's 1999 but as someone who used JS in the 1990s these are things I would not want to live without. I'm perfectly capable of writing ES3 code without any tooling but I'd rather not.

Indeed. We have to now think of JS dev for the web as something like a Universal build and dispense with trying to code for the oldest version.

I know JS is JIT, but with tools like Babel and webpack and sourcemapping, that doesn’t mean we have to write the same code that’s executed. New code is so much more resilient. Remember: this is what we evolved to.

I don't have time to watch all these now, but I just want to say how awesome Jen Simmons is and how great it is that Mozilla employs her to make stuff like this, and evangelize things like the CSS grid. Kudos!

I remember the ie6 era very well, and got hired by an agency exclusively for my CSS-fu.

The boss became kind of `jealous` of my skill and the praises i got for it, and would complain that the website did not look perfect on every browser, sending me screenshots of broken sites on his computer.

I spent about 2 months making sure they looked pristine on ALL browsers on ALL platforms, even installing Mandrake Linux and RedHat 7.20 (iirc) just to test them.

No dice, sites still malfunctioning on the boss' pc, who was really happy I couldn't make perfect sites. The more i got obsessed with it the worse the sites would look on his ie6 browser.

After yet another smug comment from him I stormed his office in a rage fueled raid and i ran to his pc shouting that this is IMPOSSIBLE, grabbed his mouse and clicked on the "?" menu and About.

He was using some obscure chinese aternative modded version of ie6 (iirc UC Browser), probably installed just to complicate my life.

tl;dr: vaffanculo, Marco.

This sucks so much !

What a waste of time and resources, hiding knowledge in video is the among most inconvenient and inefficient way of making it useful: no indexing, ni skimming, no copy pasting, it's slow, cannot be searched, cannot be put in a translator, cannot be mirrord, uses much more resources.

Then it's hosted on youtube which is the worst offender privacy wise and does not work without allowing script from a few different domains.

Once again mozilla fails to deliver according to their supposed values which are mostly marketing.

Why do I have to relinquish my privacy to endure an inconvenient and inefficient way to learn when it could have been written in the very same page with text which will survive time and can be easily mirrored. Why put such an unecessary wall between knowledge and audience ?

No one owes you anything. If someone chooses to make something it's entirely up to them how and where they do it. If your personal choices mean you can't benefit from it then that's unfortunate but it definitely isn't grounds for the sort of tirade you've posted here. Everything in this video is available elsewhere.

This is pretty much all information Jen has already written in articles. If you don't like videos, don't watch them, maybe even downvote their submission to HN.

When you think about it, all those talks at the conference is such a waste of time and resources: No indexing, no skimming,no copy pasting, it's slow, cannot be searched.

On the serious note: this is not some unique knowledge that is available in those videos. Much of this stuff was there for years, everywhere. Those who enjoy listening to Jen talking will watch the videos. Others do not have to.

The battle now is native vs web apps...old browsers are already a tiny niche...and pretty much a waste of time considering that most clients are using evergreen browsers anyway. Unless you are ORACLE, SAP or IBM I don't this it's worth it to support anchient browsers.

While I am generally in agreement, that is most applicable to B2C.

B2B, it shocks me how often we run into old-browser problems. IE8 is the biggest one I encounter day-to-day. Sure, it's been EOL for 2 years, and was released almost a decade ago, but... it still lives on within organizations that we have to support.

That's depressing. I guess it's much better to package into an Electron app and release native. For those Electron haters, before bashing me remember the b2b guys are releasing their stuff in JVM wrapped native binaries which runs into GBs of both disk and ram and many are slower than VSCode..

I remember vividly when I could finally start targeting IE8 in 2013, after internal IT phased out IE 7 support. You could finally go wild and add a comma after the last element of your array/object literals.

In the second video it talks about looking at the region of the world you're in / Google analytics to give you a good idea of browser usage.

It's just a shame there isn't 'crappy backwards business/bank' setting to show up the real usage of IE8.

TLDR: Write CSS that still displays a website that makes sense even if it fails. Stop designing websites using CSS for every different browser and device, know they will look different but you can still support users who utilize your site by writing CSS in a structured way.

Quite a bit of negativity on the comments, but can anyone hit me with a concise guide of how it works from the ground up - in text, not a video! I've read some good guides in the past, but don't have them bookmarked.

I expected a joke like Dont write CSS but actually it was an interesting article!

Just deliver the mobile version to very old browsers.

I know that Mozilla is not a single group and actually heterogenous but this talk doesn't ring very true to me when the Firefox add-ons site uses CSS Grid and when it detects you don't have it it shunts you to the mobile site which looks and works terribly (hiding things) on a real desktop computer monitor.

Is it possible that site is redirecting you to the mobile version for other reasons? CSS grid has ~85% support worldwide; current versions of every major desktop browser support it.

(Not doubting your experience, just surprised that it would be because of grid and not some other feature).

I'm sure. There are lots of us that don't use major browsers. I discussed it on IRC with some of the dev's from the Firefox fork I use. It was detecting CSS Grid and if not shunting to the mobile site.

This was about half a year ago.

Maybe you shouldn't use a fork that's lagging behind so much it doesn't support CSS grid?

No. I should. I care about browsing, not about running web apps. Modern browsers are just attempts to re-create the entire OS within a JS engine.

Couldn't the forks host their own mirror of the addons site, or inject their own CSS into the official Mozilla Addons pages?

For people using forks for the old extension system, why use an outdated engine lacking support for new features, instead of using a separate (native application|electron-based application|shell script)?

Indeed that fork does. But due to them respecting the intellectual property of the extension devs they can't just willy nilly copy everything over. They have been contacting authors and trying to do it on a case by case basis for a lot of them.

When your target audience is 'Firefox users', doesn't it make sense to more freely use features that are supported by Firefox?

Firefox is open source. There are lots of Firefox forks. Right now there are more add-ons that work in the Firefox forks then there are add-ons that work in modern Firefox.

I'm going to make a guess that the same goes for exploits.

Not with the amount of new attack surfaces that Mozilla is cramming into Firefox lately.

What do you mean "shunted," redirected to an m. site? The only old browser I have handy at the moment is super-old, Firefox 3.6.27, and it isn't redirected anywhere. The addon site's layout is clearly not as intended but seems readable and usable.

My guess is the addon site is using a strategy a lot of developers are taking, design a narrow mobile experience that doesn't use CSS Grid (because small screens typically have a single column layout anyway and most non-Grid supporting browsers are mobile) but make it fluid to work in larger viewports for any browser that doesn't support CSS Grid. Not every browser has to have the exact same experience, it's something Jen covers in this video series.

BTW, Firefox ESR 52 supports CSS Grid and addons that aren't supported in 57 and later. I think some of the forks are only needed to run unsigned extensions, which sounds like a bad idea.

That's one of the strategies you may choose to deal "what if user's browsers does not support CSS Grid?": start with the mobile layout. Offer advanced layout for the browsers with css grid support, fallback to the mobile version for others.

We need babel for CSS.

PostCSS is what you're looking for: http://postcss.org

I always thought postCSS was just for vendor prefixes. Thanks.

writing for old browsers is irresponsible. The only browsers which should be supported are modern browsers that update themselves by default.

That's naive.

To put it gently.

see my reply above.

It is literally the opposite of naive. This is why people sit back and watch the world burn, because instead of helping us make it better people like you are out there attacking people like me.

I am on the right side of this, and most other fights, but you are killing me. When I am dead I hope you enjoy the hell that you will burn in.

No. I’m not watching 10 videos to learn cross browser css.

These presentations are mostly wasted time. Blah, blah, blah. Get to the goods, already! So, skip to the second one ... where's the "How to..."? In section 3?

Video is usually a huge waste of time, period. The typical reader can take in information something like five times faster that a skilled speaker can talk.

I feel the same way about podcasts.

The good thing about podcasts is that they can still be consumed while your hands or eyes are busy, when reading wouldn't be an option.

I realize some folks are able to focus on work while listening to a podcast, but sadly I’m not one of them. Anything auditory which I need to actively listen to breaks my ability to work (conversely, an IM doesn’t do that, just someone talking). About the only time a podcast would work but reading wouldn’t is while driving, and thankfully I do that rarely.

Reply on news.ycombinator.com