Front End web development

Recently a reader going by the name of Rock Star sent me a cool little PHP script that automatically updates your site’s .htaccess with a current list of bad IP addresses. This is useful because it gives you better “real time” protection against attacks and malicious requests. This tutorial shares the code and explains how to implement in two easy steps. Specific requirements: you will need access to the server to set up a cron job. Alternately, if you are using WordPress, you need a plugin or custom function to set up a WP Cron event. Step 1: Add PHP Script To implement the automatic IP blacklist, first upload the script to your server. You can copy paste from the following code, or download a copy of the PHP script below. So without further ado, here is the Automatic IP Blacklist: // Latest Blacklist IP file $file = "http://myip.ms/files/blacklist/htaccess/latest_blacklist.txt"; // Latest Blacklist User Submitted IP // Optional, delete this variable $file2 if

Another year! You better not cry, you better not shout, I’m telling you why: @BlueBeanieDay is coming Nov. 30! Start sharing your #bbd photos, links, articles, and videos now: https://t.co/3US4vHBsDR #a11y #WebStandards #InclusiveDesign #ProgressiveEnhancement pic.twitter.com/AiV3ktRqka — zeldman (@zeldman) October 24, 2018 I feel the same this year as I have in the past. Web standards, as an overall idea, has entirely taken hold and won the day. That's worth celebrating, as the web would be kind of a joke without them. So now, our job is to uphold them. We need to cry foul when we see a browser go rogue and ship an API outside the standards process. That version of competition is what could lead the web back to a dark place where we're creating browser-specific versions. That becomes painful, we stop doing it, and slowly, the web loses. Direct Link to Article — Permalink The post Blue Beanie Day 2018 appeared first on CSS-Tricks . from CSS-Tricks https://ift

Here is video proof that Facebook is not letting people delete their own comments. The video shows me trying to delete two different comments, using three different browsers: Chrome, Firefox, and Opera. Watch the video and see for yourself. Very frustrating! Watch Video Download and watch a zipped MP4 video file that demonstrates the FB “can’t delete comments” problem: Facebook Can't Delete Comments – Version 1.0 (13 MB zip) Sorry for the poor production quality. I only have so much allotted free time to spend farting around and troubleshooting on Facebook. If you watch closely, however, you will see that clearly that something (either a bug or intentional f*ckery) is preventing me from deleting/managing my own comments. And I tend to delete FB crap frequently, because I am a thoughtful person who will go back and remove any weird comments or posts that I think are silly, low quality, or just some sort of rant/venting. Also notice in the video: the comments that I am trying

You know the concept of lazy loading images . It prevents the browser from loading images until those images are in (or nearly in) the browser's viewport. There are a plethora of JavaScript-based lazy loading solutions. GitHub has over 3,400 different lazy load repos , and those are just the ones with "lazy load" in a searchable string! Most of them rely on the same trick: Instead of putting an image's URL in the src attribute, you put it in data-src — which is the same pattern for responsive images: JavaScript watches the user scroll down the page When the use encounters an image, JavaScript moves the data-src value into src where it belongs The browser requests the image and it loads into view The result is the browser loading fewer images up front so that the page loads faster. Additionally, if the user never scrolls far enough to see an image, that image is never loaded. That equals faster page loads and less data the user needs to spend. "This is

Harry Roberts writes about working on a project with a rather nasty design flaw. The website was entirely dependent on images loading before rendering any of the content. He digs into why this bad for accessibility and performance but goes further to describe how this can ripple into other problems: While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t. Remember the fallacies ; think about resilience . Harry then suggests that we should always ask ourselves a key question when developing a website: what if this image doesn’t load? For example, if the user is on a low-end device, using a flakey network, using an obscure browser, looking at the site without a crucial API or feature available... you get the idea. While we're on this note, we asked what makes a good front-end developer a little while back and I think this is the best answer to that question after read

Web performance is a huge complicated topic. There are metrics like total requests, page weight, time to glass, time to interactive, first input delay , etc. There are things to think about like asynchronous requests, render blocking, and priority downloading . We often talk about performance budgets and performance culture . How that first document comes down from the server is a hot topic. That is where most back-end related performance talk enters the picture. It gives rise to architectures like the JAMstack , where gosh, at least we don't have to worry about index.html being slow. Images have a performance story all to themselves (formats! responsive images!). Fonts also ( FOUT'n'friends! ). CSS also (talk about render blocking !). Service workers can be involved at every level. And, of course, JavaScript is perhaps the most talked about villain of performance. All of this is balanced with perhaps the most important general performance concept: perceived performan

HTML and CSS are often seen as a burden. This is a feeling I’ve noticed from engineers and designers I’ve worked with in the past, and it’s a sentiment that’s a lot more transparent with the broader web community at large. You can hear it in Medium posts and on indie blogs, whether in conversations about CSS , web performance, or design tools. The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right? Well, no, actually. I certainly don’t think that front-end development is a problem at all. What's behind this feeling? Well, designers want tools that let them draw pictures and export a batch of CSS and HTML files like Dreamweaver promised back in the day. On the other end, engineers don’t want to sweat accessibility, web performance or focus states among many, many other things. There’s simply to

Jon Sneyers: One of the main motivations for FUIF is to have an image format that is responsive by design , which means it’s no longer necessary to produce many variants of the same image: low-quality placeholders, thumbnails, many downscaled versions for many display resolutions. A single file, truncated at different offsets, can do the same thing. FLIF isn't anywhere near ready to use, but it's a fascinating idea. I love the idea that the format stores the image data in such a way that you request just first few kilobytes of the file and to essentially get a low-quality version, then you request more as needed. See this little demo from Eric Portis that shows it off somewhat via a Service Worker and a progressive JPG. If this idea ever does get legs and support in browsers, Cloudinary is super well suited to take advantage of that, as they serve the best image format for the current browser — and that is massive for image performance. Direct Link to Article — Permal

Ire Aderinokun has written a nifty piece using loops and when we might consider replacing it with another method, say .map() and .filter() . I particularly like what she has to say here: As I mentioned earlier, loops are a great tool for a lot of cases, and the existence of these new methods doesn't mean that loops shouldn't be used at all. I think these methods are great because they provide code that is in a way self-documenting. When we use the filter() method instead of a for loop, it is easier to understand at first glance what the purpose of the logic is. However, these methods have very specific use cases and may be overkill if their full value isn't being used. An example of this is the map() method, which can technically be used to replace almost any arbitrary loop. If in our first example, we only wanted to modify the original articles array and not create a new, modified, amazingArticles, using this method would be unnecessary. It's important to use the