#css grids thank you for my life. and for once flexbox thank you for my life (i only used it on two divs but still)
Explore tagged Tumblr posts
Note
Hi sorry to bother you! I really like your multimuse #2 page theme and want to use it, but is there a way to change the grid so the muse images on the left are smaller and the grid would fit 3 or maybe 4 images instead of just 2? I've been playing around with it, but I just can't get it to work (I've never worked with grid before and I don't quite find what I'm looking for on the internet). Would be very grateful for help but if you cant that's fine too :)
Hi! :)
Of course, I'd be more than happy to help thank you for the kind words! 💖
Looking at the code I really see that I could have made these things easier to customise but you live and you learn :')
So I've made some (very quick and dirty) changes for you to try out (and I'll explain after)
For three smaller images on the left
For four smaller images on the left (though on this one, I would suggest removing the quotes in front of the images altogether because it's too big as it is, you can always make those smaller too :) )
I also realise that I need to update the assets for the icons… sorry about that, I will do that at some point…. just not right now :')
Finally, going under the cut is the explanation of what I did and some resources if you want to explore more the CSS grid :)
Once more, thank you and I hope this helps!
Alright, right off the bat here are some resources that have helped me understand the grid (or, at the very least, have my life doing things with it so much easier)
grid garden: a game where you will be using the properties of the tool to water your garden and make carrots grow!
a complete guide to grid: more confusing and a bit more intense, but really good for a quick visual of what things do
There are situations where you might not want to use the grid (for more reasons than one: no support for your browser, some specific issues that make it harder to work with), so in case if you don't know, there is also flex that is great:
flexbox froggy: a game where you make the frog jump to their lillypad by using flex properties!
a complete guide to flexbox: more intense again, but I think because flex is easier, so is the documentation as well to follow
As to what I did (and keep in mind I didn't spend that much time so if something is funky just..... don't mind me :') )
I'm using the example for the four images but it's the same for the three just with different values. The lines that have a blue square were changed, the green ones were added.
The .muse-selection is where I define how many columns things will have and how big the content (width) within it can be. The thing is, if you change only the width then the image will be funky because the height of the images is too large, so I adjusted the .muse to have a more appropriate height.
Also I had to add align-self: start and grid-template-rows to make sure that the height of the grid doesn't freak out (it should have been something I had when I first shared this page)
In a better world I would have done this automatically so you didn't have to worry about this, but alas.....
In order to keep it responsive (so that if you have a smaller screen it doesn't look broken) I've also updated the media queries to make it look good :)
And there we go ✨
1 note
·
View note
Text
css grid cheat sheet hack 79G!
💾 ►►► DOWNLOAD FILE 🔥🔥🔥🔥🔥 Our comprehensive guide to CSS grid, focusing on all the settings both for the grid parent container and the grid child elements. Today we're going to learn CSS Grid properties so that you can make your own responsive websites. I'll explain how each of Grid's properties. Grid Template Columns. To specify the number of columns of the grid and the widths of each column, the CSS property grid-template-. Hi dev friends! I made this CSS Grid Cheat Sheet that fits on one page. I hope this will help you Tagged with webdev, css, beginners. 9 We're a place where coders share, stay up-to-date and grow their careers. I hope this will help you learn the grid layout. Please let me know what you think of it :. I found one for Bootstrap frontendcheatsheets. I highly doubt any cheatsheet exists for TailwindCSS - simply because of the sheer amount of combinations conceivable. Bootstrap has several ways to generate a "card" but for TailwindCSS, I could come up with at least a hundred!!! Thanks for your effort. I'm still using flexbox and this guide can help me to kickstart use grid functionality. It should be mentioned that justify and align also works with flex and css text columns. So I'm about to start on a project and thinking of the layout- I open my dev. I'll be using it, well done! Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Shahed Nasser - Oct 3. Shubham Dutta - Sep Viktoria Bors-Pajuste - Sep Helitha Rupasinghe - Sep Once suspended, simonpaix will not be able to comment or publish posts until their suspension is removed. Once unpublished, all posts by simonpaix will become hidden and only accessible to themselves. If simonpaix is not suspended, they can still re-publish their posts from their dashboard. Once unpublished, this post will become invisible to the public and only accessible to Mariana Simon. Here is what you can do to flag simonpaix:. Create account Log in. Twitter Facebook Github Instagram Twitch. Hi dev friends! Submit Preview Dismiss. Jul 16, Dropdown menu Copy link Hide. Sep 17, Mar 15, On a mission to make online learning less boring. Coding live on LearnPine. Elena Elena Elena. Jul 13, Ifeoma Ifeoma Ifeoma. Software Engineer. Sometimes Code Sometimes Write, On a journey to live a better life. Aug 16, Dec 11, Oct 24, Apr 21, Hide child comments as well Confirm. Turn it on in Settings. Setting up Nodemailer with Gmail after May Viktoria Bors-Pajuste - Sep When have you used reengineering? Once unsuspended, simonpaix will be able to comment and publish posts again. Unpublish all posts. They can still re-publish the post if they are not suspended. Unpublish post. Report other inappropriate conduct. Confirm Flag. Unflagging simonpaix will restore default visibility to their posts. Confirm Unflag. Log in Create account.
1 note
·
View note
Text
css grid cheat sheet trainer JZ46#
💾 ►►► DOWNLOAD FILE 🔥🔥🔥🔥🔥 Our comprehensive guide to CSS grid, focusing on all the settings both for the grid parent container and the grid child elements. Today we're going to learn CSS Grid properties so that you can make your own responsive websites. I'll explain how each of Grid's properties. Grid Template Columns. To specify the number of columns of the grid and the widths of each column, the CSS property grid-template-. Hi dev friends! I made this CSS Grid Cheat Sheet that fits on one page. I hope this will help you Tagged with webdev, css, beginners. 9 We're a place where coders share, stay up-to-date and grow their careers. I hope this will help you learn the grid layout. Please let me know what you think of it :. I found one for Bootstrap frontendcheatsheets. I highly doubt any cheatsheet exists for TailwindCSS - simply because of the sheer amount of combinations conceivable. Bootstrap has several ways to generate a "card" but for TailwindCSS, I could come up with at least a hundred!!! Thanks for your effort. I'm still using flexbox and this guide can help me to kickstart use grid functionality. It should be mentioned that justify and align also works with flex and css text columns. So I'm about to start on a project and thinking of the layout- I open my dev. I'll be using it, well done! Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Shahed Nasser - Oct 3. Shubham Dutta - Sep Viktoria Bors-Pajuste - Sep Helitha Rupasinghe - Sep Once suspended, simonpaix will not be able to comment or publish posts until their suspension is removed. Once unpublished, all posts by simonpaix will become hidden and only accessible to themselves. If simonpaix is not suspended, they can still re-publish their posts from their dashboard. Once unpublished, this post will become invisible to the public and only accessible to Mariana Simon. Here is what you can do to flag simonpaix:. Create account Log in. Twitter Facebook Github Instagram Twitch. Hi dev friends! Submit Preview Dismiss. Jul 16, Dropdown menu Copy link Hide. Sep 17, Mar 15, On a mission to make online learning less boring. Coding live on LearnPine. Elena Elena Elena. Jul 13, Ifeoma Ifeoma Ifeoma. Software Engineer. Sometimes Code Sometimes Write, On a journey to live a better life. Aug 16, Dec 11, Oct 24, Apr 21, Hide child comments as well Confirm. Turn it on in Settings. Setting up Nodemailer with Gmail after May Viktoria Bors-Pajuste - Sep When have you used reengineering? Once unsuspended, simonpaix will be able to comment and publish posts again. Unpublish all posts. They can still re-publish the post if they are not suspended. Unpublish post. Report other inappropriate conduct. Confirm Flag. Unflagging simonpaix will restore default visibility to their posts. Confirm Unflag. Log in Create account.
1 note
·
View note
Text
css grid cheat sheet working JN1#
💾 ►►► DOWNLOAD FILE 🔥🔥🔥🔥🔥 Our comprehensive guide to CSS grid, focusing on all the settings both for the grid parent container and the grid child elements. Today we're going to learn CSS Grid properties so that you can make your own responsive websites. I'll explain how each of Grid's properties. Grid Template Columns. To specify the number of columns of the grid and the widths of each column, the CSS property grid-template-. Hi dev friends! I made this CSS Grid Cheat Sheet that fits on one page. I hope this will help you Tagged with webdev, css, beginners. 9 We're a place where coders share, stay up-to-date and grow their careers. I hope this will help you learn the grid layout. Please let me know what you think of it :. I found one for Bootstrap frontendcheatsheets. I highly doubt any cheatsheet exists for TailwindCSS - simply because of the sheer amount of combinations conceivable. Bootstrap has several ways to generate a "card" but for TailwindCSS, I could come up with at least a hundred!!! Thanks for your effort. I'm still using flexbox and this guide can help me to kickstart use grid functionality. It should be mentioned that justify and align also works with flex and css text columns. So I'm about to start on a project and thinking of the layout- I open my dev. I'll be using it, well done! Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Shahed Nasser - Oct 3. Shubham Dutta - Sep Viktoria Bors-Pajuste - Sep Helitha Rupasinghe - Sep Once suspended, simonpaix will not be able to comment or publish posts until their suspension is removed. Once unpublished, all posts by simonpaix will become hidden and only accessible to themselves. If simonpaix is not suspended, they can still re-publish their posts from their dashboard. Once unpublished, this post will become invisible to the public and only accessible to Mariana Simon. Here is what you can do to flag simonpaix:. Create account Log in. Twitter Facebook Github Instagram Twitch. Hi dev friends! Submit Preview Dismiss. Jul 16, Dropdown menu Copy link Hide. Sep 17, Mar 15, On a mission to make online learning less boring. Coding live on LearnPine. Elena Elena Elena. Jul 13, Ifeoma Ifeoma Ifeoma. Software Engineer. Sometimes Code Sometimes Write, On a journey to live a better life. Aug 16, Dec 11, Oct 24, Apr 21, Hide child comments as well Confirm. Turn it on in Settings. Setting up Nodemailer with Gmail after May Viktoria Bors-Pajuste - Sep When have you used reengineering? Once unsuspended, simonpaix will be able to comment and publish posts again. Unpublish all posts. They can still re-publish the post if they are not suspended. Unpublish post. Report other inappropriate conduct. Confirm Flag. Unflagging simonpaix will restore default visibility to their posts. Confirm Unflag. Log in Create account.
0 notes
Text
css grid cheat sheet work OWC&
💾 ►►► DOWNLOAD FILE 🔥🔥🔥🔥🔥 Our comprehensive guide to CSS grid, focusing on all the settings both for the grid parent container and the grid child elements. Today we're going to learn CSS Grid properties so that you can make your own responsive websites. I'll explain how each of Grid's properties. Grid Template Columns. To specify the number of columns of the grid and the widths of each column, the CSS property grid-template-. Hi dev friends! I made this CSS Grid Cheat Sheet that fits on one page. I hope this will help you Tagged with webdev, css, beginners. 9 We're a place where coders share, stay up-to-date and grow their careers. I hope this will help you learn the grid layout. Please let me know what you think of it :. I found one for Bootstrap frontendcheatsheets. I highly doubt any cheatsheet exists for TailwindCSS - simply because of the sheer amount of combinations conceivable. Bootstrap has several ways to generate a "card" but for TailwindCSS, I could come up with at least a hundred!!! Thanks for your effort. I'm still using flexbox and this guide can help me to kickstart use grid functionality. It should be mentioned that justify and align also works with flex and css text columns. So I'm about to start on a project and thinking of the layout- I open my dev. I'll be using it, well done! Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Shahed Nasser - Oct 3. Shubham Dutta - Sep Viktoria Bors-Pajuste - Sep Helitha Rupasinghe - Sep Once suspended, simonpaix will not be able to comment or publish posts until their suspension is removed. Once unpublished, all posts by simonpaix will become hidden and only accessible to themselves. If simonpaix is not suspended, they can still re-publish their posts from their dashboard. Once unpublished, this post will become invisible to the public and only accessible to Mariana Simon. Here is what you can do to flag simonpaix:. Create account Log in. Twitter Facebook Github Instagram Twitch. Hi dev friends! Submit Preview Dismiss. Jul 16, Dropdown menu Copy link Hide. Sep 17, Mar 15, On a mission to make online learning less boring. Coding live on LearnPine. Elena Elena Elena. Jul 13, Ifeoma Ifeoma Ifeoma. Software Engineer. Sometimes Code Sometimes Write, On a journey to live a better life. Aug 16, Dec 11, Oct 24, Apr 21, Hide child comments as well Confirm. Turn it on in Settings. Setting up Nodemailer with Gmail after May Viktoria Bors-Pajuste - Sep When have you used reengineering? Once unsuspended, simonpaix will be able to comment and publish posts again. Unpublish all posts. They can still re-publish the post if they are not suspended. Unpublish post. Report other inappropriate conduct. Confirm Flag. Unflagging simonpaix will restore default visibility to their posts. Confirm Unflag. Log in Create account.
1 note
·
View note
Text
i found this really cool site with a couple of css training games on it. this guy has put in a lot of work into making learning css grids fun. one of the games is free and the other is £130. i bought it cuz i really want to expand on my css knowledge. both games are about webpage layout using the new flexbox and grid technologies. they’re both cutting edge and they’re really detailed. i’ll hopefully be able to make time at work this week to give them a try
i’m aware that i actually spend quite a lot on training every month. it’s totally worth it though. the o’reilly app that i discovered a couple weeks ago lets you read every o’reilly book that they have. literally thousands of books about web development and software engineering. these are books that, in the past, i’ve spent at least £30 each on. now i can read any book i want for £30 a month. it’s on my phone/laptop though but i don’t mind that
i’ve been giving away the coins i found during the spring clean at the weekend. yesterday i was in pret getting breakfast and this old guy came in and asked for a cup of tea. he looked, idk. he looked kinda homeless. i’m in line waiting to buy my things and the cashier tells him his tea will be 1.99. the guy is dumbstruck. he’s like 1.99? 1.99??? and he reluctantly starts to pay.
i’m watching this guy and he’s taking handfuls of coins out his pocket. 1p, 2p, 10p coins. he’s counting them and muttering under his breath about the 1.99. that morning i’d picked up two £1 coins so i thought, !!! this is my chance! i had intended on giving them to someone on the street but i figured this was a good use of the coins. so i patted the guy on the back and said that i’ll get it and gave the cashier the 2 coins.
i felt kinda shy because generally i don’t interact with people i don’t know. much less do i pay for something for a stranger. it was an interesting personal experience for me because pretty much as soon as i handed over the 2 measly coins i felt my eyes start to well up ever so slightly. i’m not sure why. i’m not sure what that emotion was.
i think it might just have been from sort of breaking out this shell i tend to live in where my life revolves around myself. i am the center of my own universe. for that split second, my life wasn’t about me for once. my life was serving the needs of someone else (however trivial that need was).
it felt quite bittersweet though because on the one hand i was happy that this guy got his tea and didn’t have to spent his last few coins on it. on the other i felt kinda guilty because i start to question my motives. the guy was very grateful and thanked me like 3 times. the cashier himself thanked me twice (idk why). he was like “oh, sir, thank you!” and i just felt...idk. i didn’t want to be thanked.
i’m not sure why that is. i would absolutely love it if i could do things anonymously, invisibly. when people thank me i start to question myself. do i do these things for attention? for praise? to look good? to seem special?
but it’s none of those things. i want to do these things just because...i want to do them. i see areas in which i can be useful and i make a decision to be useful. that’s it. i like to see the result of my actions, i like to see the smile on someone’s face. that brings me a lot of joy. and for only £2? that’s a bargain if you ask me. i couldn’t buy anything for the same £2 that would bring me as much joy as giving it away.
i think, though, this comes back to the idea of letting God take control of my life - about me stepping aside. i think that’s why my eyes welled up a bit. i felt like he had control and that i was finally acting in accordance with the things he would like to see in the world. i felt like i was an asset to him, just for a brief second.
fundamentally i believe that God has filled our hearts with this wonderful thing called love and that when i act, i act based on that love. love for my fellow human beings. love for God’s creation. i believe that love is an expression of God. it’s not me. it’s just something that i have inside me. it’s not mine. it was given to me. that’s why i feel guilty when i’m thanked, because i know it’s not me who deserves any kind of thanks. i’m just a vehicle for this love thing, whatever it even really is.
i think back to that phrase i heard a billion times in church, “all glory to God” - i think that’s close.
As a doctrine, it means that everything that is done is for God's glory to the exclusion of mankind's self-glorification and pride. Christians are to be motivated and inspired by God's glory and not their own.
yeah, i think that’s it. i want to remove myself from the equation. there is action and there is God. there is no “me” in the middle. it’s just him.
i’m reminded of the ending of one of aaron weiss’s songs:
if I'm a crown without a king, if I'm a broken open seed
if I come without a thing, then I come with all I need
no boat out in the blue, no place to rest your head,
the trap I set for you seems to have caught my leg instead!
I do not exist only you exist
this song is fantastic all the way through, but the last line really sticks in my head as a concept. it’s so out of left field it feels almost out of place in the song. he just drops it at the end and leaves it there for you to think about. i’ve definitely spent many hours thinking about it and what it entails.
i think it’ll be a few more decades yet before i really truly understand it. before i can really, truly let God take control of “my” life. i know it’s his life. he breathed life into the lungs of adam, not me. he is love, not me. i cannot take credit for anything and nor do i want to.
stupid thoughts over such a tiny gesture, a small interaction, but y’know. life is made up of such things i guess.
0 notes
Text
Thank You (2018 Edition)
Another year come and gone! As we do each year, let's take a look at the past year from an analytical by-the-numbers perspective and do a goal review. Most importantly, I'd like to extend the deepest of thanks to you, wonderful readers of CSS-Tricks, for making this place possible.
This site has a new design, doesn't it? It does! I'll write something more about that soon. If you have something to say about it right now, feel free to use our new public community on Spectrum. If it's a bug or thought that doesn't really need to be public, our our contact form would be great.
I can count the times I pop into Google Analytics per year on my two hands these days, but we've had the basic snippet installed since day one around here, so it's great for keeping an eye on site traffic and usage over the long term. Especially since CSS-Tricks has been a fairly basic WordPress install the entire time with little by the way of major infrastructural changes that would disrupt how these numbers are gathered.
Page views over the entire lifespan of CSS-Tricks.
We had 91 million page views this year, up from 75 million last year. That's great to see, as we were at 75 in 2017, 77 in 2016, and 72 in 2015. We've managed to do a bigger leap this year than perhaps we ever have. I'd love make a go at 100 million next year! That's based on 65 million sessions and 23 million users.
Perhaps some of that traffic could be attributed to the fact that we published 636 Posts this year, up from 595 last year. I'd like to think they are higher quality too, as we've invested much more in guest writing and had a more thorough editing process this year than we ever have. We've had Geoff Graham as lead editor all year and he's doing a phenomenal job of keeping our content train rolling.
For the last few years, I've been trying to think of CSS-Tricks as this two-headed beast. One head is that we're trying to produce long-lasting referential content. We want to be a site that you come to or land on to find answers to front-end questions. The other head is that we want to be able to be read like a magazine. Subscribe, pop by once a week, snag the RSS feed... whatever you like, we hope CSS-Tricks is interesting to read as a hobbyist magazine or industry rag.
We only published 25 new pages this year, which are things like snippets, almanac entries, and videos. I'd really like to see that go up this year, particularly with the almanac, as we have lots of new pages documented that we need to add an update.
I almost wish our URLs had years in them because I still don't have a way to scope analytic data to only show me data from content published this year. I can see the most popular stuff from the year, but that's regardless of when it was published, and that's dominated by the big guides we've had for years and keep updated.
Interestingly, flexbox is still our #1 guide, but searches for the grid guide are only narrowly behind it. It depends on the source though. I can see data for on-site search through WordPress.com (via Jetpack) which show grid searches at about 30% less than flexbox. Google Analytics have it about 60% less, which would be Google searches that end up on CSS-Tricks. Nevertheless, those are the two most popular search keywords, on-site and off. From #3 onwards: svg, border, position, animation, underline, background, display, transition, table, button, uppercase, css, bold, float, hover, transform.
I love that! People are landing on the site looking for fundamental CSS concepts, and hopefully finding what they need.
Site search has been a bit of a journey. Native WordPress search isn't good enough for a site this big. For a long time I used Google Custom Search Engine, which is nice because it's as good as Google is, but bad because it's a bit hard to style nicely and is covered in ads that don't make enough money to be worth it and are too expensive to remove. Last year I was using Algolia for a while, which is a fantastic product, but I needed to give it more development effort than I was able to at the time. Now I'm back on WordPress search but powered by Jetpack, which brings the power of cloud-hosted Elasticsearch, which is pretty sweet. It means I have native WordPress template and styling control, and lots of tweakability.
Search is also fascinating as it represents 81% of how people get to CSS-Tricks. That's particularly interesting in it means that the growth in page views wasn't necessarily from search, as we had 86% of traffic from search last year, down a full 5%. Growth came from other areas so strongly it pushed down search.
All of social media combined is 2%. I'm always reminded this time of year how much time and energy we spend on social media, and how perhaps the smart move is refocusing some of that energy toward on-site content, as that is far better for helping more people. Not that I don't enjoy social media. Surely we've gotten countless ideas for posts and content for those posts from social media participation.
An interesting uptick was in direct traffic. 9% of visits this year were direct, up from just 5% last year. And referral traffic at 7% up from 5%. Social media remained steady, so really we have more people coming directly to the site and more links from other sites to thank for the uptick in traffic.
Speaking of social media, we got @CSS on Twitter this year, and that's been fun. I would have thought it would have increased the rate of growth for followers, but it doesn't appear to.
Chart from SocialBlade. I imagine that downblip was some sort of Twitter spam purge.
We hardly do anything with Facebook, beyond making sure new content is posted there. That sometimes feels like a missed opportunity since there are more people there than any other social network on Earth. But it doesn't seem particularly huge in developer communities as best I can tell. Not to mention Facebook is constantly revealed to be doing sketchy things, which steers me away from it personally.
We've had a remarkably consistent year of the CSS-Tricks Newsletter, publishing it every single week. Robin Rendle works hard on that every single week. We started the year with 31,376 subscribers and ended with 39,655. So about an 8.5k increase, down from the 10k increase last year. It's still good growth, and I suspect we'll see much better growth next year because the new site design does a lot better job promoting it and we have some plans to make our authoring of it and displaying it on this site much better.
If the news about Edge going Chromium made you worry that Chrome would become too dominant of a browser... well, Edge hasn't actually done that yet and Chrome is already pretty darn dominant already, particularly on this site. 77% of traffic is Chrome, 11% Firefox, 6% Safari, about 1.5% each for IE and Edge, and then the rest sprinkled out through 836 other identified browsers.
61% Windows, 22% Mac, 7% Linux, 7% Android, 3% iOS, and the rest sprinkled through 42 known operating systems.
Traffic geography has remained consistent. The United States has the lead at 22%, India at 13%, UK at 5%, Germany at 4%, Canada, France, and Brazil at 3%, Russia, Australia, Netherlands, Spain, Poland, Italy, Ukraine, China, Philipines at 2%, and the rest over 240 other identified countries.
Another surprising turn this year was mobile traffic. Internet-wide, I believe we're past the tipping point of more than half of all traffic being from mobile devices. On this site, we hovered at just 2 or 3% for many years. It was 6% last year, a big jump, and now 10% this year. I always suspected the main reason for the low numbers was the fact that this site is used in conjunction with doing active development, and active development is still a desktop-dominant task. Still, it's growing and the rate of growth is growing too.
There were 3,788 approved comments this year, down from 5,040 last year. We've been hand-approving all comments for a while now. We've always moderated, but having to approve them before they appear at all slows down commenting activity and leads to less overall. I'd estimate maybe 50-60% of non-spam comments get approved. Absolutely worth it to me to maintain a positive vibe here. I also suspect the main reason for lower comments is just that people do a lot more of their conversing over social media. I'm sure if we tracked conversations on social media in relation to things we've published (somehow) that would be up.
Our commenting system is also dreadfully old-timey. I'd love to see a system that allows for accounts, comment editing, social login, a fancy editor, Markdown, the whole nine yards, but I've yet to be swooned by something.
The contact form on site is up to ID #21458, so we got 1,220 messages through that this year.
Goal Review
❌ Publish something in a new format. Behind the scenes, we actually did some foundational work to make this happen, so I'm optimistic about the possibilities. But we didn't get anything out the door. The closest thing we've been doing is organizing content into guides, which is somewhat of a new format for us that I also want to evolve.
✅ More editorial vision. I think we got close enough to call this a success. We did a bunch of themed weeks. We were always grouping content together that is thematically related. Our link posts got better at being referential and topical. We still covered news pretty well. I think I'd like to see us to more far-ahead planning so we can bring bigger ideas to life.
✅ Interesting sponsorship partners. I think we nailed it here.
❌ Create another very popular page. We're at our best when we're creating really strong useful referential content. When we really nail it, we make pages that are very useful to people and it's a win for everybody. I'm not sure we had a run-away super popular page this year, so we'll gun for it next year.
New Goals
Polish this new design. This is easily the most time, effort, and money that's gone into a redesign since the big v10 design. There are a lot of aesthetic changes, but there was also quite a bit of UX work, business goal orientation, workflow tweaking, and backend development work that went along with it. I'd like to get some mileage out of it by not just sitting on it but refining it over a longer period.
Improve newsletter publishing and display. We sent our newsletter out via MailChimp, which is a great product, but over the years it has been good for us to bring as much under the WordPress umbrella as we can. I think we can create a pretty sweet newsletter authoring experience right within WordPress, then continue to send it via MailChimp via a special RSS feed. That'll take some work, but it should make for a better newsletter that is more comfortable to produce and easier to integrate here on the site.
Raise the bar on quality. I'd be happy to see the number of posts we publish go down if we could make the quality go up. Nothing against any of our authors’ work that is already out there, but I think we all know super high-quality articles when we see them and I'd like to hit that mark more often. If that means posts spending more time in editing and us being a bit more demanding about what we'd like to see, we'll do it.
Better guides. There are two sorts of guides: "complete guides" like our flexbox and grid guides (to name a few) and "guide collections" which are hand-chosen, hand-ordered, and hand-maintained guides along a theme, like our beginner guide. As a site with loads of content from over a decade, I really like these as a way to make sure the best stuff has a proper home and we can serve groups of people and topics in a strong way.
THANK YOU!
💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜
Again, you make this place possible.
The post Thank You (2018 Edition) appeared first on CSS-Tricks.
😉SiliconWebX | 🌐CSS-Tricks
0 notes
Text
Thank You (2018 Edition)
Another year come and gone! As we do each year, let's take a look at the past year from an analytical by-the-numbers perspective and do a goal review. Most importantly, I'd like extend the deepest of thanks to you, wonderful readers of CSS-Tricks, for making this place possible.
This site has a new design, doesn't it? It does! I'll write something more about that soon. If you have something to say about it right now, feel free to use our new public community on Spectrum. If it's a bug or thought that doesn't really need to be public, our our contact form would be great.
I can count the times I pop into Google Analytics per year on my two hands these days, but we've had the basic snippet installed since day one around here, so it's great for keeping an eye on site traffic and usage over the long term. Especially since CSS-Tricks has been a fairly basic WordPress install the entire time with little by the way of major infrastructural changes that would disrupt how these numbers are gathered.
Page views over the entire lifespan of CSS-Tricks.
We had 91 million page views this year, up from 75 million last year. That's great to see, as we were at 75 in 2017, 77 in 2016, and 72 in 2015. We've managed to do a bigger leap this year than perhaps we ever have. I'd love make a go at 100 million next year! That's based on 65 million sessions and 23 million users.
Perhaps some of that traffic could be attributed to the fact that we published 636 Posts this year, up from 595 last year. I'd like to think they are higher quality too, as we've invested much more in guest writing and had a more thorough editing process this year than we ever have. We've had Geoff Graham as lead editor all year and he's doing a phenomenal job of keeping our content train rolling.
For the last few years, I've been trying to think of CSS-Tricks as this two-headed beast. One head is that we're trying to produce long-lasting referential content. We want to be a site that you come to or land on to find answers to front-end questions. The other head is that we want to be able to be read like a magazine. Subscribe, pop by once a week, snag the RSS feed... whatever you like, we hope CSS-Tricks is interested to read as a hobbyist magazine or industry rag.
We only published 25 new pages this year, which are things like snippets, almanac entries, and videos. I'd really like to see that go up this year, particularly with the almanac, as we have lots of new pages documented that we need to add and update.
I almost wish our URLs had years in them, because I still don't have a way to scope analytic data to only show me data from content published this year. I can see the most popular stuff from the year, but that's regardless of when it was published, and that's dominated by the big guides we've had for years and keep updated.
Interestingly, flexbox is still our #1 guide, but searches for the grid guide are only narrowly behind it. It depends on the source though. I can see data for on-site search through WordPress.com (via Jetpack) which show grid searches at about 30% less than flexbox. Google Analytics have it about 60% less, which would be Google searches that end up on CSS-Tricks. Nevertheless, those are the two most popular search keywords, on-site and off. From #3 onwards: svg, border, position, animation, underline, background, display, transition, table, button, uppercase, css, bold, float, hover, transform.
I love that! People are landing on the site looking for fundamental CSS concepts, and hopefully finding what they need.
Site search has been a bit of a journey. Native WordPress search isn't good enough for a site this big. For a long time I used Google Custom Search Engine, which is nice because it's as good as Google is, but bad because it's a bit hard to style nicely and is covered in ads that don't make enough money to be worth it and are too expensive to remove. Last year I was using Algolia for a while, which is a fantastic product, but I needed to give it more development effort than I was able to at the time. Now I'm back on WordPress search but powered by Jetpack, which brings the power of cloud-hosted Elasticsearch, which is pretty sweet. I means I have native WordPress template and styling control, and lots of tweakability.
Search is also fascinating as it represents 81% of how people get to CSS-Tricks. That's particularly interesting in it means that the growth in page views wasn't necessarily from search, as we had 86% of traffic from search last year, down a full 5%. Growth came from other areas so strongly it pushed down search.
All of social media combined is 2%. I'm always reminded this time of year how much time and energy we spend on social media, and how perhaps the smart move is refocusing some of that energy toward on-site content, as that is far better for helping more people. Not that I don't enjoy social media. Surely we've gotten countless ideas for posts and content for those posts from social media participation.
An interesting uptick was in direct traffic. 9% of visits this year were direct, up from just 5% last year. And referral traffic at 7% up from 5%. Social media remained steady, so really we have more people coming directly to the site and more links from other sites to thank for the uptick in traffic.
Speaking of social media, we got @CSS on Twitter this year, and that's been fun. I would have thought it would have increased the rate of growth for followers, but it doesn't appear to.
Chart from SocialBlade. I imagine that downblip was some sort of Twitter spam purge.
We hardly do anything with Facebook, beyond making sure new content is posted there. That sometimes feels like a missed opportunity since there is more people there than any other social network on Earth. But it doesn't seem particularly huge in developer communities as best I can tell. Not to mention Facebook is constantly revealed to be doing sketchy things, which steers me away from it personally.
We've had a remarkably consistent year of the CSS-Tricks Newsletter, publishing it every single week. Robin Rendle works hard on that every single week. We started the year with 31,376 subscribers and ended with 39,655. So about an 8.5k increase, down from the 10k increase last year. It's still good growth, and I suspect we'll see much better growth next year because the new site design does a lot better job promoting it and we have some plans to make our authoring of it and displaying it on this site much better.
If the news about Edge going Chromium made you worry that Chrome would become too dominant of a browser... well, Edge hasn't actually done that yet and Chrome is already pretty darn dominant already, particularly on this site. 77% of traffic is Chrome, 11% Firefox, 6% Safari, about 1.5% each for IE and Edge, and then the rest sprinkled out through 836 other identified browsers.
61% Windows, 22% Mac, 7% Linux, 7% Android, 3% iOS, and the rest sprinkled through 42 known operating systems.
Traffic geography has remained consistent. The United States has the lead at 22%, India at 13%, UK at 5%, Germany at 4%, Canada, France, and Brazil at 3%, Russia, Australia, Netherlands, Spain, Poland, Italy, Ukraine, China, Philipines at 2%, and the rest over 240 other identified countries.
Another surprising turn this year was mobile traffic. Internet wide, I believe we're past the tipping point of more than half of all traffic being from mobile devices. On this site, we hovered at just 2 or 3% for many years. It was 6% last year, a big jump, and now 10% this year. I always suspected the main reason for the low numbers was the fact that this site is used in conjuction with doing active development, and active development is still a desktop-dominant task. Still, it's growing and the rate of growth is growing too.
There were 3,788 approved comments this year, down from 5,040 last year. We've been hand-approving all comments for a while now. We've always moderated, but having to approve them before they appear at all slows down commenting activity and leads to less overall. I'd estimate maybe 50-60% of non-spam comments get approved. Absolutely worth it to me to maintain a positive vibe here. I also suspect the main reason for lower comments is just that people do a lot more of their conversing over social media. I'm sure if we tracked conversations on social media in relation to things we've published (somehow) that would be up.
Our commenting system is also dreadfully old timey. I'd love to see a system that allows for accounts, comment editing, social login, a fancy editor, Markdown, the whole nine yards, but I've yet to be swooned by something.
The contact form on site is up to ID #21458, so we got 1,220 messages through that this year.
Goal Review
❌ Publish something in a new format. Behind the scenes, we actually did some foundational work to make this happen, so I'm optimistic for the possibilities. But we didn't get anything out the door. The closest thing we've been doing is organizing content into guides, which is somewhat of a new format for us that I also want to evolve.
✅ More editorial vision. I think we got close enough to call this a success. We did a bunch of themed weeks. We were always grouping content together that is thematically related. Our link posts got better at being referential and topical. We still covered news pretty well. I think I'd like to see us to more far-ahead planning so we can bring bigger ideas to life.
✅ Interesting sponsorship partners. I think we nailed it here.
❌ Create another very popular page. We're at our best when we're creating really strong useful referential content. When we really nail it, we make pages that are very useful to people and it's a win for everybody. I'm not sure we had a run-away super popular page this year, so we'll gun for it next year.
New Goals
Polish this new design. This is easily the most time, effort, and money that's gone into a redesign since the big v10 design. There are a lot of aesthetic changes, but there was also quite a bit of UX work, business goal orientation, workflow tweaking, and backend development work that went along with it. I'd like to get some mileage out of it by not just sitting on it but refining it over a longer period.
Improve newsletter publishing and display. We sent our newsletter out via MailChimp, which is a great product, but over the years it has been good to us to bring as much under the WordPress umbrella as we can. I think we can create a pretty sweet newsletter authoring experience right within WordPress, then continue to send it via MailChimp via a special RSS feed. That'll take some work, but it should make for a better newsletter that is more comfortable to produce and easier to integrate here on the site.
Raise the bar on quality. I'd be happy see the number of posts we publish go down if we could make the quality go up. Nothing aginast any of our authors work that is already out there, but I think we all know super high quality articles when we see them and I'd like to hit that mark more often. If that means posts spending more time in editing and us being a bit more demanding about what we'd like to see, we'll do it.
Better guides. There are two sorts of guides: "complete guides" like our flexbox and grid guides (to name a few) and "guide collections" which are hand-chosen, hand-ordered, and hand-maintained guides along a theme, like our beginner guide. As a site with loads of content from over a decade, I really like these as a way to make sure the best stuff has a proper home and we can serve groups of people and topics in a strong way.
THANK YOU!
💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜💙💚💛🧡❤️💜
Again, you make this place possible.
The post Thank You (2018 Edition) appeared first on CSS-Tricks.
Thank You (2018 Edition) published first on https://deskbysnafu.tumblr.com/
0 notes
Text
The Slow Death of Internet Explorer and the Future of Progressive Enhancement
My first full-time developer job was at a small company. We didn’t have BrowserStack, so we cobbled together a makeshift device lab. Viewing a site I’d been making on a busted first-generation iPad with an outdated version of Safari, I saw a distorted, failed mess. It brought home to me a quote from Douglas Crockford, who once deemed the web “the most hostile software engineering environment imaginable.”
The “works best with Chrome” problem
Because of this difficulty, a problem has emerged. Earlier this year, a widely shared article in the Verge warned of “works best with Chrome” messages seen around the web.
Hi Larry, we apologize for the frustration. Groupon is optimized to be used on a Google Chrome browser, and while you are definitely able to use Firefox or another browser if you'd like, there can be delays when Groupon is not used through Google Chrome.
— Groupon Help U.S. (@GrouponHelpUS) November 26, 2017
Hi Rustram. We'd always recommend that you use Google Chrome to browse the site: we've optimised things for this browser. Thanks.
— Airbnb Help (@AirbnbHelp) July 12, 2016
There are more examples of this problem. In the popular messaging app Slack, voice calls work only in Chrome. In response to help requests, Slack explains its decision like this: “It requires significant effort for us to build out support and triage issues on each browser, so we’re focused on providing a great experience in Chrome.” (Emphasis mine.) Google itself has repeatedly built sites—including Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio—that block alternative browsers entirely. This is clearly a bad practice, but highlights the fact that cross-browser compatibility can be difficult and time-consuming.
The significant feature gap, though, isn’t between Chrome and everything else. Of far more significance is the increasingly gaping chasm between Internet Explorer and every other major browser. Should our development practices be hamstrung by the past? Or should we dash into the future relinquishing some users in our wake? I’ll argue for a middle ground. We can make life easier for ourselves without breaking the backward compatibility of the web.
The widening gulf
Chrome, Opera, and Firefox ship new features constantly. Edge and Safari eventually catch up. Internet Explorer, meanwhile, has been all but abandoned by Microsoft, which is attempting to push Windows users toward Edge. IE receives nothing but security updates. It’s a frustrating period for client-side developers. We read about new features but are often unable to use them—due to a single browser with a diminishing market share.
Internet Explorer’s global market share since 2013 is shown in dark blue. It now stands at just 3 percent.
Some new features are utterly trivial (caret-color!); some are for particular use cases you may never have (WebGL 2.0, Web MIDI, Web Bluetooth). Others already feel near-essential for even the simplest sites (object-fit, Grid).
A list of features supported in Chrome but unavailable in IE11, taken from caniuse.com. This is a truncated and incomplete screenshot of an extraordinarily long list. The promise and reality of progressive enhancement
For content-driven sites, the question of browser support should never be answered with a simple yes or no. CSS and HTML were designed to be fault-tolerant. If a particular browser doesn’t support shape-outside or service workers or font-display, you can still use those features. Your website will not implode. It’ll just lack that extra stylistic flourish or performance optimization in non-supporting browsers.
Other features, such as CSS Grid, require a bit more work. Your page layout is less enhancement than necessity, and Grid has finally brought a real layout system to the web. When used with care for simple cases, Grid can gracefully fall back to older layout techniques. We could, for example, fall back to flex-wrap. Flexbox is by now a taken-for-granted feature among developers, yet even that is riddled with bugs in IE11.
.grid > * { width: 270px; /* no grid fallback style */ margin-right: 30px; /* no grid fallback style */ } @supports (display: grid) { .grid > * { width: auto; margin-right: 0; } }
In the code above, I’m setting all the immediate children of the grid to have a specified width and a margin. For browsers that support Grid, I’ll use grid-gap in place of margin and define the width of the items with the grid-template-columns property. It’s not difficult, but it adds bloat and complexity if it’s repeated throughout a codebase for different layouts. As we start building entire page layouts with Grid (and eventually display: contents), providing a fallback for IE will become increasingly arduous. By using @supports for complex layout tasks, we’re effectively solving the same problem twice—using two different methods to create a similar result.
Not every feature can be used as an enhancement. Some things are imperative. People have been getting excited about CSS custom properties since 2013, but they’re still not widely used, and you can guess why: Internet Explorer doesn’t support them. Or take Shadow DOM. People have been doing conference talks about it for more than five years. It’s finally set to land in Firefox and Edge this year, and lands in Internet Explorer … at no time in the future. You can’t patch support with transpilers or polyfills or prefixes.
Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.
The problem with shoehorning
Rather than eschew modern JavaScript features, polyfilling and transpiling have become the norm. ES6 is supported everywhere other than IE, yet we’re sending all browsers transpiled versions of our code. Transpilation isn’t great for performance. A single five-line async function, for example, may well transpile to twenty-five lines of code.
“I feel some guilt about the current state of affairs,” Alex Russell said of his previous role leading development of Traceur, a transpiler that predated Babel. “I see so many traces where the combination of Babel transpilation overhead and poor [webpack] foo totally sink the performance of a site. … I’m sad that we’re still playing this game.”
What you can’t transpile, you can often polyfill. Polyfill.io has become massively popular. Chrome gets sent a blank file. Ancient versions of IE receive a giant mountain of polyfills. We are sending the largest payload to those the least equipped to deal with it—people stuck on slow, old machines.
What is to be done?Prioritize content
Cutting the mustard is a technique popularized by the front-end team at BBC News. The approach cuts the browser market in two: all browsers receive a base experience or core content. JavaScript is conditionally loaded only by the more capable browsers. Back in 2012, their dividing line was this:
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // load the javascript }
Tom Maslen, then a lead developer at the BBC, explained the rationale: “Over the last few years I feel that our industry has gotten lazy because of the crazy download speeds that broadband has given us. Everyone stopped worrying about how large their web pages were and added a ton of JS libraries, CSS files, and massive images into the DOM. This has continued on to mobile platforms that don’t always have broadband speeds or hardware capacity to render complex code.”
The Guardian, meanwhile, entirely omits both JavaScript and stylesheets from Internet Explorer 8 and further back.
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional.
Nature.com takes a similar approach, delivering only a very limited stylesheet to anything older than IE10.
The nature.com homepage as seen in Internet Explorer 9.
Were you to break into a museum, steal an ancient computer, and open Netscape Navigator, you could still happily view these websites. A user comes to your site for the content. They didn’t come to see a pretty gradient or a nicely rounded border-radius. They certainly didn’t come for the potentially nauseating parallax scroll animation.
Anyone who’s been developing for the web for any amount of time will have come across a browser bug. You check your new feature in every major browser and it works perfectly—except in one. Memorizing support info from caniuse.com and using progressive enhancement is no guarantee that every feature of your site will work as expected.
The W3C’s website for the CSS Working Group as viewed in the latest version of Safari.
Regardless of how perfectly formed and well-written your code, sometimes things break through no fault of your own, even in modern browsers. If you’re not actively testing your site, bugs are more likely to reach your users, unbeknownst to you. Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.
Make a clean break
What could a mustard cut look like going forward? You could conduct a feature query using JavaScript to conditionally load the stylesheet, but relying on JavaScript introduces a brittleness that would be best to avoid. You can’t use @import inside an @supports block, so we’re left with media queries.
The following query will prevent the CSS file from being delivered to any version of Internet Explorer and older versions of other browsers:
<link id="mustardcut" href="stylesheet.css" media=" only screen, only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none), min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0) ">
We’re not really interested in what particular features this query is testing for; it’s just a hacky way to split between legacy and modern browsers. The shiny, modern site will be delivered to Edge, Chrome (and Chrome for Android) 39+, Opera 26+, Safari 9+, Safari on iOS 9+, and Firefox 47+. I based the query on the work of Andy Kirk. If you want to take a cutting-the-mustard approach but have to meet different support demands, he maintains a Github repo with a range of options.
We can use the same media query to conditionally load a Javascript file. This gives us one consistent dividing line between old and modern browsers:
(function() { var linkEl = document.getElementById('mustardcut'); if (window.matchMedia && window.matchMedia(linkEl.media).matches) { var script = document.createElement('script'); script.src = 'your-script.js'; script.async = true; document.body.appendChild(script); } })();
matchMedia brings the power of CSS media queries to JavaScript. The matches property is a boolean that reflects the result of the query. If the media query we defined in the link tag evaluates to true, the JavaScript file will be added to the page.
It might seem like an extreme solution. From a marketing point of view, the site no longer looks “professional” for a small amount of visitors. However, we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them. This is far from a new approach. All the way back in 2001, A List Apart stopped delivering a visual design to Netscape 4. Readership among users of that browser went up.
Front-end development is complicated at the best of times. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to the development process. Testing becomes onerous. Bug-fixing looms large.
By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments. And for Internet Explorer users on Windows 10, Edge is preinstalled. The full experience is only a click away.
Internet Explorer 11 with its ever-present “Open Microsoft Edge” button.
Developers must avoid living in a bubble of MacBook Pros and superfast connections. There’s no magic bullet that enables developers to use bleeding-edge features. You may still need Autoprefixer and polyfills. If you’re planning to have a large user base in Asia and Africa, you’ll need to build a site that looks great in Opera Mini and UC Browser, which have their own limitations. You might choose a different cutoff point for now, but it will increasingly pay off, in terms of both user experience and developer experience, to make use of what the modern web has to offer.
https://ift.tt/2KlVR59
0 notes
Text
The Slow Death of Internet Explorer and the Future of Progressive Enhancement
My first full-time developer job was at a small company. We didn’t have BrowserStack, so we cobbled together a makeshift device lab. Viewing a site I’d been making on a busted first-generation iPad with an outdated version of Safari, I saw a distorted, failed mess. It brought home to me a quote from Douglas Crockford, who once deemed the web “the most hostile software engineering environment imaginable.”
The “works best with Chrome” problem
Because of this difficulty, a problem has emerged. Earlier this year, a widely shared article in the Verge warned of “works best with Chrome” messages seen around the web.
Hi Larry, we apologize for the frustration. Groupon is optimized to be used on a Google Chrome browser, and while you are definitely able to use Firefox or another browser if you'd like, there can be delays when Groupon is not used through Google Chrome.
— Groupon Help U.S. (@GrouponHelpUS) November 26, 2017
Hi Rustram. We'd always recommend that you use Google Chrome to browse the site: we've optimised things for this browser. Thanks.
— Airbnb Help (@AirbnbHelp) July 12, 2016
There are more examples of this problem. In the popular messaging app Slack, voice calls work only in Chrome. In response to help requests, Slack explains its decision like this: “It requires significant effort for us to build out support and triage issues on each browser, so we’re focused on providing a great experience in Chrome.” (Emphasis mine.) Google itself has repeatedly built sites—including Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio—that block alternative browsers entirely. This is clearly a bad practice, but highlights the fact that cross-browser compatibility can be difficult and time-consuming.
The significant feature gap, though, isn’t between Chrome and everything else. Of far more significance is the increasingly gaping chasm between Internet Explorer and every other major browser. Should our development practices be hamstrung by the past? Or should we dash into the future relinquishing some users in our wake? I’ll argue for a middle ground. We can make life easier for ourselves without breaking the backward compatibility of the web.
The widening gulf
Chrome, Opera, and Firefox ship new features constantly. Edge and Safari eventually catch up. Internet Explorer, meanwhile, has been all but abandoned by Microsoft, which is attempting to push Windows users toward Edge. IE receives nothing but security updates. It’s a frustrating period for client-side developers. We read about new features but are often unable to use them—due to a single browser with a diminishing market share.
Internet Explorer’s global market share since 2013 is shown in dark blue. It now stands at just 3 percent.
Some new features are utterly trivial (caret-color!); some are for particular use cases you may never have (WebGL 2.0, Web MIDI, Web Bluetooth). Others already feel near-essential for even the simplest sites (object-fit, Grid).
A list of features supported in Chrome but unavailable in IE11, taken from caniuse.com. This is a truncated and incomplete screenshot of an extraordinarily long list. The promise and reality of progressive enhancement
For content-driven sites, the question of browser support should never be answered with a simple yes or no. CSS and HTML were designed to be fault-tolerant. If a particular browser doesn’t support shape-outside or service workers or font-display, you can still use those features. Your website will not implode. It’ll just lack that extra stylistic flourish or performance optimization in non-supporting browsers.
Other features, such as CSS Grid, require a bit more work. Your page layout is less enhancement than necessity, and Grid has finally brought a real layout system to the web. When used with care for simple cases, Grid can gracefully fall back to older layout techniques. We could, for example, fall back to flex-wrap. Flexbox is by now a taken-for-granted feature among developers, yet even that is riddled with bugs in IE11.
.grid > * { width: 270px; /* no grid fallback style */ margin-right: 30px; /* no grid fallback style */ } @supports (display: grid) { .grid > * { width: auto; margin-right: 0; } }
In the code above, I’m setting all the immediate children of the grid to have a specified width and a margin. For browsers that support Grid, I’ll use grid-gap in place of margin and define the width of the items with the grid-template-columns property. It’s not difficult, but it adds bloat and complexity if it’s repeated throughout a codebase for different layouts. As we start building entire page layouts with Grid (and eventually display: contents), providing a fallback for IE will become increasingly arduous. By using @supports for complex layout tasks, we’re effectively solving the same problem twice—using two different methods to create a similar result.
Not every feature can be used as an enhancement. Some things are imperative. People have been getting excited about CSS custom properties since 2013, but they’re still not widely used, and you can guess why: Internet Explorer doesn’t support them. Or take Shadow DOM. People have been doing conference talks about it for more than five years. It’s finally set to land in Firefox and Edge this year, and lands in Internet Explorer … at no time in the future. You can’t patch support with transpilers or polyfills or prefixes.
Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.
The problem with shoehorning
Rather than eschew modern JavaScript features, polyfilling and transpiling have become the norm. ES6 is supported everywhere other than IE, yet we’re sending all browsers transpiled versions of our code. Transpilation isn’t great for performance. A single five-line async function, for example, may well transpile to twenty-five lines of code.
“I feel some guilt about the current state of affairs,” Alex Russell said of his previous role leading development of Traceur, a transpiler that predated Babel. “I see so many traces where the combination of Babel transpilation overhead and poor [webpack] foo totally sink the performance of a site. … I’m sad that we’re still playing this game.”
What you can’t transpile, you can often polyfill. Polyfill.io has become massively popular. Chrome gets sent a blank file. Ancient versions of IE receive a giant mountain of polyfills. We are sending the largest payload to those the least equipped to deal with it—people stuck on slow, old machines.
What is to be done?Prioritize content
Cutting the mustard is a technique popularized by the front-end team at BBC News. The approach cuts the browser market in two: all browsers receive a base experience or core content. JavaScript is conditionally loaded only by the more capable browsers. Back in 2012, their dividing line was this:
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // load the javascript }
Tom Maslen, then a lead developer at the BBC, explained the rationale: “Over the last few years I feel that our industry has gotten lazy because of the crazy download speeds that broadband has given us. Everyone stopped worrying about how large their web pages were and added a ton of JS libraries, CSS files, and massive images into the DOM. This has continued on to mobile platforms that don’t always have broadband speeds or hardware capacity to render complex code.”
The Guardian, meanwhile, entirely omits both JavaScript and stylesheets from Internet Explorer 8 and further back.
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional.
Nature.com takes a similar approach, delivering only a very limited stylesheet to anything older than IE10.
The nature.com homepage as seen in Internet Explorer 9.
Were you to break into a museum, steal an ancient computer, and open Netscape Navigator, you could still happily view these websites. A user comes to your site for the content. They didn’t come to see a pretty gradient or a nicely rounded border-radius. They certainly didn’t come for the potentially nauseating parallax scroll animation.
Anyone who’s been developing for the web for any amount of time will have come across a browser bug. You check your new feature in every major browser and it works perfectly—except in one. Memorizing support info from caniuse.com and using progressive enhancement is no guarantee that every feature of your site will work as expected.
The W3C’s website for the CSS Working Group as viewed in the latest version of Safari.
Regardless of how perfectly formed and well-written your code, sometimes things break through no fault of your own, even in modern browsers. If you’re not actively testing your site, bugs are more likely to reach your users, unbeknownst to you. Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.
Make a clean break
What could a mustard cut look like going forward? You could conduct a feature query using JavaScript to conditionally load the stylesheet, but relying on JavaScript introduces a brittleness that would be best to avoid. You can’t use @import inside an @supports block, so we’re left with media queries.
The following query will prevent the CSS file from being delivered to any version of Internet Explorer and older versions of other browsers:
<link id="mustardcut" href="stylesheet.css" media=" only screen, only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none), min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0) ">
We’re not really interested in what particular features this query is testing for; it’s just a hacky way to split between legacy and modern browsers. The shiny, modern site will be delivered to Edge, Chrome (and Chrome for Android) 39+, Opera 26+, Safari 9+, Safari on iOS 9+, and Firefox 47+. I based the query on the work of Andy Kirk. If you want to take a cutting-the-mustard approach but have to meet different support demands, he maintains a Github repo with a range of options.
We can use the same media query to conditionally load a Javascript file. This gives us one consistent dividing line between old and modern browsers:
(function() { var linkEl = document.getElementById('mustardcut'); if (window.matchMedia && window.matchMedia(linkEl.media).matches) { var script = document.createElement('script'); script.src = 'your-script.js'; script.async = true; document.body.appendChild(script); } })();
matchMedia brings the power of CSS media queries to JavaScript. The matches property is a boolean that reflects the result of the query. If the media query we defined in the link tag evaluates to true, the JavaScript file will be added to the page.
It might seem like an extreme solution. From a marketing point of view, the site no longer looks “professional” for a small amount of visitors. However, we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them. This is far from a new approach. All the way back in 2001, A List Apart stopped delivering a visual design to Netscape 4. Readership among users of that browser went up.
Front-end development is complicated at the best of times. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to the development process. Testing becomes onerous. Bug-fixing looms large.
By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments. And for Internet Explorer users on Windows 10, Edge is preinstalled. The full experience is only a click away.
Internet Explorer 11 with its ever-present “Open Microsoft Edge” button.
Developers must avoid living in a bubble of MacBook Pros and superfast connections. There’s no magic bullet that enables developers to use bleeding-edge features. You may still need Autoprefixer and polyfills. If you’re planning to have a large user base in Asia and Africa, you’ll need to build a site that looks great in Opera Mini and UC Browser, which have their own limitations. You might choose a different cutoff point for now, but it will increasingly pay off, in terms of both user experience and developer experience, to make use of what the modern web has to offer.
https://ift.tt/2KlVR59
0 notes
Text
The Slow Death of Internet Explorer and the Future of Progressive Enhancement
My first full-time developer job was at a small company. We didn’t have BrowserStack, so we cobbled together a makeshift device lab. Viewing a site I’d been making on a busted first-generation iPad with an outdated version of Safari, I saw a distorted, failed mess. It brought home to me a quote from Douglas Crockford, who once deemed the web “the most hostile software engineering environment imaginable.”
The “works best with Chrome” problem
Because of this difficulty, a problem has emerged. Earlier this year, a widely shared article in the Verge warned of “works best with Chrome” messages seen around the web.
Hi Larry, we apologize for the frustration. Groupon is optimized to be used on a Google Chrome browser, and while you are definitely able to use Firefox or another browser if you'd like, there can be delays when Groupon is not used through Google Chrome.
— Groupon Help U.S. (@GrouponHelpUS) November 26, 2017
Hi Rustram. We'd always recommend that you use Google Chrome to browse the site: we've optimised things for this browser. Thanks.
— Airbnb Help (@AirbnbHelp) July 12, 2016
There are more examples of this problem. In the popular messaging app Slack, voice calls work only in Chrome. In response to help requests, Slack explains its decision like this: “It requires significant effort for us to build out support and triage issues on each browser, so we’re focused on providing a great experience in Chrome.” (Emphasis mine.) Google itself has repeatedly built sites—including Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio—that block alternative browsers entirely. This is clearly a bad practice, but highlights the fact that cross-browser compatibility can be difficult and time-consuming.
The significant feature gap, though, isn’t between Chrome and everything else. Of far more significance is the increasingly gaping chasm between Internet Explorer and every other major browser. Should our development practices be hamstrung by the past? Or should we dash into the future relinquishing some users in our wake? I’ll argue for a middle ground. We can make life easier for ourselves without breaking the backward compatibility of the web.
The widening gulf
Chrome, Opera, and Firefox ship new features constantly. Edge and Safari eventually catch up. Internet Explorer, meanwhile, has been all but abandoned by Microsoft, which is attempting to push Windows users toward Edge. IE receives nothing but security updates. It’s a frustrating period for client-side developers. We read about new features but are often unable to use them—due to a single browser with a diminishing market share.
Internet Explorer’s global market share since 2013 is shown in dark blue. It now stands at just 3 percent.
Some new features are utterly trivial (caret-color!); some are for particular use cases you may never have (WebGL 2.0, Web MIDI, Web Bluetooth). Others already feel near-essential for even the simplest sites (object-fit, Grid).
A list of features supported in Chrome but unavailable in IE11, taken from caniuse.com. This is a truncated and incomplete screenshot of an extraordinarily long list. The promise and reality of progressive enhancement
For content-driven sites, the question of browser support should never be answered with a simple yes or no. CSS and HTML were designed to be fault-tolerant. If a particular browser doesn’t support shape-outside or service workers or font-display, you can still use those features. Your website will not implode. It’ll just lack that extra stylistic flourish or performance optimization in non-supporting browsers.
Other features, such as CSS Grid, require a bit more work. Your page layout is less enhancement than necessity, and Grid has finally brought a real layout system to the web. When used with care for simple cases, Grid can gracefully fall back to older layout techniques. We could, for example, fall back to flex-wrap. Flexbox is by now a taken-for-granted feature among developers, yet even that is riddled with bugs in IE11.
.grid > * { width: 270px; /* no grid fallback style */ margin-right: 30px; /* no grid fallback style */ } @supports (display: grid) { .grid > * { width: auto; margin-right: 0; } }
In the code above, I’m setting all the immediate children of the grid to have a specified width and a margin. For browsers that support Grid, I’ll use grid-gap in place of margin and define the width of the items with the grid-template-columns property. It’s not difficult, but it adds bloat and complexity if it’s repeated throughout a codebase for different layouts. As we start building entire page layouts with Grid (and eventually display: contents), providing a fallback for IE will become increasingly arduous. By using @supports for complex layout tasks, we’re effectively solving the same problem twice—using two different methods to create a similar result.
Not every feature can be used as an enhancement. Some things are imperative. People have been getting excited about CSS custom properties since 2013, but they’re still not widely used, and you can guess why: Internet Explorer doesn’t support them. Or take Shadow DOM. People have been doing conference talks about it for more than five years. It’s finally set to land in Firefox and Edge this year, and lands in Internet Explorer … at no time in the future. You can’t patch support with transpilers or polyfills or prefixes.
Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.
The problem with shoehorning
Rather than eschew modern JavaScript features, polyfilling and transpiling have become the norm. ES6 is supported everywhere other than IE, yet we’re sending all browsers transpiled versions of our code. Transpilation isn’t great for performance. A single five-line async function, for example, may well transpile to twenty-five lines of code.
“I feel some guilt about the current state of affairs,” Alex Russell said of his previous role leading development of Traceur, a transpiler that predated Babel. “I see so many traces where the combination of Babel transpilation overhead and poor [webpack] foo totally sink the performance of a site. … I’m sad that we’re still playing this game.”
What you can’t transpile, you can often polyfill. Polyfill.io has become massively popular. Chrome gets sent a blank file. Ancient versions of IE receive a giant mountain of polyfills. We are sending the largest payload to those the least equipped to deal with it—people stuck on slow, old machines.
What is to be done?Prioritize content
Cutting the mustard is a technique popularized by the front-end team at BBC News. The approach cuts the browser market in two: all browsers receive a base experience or core content. JavaScript is conditionally loaded only by the more capable browsers. Back in 2012, their dividing line was this:
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // load the javascript }
Tom Maslen, then a lead developer at the BBC, explained the rationale: “Over the last few years I feel that our industry has gotten lazy because of the crazy download speeds that broadband has given us. Everyone stopped worrying about how large their web pages were and added a ton of JS libraries, CSS files, and massive images into the DOM. This has continued on to mobile platforms that don’t always have broadband speeds or hardware capacity to render complex code.”
The Guardian, meanwhile, entirely omits both JavaScript and stylesheets from Internet Explorer 8 and further back.
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional.
Nature.com takes a similar approach, delivering only a very limited stylesheet to anything older than IE10.
The nature.com homepage as seen in Internet Explorer 9.
Were you to break into a museum, steal an ancient computer, and open Netscape Navigator, you could still happily view these websites. A user comes to your site for the content. They didn’t come to see a pretty gradient or a nicely rounded border-radius. They certainly didn’t come for the potentially nauseating parallax scroll animation.
Anyone who’s been developing for the web for any amount of time will have come across a browser bug. You check your new feature in every major browser and it works perfectly—except in one. Memorizing support info from caniuse.com and using progressive enhancement is no guarantee that every feature of your site will work as expected.
The W3C’s website for the CSS Working Group as viewed in the latest version of Safari.
Regardless of how perfectly formed and well-written your code, sometimes things break through no fault of your own, even in modern browsers. If you’re not actively testing your site, bugs are more likely to reach your users, unbeknownst to you. Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.
Make a clean break
What could a mustard cut look like going forward? You could conduct a feature query using JavaScript to conditionally load the stylesheet, but relying on JavaScript introduces a brittleness that would be best to avoid. You can’t use @import inside an @supports block, so we’re left with media queries.
The following query will prevent the CSS file from being delivered to any version of Internet Explorer and older versions of other browsers:
<link id="mustardcut" href="stylesheet.css" media=" only screen, only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none), min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0) ">
We’re not really interested in what particular features this query is testing for; it’s just a hacky way to split between legacy and modern browsers. The shiny, modern site will be delivered to Edge, Chrome (and Chrome for Android) 39+, Opera 26+, Safari 9+, Safari on iOS 9+, and Firefox 47+. I based the query on the work of Andy Kirk. If you want to take a cutting-the-mustard approach but have to meet different support demands, he maintains a Github repo with a range of options.
We can use the same media query to conditionally load a Javascript file. This gives us one consistent dividing line between old and modern browsers:
(function() { var linkEl = document.getElementById('mustardcut'); if (window.matchMedia && window.matchMedia(linkEl.media).matches) { var script = document.createElement('script'); script.src = 'your-script.js'; script.async = true; document.body.appendChild(script); } })();
matchMedia brings the power of CSS media queries to JavaScript. The matches property is a boolean that reflects the result of the query. If the media query we defined in the link tag evaluates to true, the JavaScript file will be added to the page.
It might seem like an extreme solution. From a marketing point of view, the site no longer looks “professional” for a small amount of visitors. However, we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them. This is far from a new approach. All the way back in 2001, A List Apart stopped delivering a visual design to Netscape 4. Readership among users of that browser went up.
Front-end development is complicated at the best of times. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to the development process. Testing becomes onerous. Bug-fixing looms large.
By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments. And for Internet Explorer users on Windows 10, Edge is preinstalled. The full experience is only a click away.
Internet Explorer 11 with its ever-present “Open Microsoft Edge” button.
Developers must avoid living in a bubble of MacBook Pros and superfast connections. There’s no magic bullet that enables developers to use bleeding-edge features. You may still need Autoprefixer and polyfills. If you’re planning to have a large user base in Asia and Africa, you’ll need to build a site that looks great in Opera Mini and UC Browser, which have their own limitations. You might choose a different cutoff point for now, but it will increasingly pay off, in terms of both user experience and developer experience, to make use of what the modern web has to offer.
https://ift.tt/2KlVR59
0 notes
Text
The Slow Death of Internet Explorer and the Future of Progressive Enhancement
My first full-time developer job was at a small company. We didn’t have BrowserStack, so we cobbled together a makeshift device lab. Viewing a site I’d been making on a busted first-generation iPad with an outdated version of Safari, I saw a distorted, failed mess. It brought home to me a quote from Douglas Crockford, who once deemed the web “the most hostile software engineering environment imaginable.”
The “works best with Chrome” problem
Because of this difficulty, a problem has emerged. Earlier this year, a widely shared article in the Verge warned of “works best with Chrome” messages seen around the web.
Hi Larry, we apologize for the frustration. Groupon is optimized to be used on a Google Chrome browser, and while you are definitely able to use Firefox or another browser if you'd like, there can be delays when Groupon is not used through Google Chrome.
— Groupon Help U.S. (@GrouponHelpUS) November 26, 2017
Hi Rustram. We'd always recommend that you use Google Chrome to browse the site: we've optimised things for this browser. Thanks.
— Airbnb Help (@AirbnbHelp) July 12, 2016
There are more examples of this problem. In the popular messaging app Slack, voice calls work only in Chrome. In response to help requests, Slack explains its decision like this: “It requires significant effort for us to build out support and triage issues on each browser, so we’re focused on providing a great experience in Chrome.” (Emphasis mine.) Google itself has repeatedly built sites—including Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio—that block alternative browsers entirely. This is clearly a bad practice, but highlights the fact that cross-browser compatibility can be difficult and time-consuming.
The significant feature gap, though, isn’t between Chrome and everything else. Of far more significance is the increasingly gaping chasm between Internet Explorer and every other major browser. Should our development practices be hamstrung by the past? Or should we dash into the future relinquishing some users in our wake? I’ll argue for a middle ground. We can make life easier for ourselves without breaking the backward compatibility of the web.
The widening gulf
Chrome, Opera, and Firefox ship new features constantly. Edge and Safari eventually catch up. Internet Explorer, meanwhile, has been all but abandoned by Microsoft, which is attempting to push Windows users toward Edge. IE receives nothing but security updates. It’s a frustrating period for client-side developers. We read about new features but are often unable to use them—due to a single browser with a diminishing market share.
Internet Explorer’s global market share since 2013 is shown in dark blue. It now stands at just 3 percent.
Some new features are utterly trivial (caret-color!); some are for particular use cases you may never have (WebGL 2.0, Web MIDI, Web Bluetooth). Others already feel near-essential for even the simplest sites (object-fit, Grid).
A list of features supported in Chrome but unavailable in IE11, taken from caniuse.com. This is a truncated and incomplete screenshot of an extraordinarily long list. The promise and reality of progressive enhancement
For content-driven sites, the question of browser support should never be answered with a simple yes or no. CSS and HTML were designed to be fault-tolerant. If a particular browser doesn’t support shape-outside or service workers or font-display, you can still use those features. Your website will not implode. It’ll just lack that extra stylistic flourish or performance optimization in non-supporting browsers.
Other features, such as CSS Grid, require a bit more work. Your page layout is less enhancement than necessity, and Grid has finally brought a real layout system to the web. When used with care for simple cases, Grid can gracefully fall back to older layout techniques. We could, for example, fall back to flex-wrap. Flexbox is by now a taken-for-granted feature among developers, yet even that is riddled with bugs in IE11.
.grid > * { width: 270px; /* no grid fallback style */ margin-right: 30px; /* no grid fallback style */ } @supports (display: grid) { .grid > * { width: auto; margin-right: 0; } }
In the code above, I’m setting all the immediate children of the grid to have a specified width and a margin. For browsers that support Grid, I’ll use grid-gap in place of margin and define the width of the items with the grid-template-columns property. It’s not difficult, but it adds bloat and complexity if it’s repeated throughout a codebase for different layouts. As we start building entire page layouts with Grid (and eventually display: contents), providing a fallback for IE will become increasingly arduous. By using @supports for complex layout tasks, we’re effectively solving the same problem twice—using two different methods to create a similar result.
Not every feature can be used as an enhancement. Some things are imperative. People have been getting excited about CSS custom properties since 2013, but they’re still not widely used, and you can guess why: Internet Explorer doesn’t support them. Or take Shadow DOM. People have been doing conference talks about it for more than five years. It’s finally set to land in Firefox and Edge this year, and lands in Internet Explorer … at no time in the future. You can’t patch support with transpilers or polyfills or prefixes.
Users have more browsers than ever to choose from, yet IE manages to single-handedly tie us to the pre-evergreen past of the web. If developing Chrome-only websites represents one extreme of bad development practice, shackling yourself to a vestigial, obsolete, zombie browser surely represents the other.
The problem with shoehorning
Rather than eschew modern JavaScript features, polyfilling and transpiling have become the norm. ES6 is supported everywhere other than IE, yet we’re sending all browsers transpiled versions of our code. Transpilation isn’t great for performance. A single five-line async function, for example, may well transpile to twenty-five lines of code.
“I feel some guilt about the current state of affairs,” Alex Russell said of his previous role leading development of Traceur, a transpiler that predated Babel. “I see so many traces where the combination of Babel transpilation overhead and poor [webpack] foo totally sink the performance of a site. … I’m sad that we’re still playing this game.”
What you can’t transpile, you can often polyfill. Polyfill.io has become massively popular. Chrome gets sent a blank file. Ancient versions of IE receive a giant mountain of polyfills. We are sending the largest payload to those the least equipped to deal with it—people stuck on slow, old machines.
What is to be done?Prioritize content
Cutting the mustard is a technique popularized by the front-end team at BBC News. The approach cuts the browser market in two: all browsers receive a base experience or core content. JavaScript is conditionally loaded only by the more capable browsers. Back in 2012, their dividing line was this:
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // load the javascript }
Tom Maslen, then a lead developer at the BBC, explained the rationale: “Over the last few years I feel that our industry has gotten lazy because of the crazy download speeds that broadband has given us. Everyone stopped worrying about how large their web pages were and added a ton of JS libraries, CSS files, and massive images into the DOM. This has continued on to mobile platforms that don’t always have broadband speeds or hardware capacity to render complex code.”
The Guardian, meanwhile, entirely omits both JavaScript and stylesheets from Internet Explorer 8 and further back.
The Guardian navigation as seen in Internet Explorer 8. Unsophisticated yet functional.
Nature.com takes a similar approach, delivering only a very limited stylesheet to anything older than IE10.
The nature.com homepage as seen in Internet Explorer 9.
Were you to break into a museum, steal an ancient computer, and open Netscape Navigator, you could still happily view these websites. A user comes to your site for the content. They didn’t come to see a pretty gradient or a nicely rounded border-radius. They certainly didn’t come for the potentially nauseating parallax scroll animation.
Anyone who’s been developing for the web for any amount of time will have come across a browser bug. You check your new feature in every major browser and it works perfectly—except in one. Memorizing support info from caniuse.com and using progressive enhancement is no guarantee that every feature of your site will work as expected.
The W3C’s website for the CSS Working Group as viewed in the latest version of Safari.
Regardless of how perfectly formed and well-written your code, sometimes things break through no fault of your own, even in modern browsers. If you’re not actively testing your site, bugs are more likely to reach your users, unbeknownst to you. Rather than transpiling and polyfilling and hoping for the best, we can deliver what the person came for, in the most resilient, performant, and robust form possible: unadulterated HTML. No company has the resources to actively test their site on every old version of every browser. Malfunctioning JavaScript can ruin a web experience and make a simple page unusable. Rather than leaving users to a mass of polyfills and potential JavaScript errors, we give them a basic but functional experience.
Make a clean break
What could a mustard cut look like going forward? You could conduct a feature query using JavaScript to conditionally load the stylesheet, but relying on JavaScript introduces a brittleness that would be best to avoid. You can’t use @import inside an @supports block, so we’re left with media queries.
The following query will prevent the CSS file from being delivered to any version of Internet Explorer and older versions of other browsers:
<link id="mustardcut" href="stylesheet.css" media=" only screen, only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none), min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0) ">
We’re not really interested in what particular features this query is testing for; it’s just a hacky way to split between legacy and modern browsers. The shiny, modern site will be delivered to Edge, Chrome (and Chrome for Android) 39+, Opera 26+, Safari 9+, Safari on iOS 9+, and Firefox 47+. I based the query on the work of Andy Kirk. If you want to take a cutting-the-mustard approach but have to meet different support demands, he maintains a Github repo with a range of options.
We can use the same media query to conditionally load a Javascript file. This gives us one consistent dividing line between old and modern browsers:
(function() { var linkEl = document.getElementById('mustardcut'); if (window.matchMedia && window.matchMedia(linkEl.media).matches) { var script = document.createElement('script'); script.src = 'your-script.js'; script.async = true; document.body.appendChild(script); } })();
matchMedia brings the power of CSS media queries to JavaScript. The matches property is a boolean that reflects the result of the query. If the media query we defined in the link tag evaluates to true, the JavaScript file will be added to the page.
It might seem like an extreme solution. From a marketing point of view, the site no longer looks “professional” for a small amount of visitors. However, we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them. This is far from a new approach. All the way back in 2001, A List Apart stopped delivering a visual design to Netscape 4. Readership among users of that browser went up.
Front-end development is complicated at the best of times. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to the development process. Testing becomes onerous. Bug-fixing looms large.
By making a clean break with the past, we can focus our energies on building modern sites using modern standards without leaving users stuck on antiquated browsers with an untested and possibly broken site. We save a huge amount of mental overhead. If your content has real value, it can survive without flashy embellishments. And for Internet Explorer users on Windows 10, Edge is preinstalled. The full experience is only a click away.
Internet Explorer 11 with its ever-present “Open Microsoft Edge” button.
Developers must avoid living in a bubble of MacBook Pros and superfast connections. There’s no magic bullet that enables developers to use bleeding-edge features. You may still need Autoprefixer and polyfills. If you’re planning to have a large user base in Asia and Africa, you’ll need to build a site that looks great in Opera Mini and UC Browser, which have their own limitations. You might choose a different cutoff point for now, but it will increasingly pay off, in terms of both user experience and developer experience, to make use of what the modern web has to offer.
https://ift.tt/2KlVR59
0 notes