emGee Software Solutions Custom Database Applications

Share this

CSS-Tricks

Tips, Tricks, and Techniques on using Cascading Style Sheets.
Updated: 2 days 18 hours ago

Iterating a React Design with Styled Components

Thu, 05/16/2019 - 07:29

In a perfect world, our projects would have unlimited resources and time. Our teams would begin coding with well thought out and highly refined UX designs. There would be consensus among developers about the best way to approach styling. There’d be one or more CSS gurus on the team who could ensure that functionality and style could roll out simultaneously without it turning into a train-wreck.

I’ve actually seen this happen in large enterprise environments. It’s a beautiful thing. This article is not for those people.

On the flip side of the coin is the tiny startup that has zero funding, one or two front-end developers, and a very short timeline to demonstrate some functionality. It doesn’t have to look perfect, but it should at least render reasonably well on desktop, tablet, and mobile. This gets them to a point where it can be shown to advisors and early users; maybe even potential investors who’ve expressed an interest in the concept. Once they get some cashflow from sales and/or investment, they can get a dedicated UX designer and polish the interface.

What follows is for this latter group.

Project Kickoff Meeting

Let’s invent a company to get the ball rolling.

Solar Excursions is a small travel agency aiming to serve the near-future’s burgeoning space tourism industry.

Our tiny development team has agreed that React will be used for the UI. One of our front-end developers is big on Sass, and the other is enamored with CSS in JavaScript. But they’ll be hard pressed to knock out their initial sprint goals; there’s certainly no time for arguing about the best possible styling approach. Both coders agree the choice doesn’t matter much in the long run, as long as its consistently executed. They’re certain that implementing the styling from scratch under the gun now will incur technical debt that will have to be cleaned up later.

After some discussion, the team opts to plan for one or more "styling refactor" sprints. For now, we’ll just focus on getting something up on the screen using React-Bootstrap. That way we’ll be able to quickly build working desktop and mobile layouts without much fuss.

The less time spent on front-end styling the better, because we’ll also need the UI to hook up to the services our backend developer will be cranking out. And, as our application architecture begins to take shape, both front-enders agree it’s important that it be unit tested. They have a lot on their plate.

Based on my discussions with the Powers That Be, as a dedicated project manager, I slaved over Balsamiq for at least ten minutes to provide the team with mockups for the booking page on desktop and mobile. I assume they’ll make tablet meet in the middle and look reasonable.

Initial mockups for the Solar Excursions Trip Booking Page on desktop (left) and mobile (right). Sprint Zero: Review Meeting

Pizza all around! The team worked really hard to hit its goals, and we now have a booking page with a layout that approximates the mockups. The infrastructure for services is coming together, but there’s quite a way to go before we can connect the UI to it. In the interim, the front-enders are using a hardcoded mock data structure.

The first iteration of the page in code using react-bootstrap.

Here’s a look at our UI code so far:

This is all straightforward React. We’re using some of that Hooks hotness, but it’s probably passé to most of you by now.

The key takeaway to notice here is how four of our five application components import and use components from react-bootstrap. Only the main App component is unaffected. That’s because it just composes the top level view with our custom components.

// App.js imports import React, { useState } from "react"; import Navigation from "./Navigation"; import Page from "./Page"; // Navigation.js imports import React from "react"; import { Navbar, Dropdown, Nav } from "react-bootstrap"; // Page.js imports import React from "react"; import PosterCarousel from "./PosterCarousel"; import DestinationLayout from "./DestinationLayout"; import { Container, Row, Col } from "react-bootstrap"; // PosterCarousel.js imports import React from "react"; import { Alert, Carousel, Image } from "react-bootstrap"; // DestinationLayout.js imports import React, { useState, useEffect } from "react"; import { Button, Card, Col, Container, Dropdown, Jumbotron, ListGroup, Row, ToggleButtonGroup, ToggleButton } from "react-bootstrap";

The decision to move fast with Bootstrap has allowed us to hit our sprint goals, but we’re already accumulating technical debt. This is just four affected components, but as the application grows, it’s clear the "styling refactor" sprints that we planned for are going to become exponentially harder. And we haven’t even customized these components much. Once we have tens of components, all using Bootstrap with lots of inline styling to pretty them up, refactoring them to remove react-bootstrap dependencies will be a scary proposition indeed.

Rather than building more of the booking pipeline pages, the team decides that we’ll spend the next sprint working to isolate the react-bootstrap usage in a custom component kit since our services are still under construction. Application components will only use components from this kit. That way, when it comes time to ween ourselves from react-bootstrap, the process will be much easier. We won’t have to refactor thirty usages of the react-bootstrap Button throughout the app, we’ll just rewrite the internals of our KitButton component.

Sprint One: Review Meeting

Well, that was easy. High-fives. No change to the visual appearance of the UI, but we now have a "kit" folder that’s sibling to "components" in our React source. It has a bunch of files like KitButton.js, which basically export renamed react-bootstrap components.

An example component from our kit looks like this:

// KitButton.js import { Button, ToggleButton, ToggleButtonGroup } from "react-bootstrap"; export const KitButton = Button; export const KitToggleButton = ToggleButton; export const KitToggleButtonGroup = ToggleButtonGroup;

We wrap those all kit components up into a module like this:

// kit/index.js import { KitCard } from "./KitCard"; import { KitHero } from "./KitHero"; import { KitList } from "./KitList"; import { KitImage } from "./KitImage"; import { KitCarousel } from "./KitCarousel"; import { KitDropdown } from "./KitDropdown"; import { KitAttribution } from "./KitAttribution"; import { KitNavbar, KitNav } from "./KitNavbar"; import { KitContainer, KitRow, KitCol } from "./KitContainer"; import { KitButton, KitToggleButton, KitToggleButtonGroup } from "./KitButton"; export { KitCard, KitHero, KitList, KitImage, KitCarousel, KitDropdown, KitAttribution, KitButton, KitToggleButton, KitToggleButtonGroup, KitContainer, KitRow, KitCol, KitNavbar, KitNav };

And now our application components are completely free of react-bootstrap. Here are the imports for the affected components:

// Navigation.js imports import React from "react"; import { KitNavbar, KitNav, KitDropdown } from "../kit"; // Page.js imports import React from "react"; import PosterCarousel from "./PosterCarousel"; import DestinationLayout from "./DestinationLayout"; import { KitContainer, KitRow, KitCol } from "../kit"; // PosterCarousel.js imports import React from "react"; import { KitAttribution, KitImage, KitCarousel } from "../kit"; // DestinationLayout.js imports import React, { useState, useEffect } from "react"; import { KitCard, KitHero, KitList, KitButton, KitToggleButton, KitToggleButtonGroup, KitDropdown, KitContainer, KitRow, KitCol } from "../kit";

Here’s the front-end codebase now:

Although we’ve corralled all of the react imports into our kit components, our application components still rely a bit on the react-bootstrap implementation because the attributes we place on our kit component instances are the same as those of react-bootstrap. That constrains us when it comes to re-implementing the kit components, because we need to adhere to the same API. For instance:

// From Navigation.js <KitNavbar bg="dark" variant="dark" fixed="top">

Ideally, we wouldn’t have to add those react-bootstrap specific attributes when we instantiate our KitNavbar.

The front-enders promise to refactor those out as we go, now that we’ve identified them as problematic. And any new references to react-bootstrap components will go into our kit instead of directly into the application components.

Meanwhile, we’ve shared our mock data with the server engineer, who is working hard to build separate server environments, implement the database schema, and expose some services to us.

That gives us time to add some gloss to our UI in the next sprint — which is good because the Powers That Be would like to see separate themes for each destination. As the user browses destinations, we need to have the UI color scheme change to match the displayed travel poster. Also, we want to try and spiff up those components a bit to begin evolving our own look and feel. Once we have some money coming in, we’ll get a designer to do a complete overhaul, but hopefully we can reach a happy medium for our early users.

Sprint Two: Review Meeting

Wow! The team really pulled out all the stops this sprint. We got per-destination themes, customized components, and a lot of the lingering react-bootstrap API implementations removed from the application components.

Here’s what the desktop looks like now:

Check out the solarized theme for the red planet!

In order to pull this off, the front-enders brought in the Styled Components library. It made styling the individual kit components a breeze, as well as adding support for multiple themes.

Let’s look at a few highlights of their changes for this sprint.

First, for global things like pulling in fonts and setting the page body styles, we have a new kit component called KitGlobal.

// KitGlobal.js import { createGlobalStyle } from "styled-components"; export const KitGlobal = createGlobalStyle` body { @import url('https://fonts.googleapis.com/css?family=Orbitron:500|Nunito:600|Alegreya+Sans+SC:700'); background-color: ${props => props.theme.foreground}; overflow-x: hidden; } `;

It uses the createGlobalStyle helper to define the CSS for the body element. That imports our desired web fonts from Google, sets the background color to whatever the current theme’s "foreground" value is, and turns off overflow in the x-direction to eliminate a pesky horizontal scrollbar. We use that KitGlobal component in the render method of our App component.

Also in the App component, we import ThemeProvider from styled-components, and something called "themes" from ../theme. We use React’s useState to set the initial theme to themes.luna and React’s useEffect to call setTheme whenever the "destination" changes. The returned component is now wrapped in ThemeProvider, which is passed "theme" as a prop. Here’s the App component in its entirety.

// App.js import React, { useState, useEffect } from "react"; import { ThemeProvider } from "styled-components"; import themes from "../theme/"; import { KitGlobal } from "../kit"; import Navigation from "./Navigation"; import Page from "./Page"; export default function App(props) { const [destinationIndex, setDestinationIndex] = useState(0); const [theme, setTheme] = useState(themes.luna); const destination = props.destinations[destinationIndex]; useEffect(() => { setTheme(themes[destination.theme]); }, [destination]); return ( <ThemeProvider theme={theme}> <React.Fragment> <KitGlobal /> <Navigation {...props} destinationIndex={destinationIndex} setDestinationIndex={setDestinationIndex} /> <Page {...props} destinationIndex={destinationIndex} setDestinationIndex={setDestinationIndex} /> </React.Fragment> </ThemeProvider> ); }

KitGlobal is rendering like any other component. Nothing special there, only that the body tag is affected. ThemeProvider is using the React Context API to pass theme down to whatever components need it (which is all of them). In order to fully understand that, we also need to take a look at what a theme actually is.

To create a theme, one of our front-enders took all the travel posters and created palettes for each by extracting the prominent colors. That was fairly simple.

We used TinyEye for this.

Obviously, we weren’t going to use all the colors. The approach was mainly to dub the most used two colors foreground and background. Then we took three more colors, generally ordered from lightest to darkest as accent1, accent2, and accent3. Finally, we picked two contrasting colors to call text1 and text2. For the above destination, that looked like:

// theme/index.js (partial list) const themes = { ... mars: { background: "#a53237", foreground: "#f66f40", accent1: "#f8986d", accent2: "#9c4952", accent3: "#f66f40", text1: "#f5e5e1", text2: "#354f55" }, ... }; export default themes;

Once we have a theme for each destination, and it is being passed into all the components (including the kit components that our application components are now built from), we need to use styled-components to apply those theme colors as well as our custom visual styling, like the panel corners and "border glow."

This is a simple example where we made our KitHero component apply the theme and custom styles to the Bootstrap Jumbotron:

// KitHero.js import styled from "styled-components"; import { Jumbotron } from "react-bootstrap"; export const KitHero = styled(Jumbotron)` background-color: ${props => props.theme.accent1}; color: ${props => props.theme.text2}; border-radius: 7px 25px; border-color: ${props => props.theme.accent3}; border-style: solid; border-width: 1px; box-shadow: 0 0 1px 2px #fdb813, 0 0 3px 4px #f8986d; font-family: "Nunito", sans-serif; margin-bottom: 20px; `;

In this case, we’re good to go with what gets returned from styled-components, so we just name it KitHero and export it.

When we use it in the application, it looks like this:

// DestinationLayout.js (partial code) const renderHero = () => { return ( <KitHero> <h2>{destination.header}</h2> <p>{destination.blurb}</p> <KitButton>Book Your Trip Now!</KitButton> </KitHero> ); };

Then there are more complex cases where we want to preset some attributes on the react-bootstrap component. For instance, the KitNavbar component which we identified earlier as having a bunch of react-bootstrap attributes that we’d rather not pass from the application’s declaration of the component.

Now for a look at how that was handled:

// KitNavbar.js (partial code) import React, { Component } from "react"; import styled from "styled-components"; import { Navbar } from "react-bootstrap"; const StyledBootstrapNavbar = styled(Navbar)` background-color: ${props => props.theme.background}; box-shadow: 0 0 1px 2px #fdb813, 0 0 3px 4px #f8986d; display: flex; flex-direction: horizontal; justify-content: space-between; font-family: "Nunito", sans-serif; `; export class KitNavbar extends Component { render() { const { ...props } = this.props; return <StyledBootstrapNavbar fixed="top" {...props} />; } }

First, we create a component called StyledBootstrapNavbar using styled-components. We were able to handle some of the attributes with the CSS we passed to styled-components. But in order to continue leveraging (for now) the reliable stickiness of the component to the top of the screen while everything else is scrolled, our front-enders elected to continue using react-bootstrap’s fixed attribute. In order to do that, we had to create a KitNavbar component that rendered an instance of StyledBootstrapNavbar with the fixed=top attribute. We also passed through all the props, which includes its children.

We only have to create a separate class that renders styled-component’s work and passes props through to it if we want to explicitly set some attributes in our kit component by default. In most cases, we can just name and return styled-component’s output and use it as we did with KitHero above.

Now, when we render the KitNavbar in our application’s Navigation component, it looks like this:

// Navigation.js (partial code) return ( <KitNavbar> <KitNavbarBrand> <KitLogo /> Solar Excursions </KitNavbarBrand> {renderDestinationMenu()} </KitNavbar> );

Finally, we took our first stabs at refactoring our kit components away from react-bootstrap. The KitAttribution component is a Bootstrap Alert which, for our purposes, is little more than an ordinary div. We were able to easily refactor to remove its dependency on react-bootstrap.

This is the component as it emerged from the previous sprint:

// KitAttribution.js (using react-bootstrap) import { Alert } from "react-bootstrap"; export const KitAttribution = Alert;

This is what it looks like now:

// KitAttribution.js import styled from "styled-components"; export const KitAttribution = styled.div` text-align: center; background-color: ${props => props.theme.accent1}; color: ${props => props.theme.text2}; border-radius: 7px 25px; border-color: ${props => props.theme.accent3}; border-style: solid; border-width: 1px; box-shadow: 0 0 1px 2px #fdb813, 0 0 3px 4px #f8986d; font-family: "Alegreya Sans SC", sans-serif; > a { color: ${props => props.theme.text2}; font-family: "Nunito", sans-serif; } > a:hover { color: ${props => props.theme.background}; text-decoration-color: ${props => props.theme.accent3}; } `;

Notice how we no longer import react-bootstrap and we use styled.div as the component base. They won’t all be so easy, but it’s a process.

Here are the results of our team’s styling and theming efforts in sprint 3:

Conclusion

After three sprints, our team is well on its way to having a scalable component architecture in place for the UI.

  • We are moving quickly thanks to react-bootstrap, but are no longer piling up loads of technical debt as a result of it.
  • Thanks to styled-components, we were able to implement multiple themes (like how almost every app on the Internet these days sports dark and light modes). We also don’t look like an out-of-the-box Bootstrap app anymore.
  • By implementing a custom component kit that contains all references to react-bootstrap, we can refactor away from it as time permits.

The post Iterating a React Design with Styled Components appeared first on CSS-Tricks.

Categories: Web Technologies

Evergreen Googlebot

Thu, 05/16/2019 - 07:28

I've heard people say that the #1 most exciting and important thing that came out of Google I/O this year was the evergreen Googlebot:

Today, we are happy to announce that Googlebot now runs the latest Chromium rendering engine (74 at the time of this post) when rendering pages for Search. Moving forward, Googlebot will regularly update its rendering engine to ensure support for latest web platform features.

Before this, I guess I never even thought about it.

I guess part of it is that some people did already know that the old version didn't support some newfangled JavaScript stuff, and thus literally packaged their app with old JavaScript to be more SEO-friendly.

A bunch of people were apparently shipping older code simply for the sake of Googlebot, and now they don't have to. Sure, I'll call that a win.

Don't read this news as "don't worry about your JavaScript-rendered pages and SEO" though, because Google Webmasters is still telling us that pages with content that requires JavaScript to render are put into a special slower queue for both initial crawling and for updates. Not necessarily a penalty, but certainly a delay. I'm sure that's enough to make server-side rendering a priority for sites where SEO is the whole ballgame.

Direct Link to ArticlePermalink

The post Evergreen Googlebot appeared first on CSS-Tricks.

Categories: Web Technologies

Using Jetpack to Accelerate WordPress Development

Thu, 05/16/2019 - 07:25

(This is a sponsored post.)

[Geoff:] I've built a fair number of WordPress sites in my day. It's been my go-to since the 2.x-ish days because it works for any site, big or small. That's the sort of solution and flexibility you like to have as a freelancer.

Boy, I wish I had Jetpack available in those early days.

Like WordPress itself, Jetpack is a good solution for many, many of the types of things clients are looking for from a WordPress site. I used to spend hours researching the right plugin for a specific feature, whether that was for comment filtering, asset caching, beefier search functionality, creating custom post types on the fly... you name it. All of that — and a heckuva lot more — is included in Jetpack right out of the box.

Here's what I'm talking about. A friend of mine runs a pop-up gallery here locally. She displays paintings, photographs, sculptures... basically anything super artsy from super talented locals. That includes events, socials, performances and screenings. The wild thing is that it "pops" up in different spots, based on what she's showing and what public space is available. So, you get how a website would be helpful for visitors to keep tabs on what's coming up and where things are going to take place, not to mention getting a recap on past events.

We've all made sites for friends, right? It's the kind of thing you do for free on the side. That makes it something you want to do well, but not necessarily spend a ton of time making. That's where Jetpack really helped me out in this case.

If Jetpack is new to you, it's a WordPress plugin that, as part of what it does, is bring features from WordPress.com and makes them available on your self-hosted WordPress sites.

For example, my friend really needed to showcase work. This is less of a content site and more of a visual experience, so media plays a big role. Photos, video, audio. You get it. Good thing Jetpack has a "Portfolio" custom post type at the ready.

That's a perfect start for showing things off, but my friend also needed a carousel to allow visitors to browse photos from events and artist works. This would've been something I probably would have turned to the WordPress plugin directory for in the past, or perhaps some (back then) jQuery plugin, but thankfully Jetpack had my back there, too.

While we're on the topic of media, we know that heavy image files are a recipe for slow sites. There's a ton of WordPress plugins that can help with caching, gzipping, and even lazy loading, but all that's already in Jetpack. Why go reinvent the wheel, especially on what's supposed to be a pretty quick build?

I think you catch my drift. The fact is that Jetpack is an effective way to supercharge a self-hosted WordPress site, connecting it to many of the same powerful services that you'd otherwise need to go to WordPress.com — or gobs of third-party plugins — to get. Plus, it's built by Automattic, so you know it integrates seamlessly with WordPress. No better confidence than going with something the primary maintainers of WordPress are willing to slap their name on!

Sure, we've only looked at a very simple example of how powerful Jetpack is for a small site. But don't be fooled: Jetpack is capable of handling the needs of large-scale sites as well. In fact, we love Jetpack here at CSS-Tricks because it powers so much of what you see on the site, from social sign-in and automated sharing, to downtime monitoring and site search. It's robust, dependable, and just gosh darn delightful to use.

And, hey, there's a free tier you can start using right away and it includes a generous number of features that help with security, performance, analytics, and theming... and it only goes up from there. &#x1f680;

Get Jetpack

Direct Link to ArticlePermalink

The post Using Jetpack to Accelerate WordPress Development appeared first on CSS-Tricks.

Categories: Web Technologies

A Deep Dive into Native Lazy-Loading for Images and Frames

Wed, 05/15/2019 - 08:04

Today's websites are packed with heavy media assets like images and videos. Images make up around 50% of an average website's traffic. Many of them, however, are never shown to a user because they're placed way below the fold.

What’s this thing about images being lazy, you ask? Lazy-loading is something that’s been covered quite a bit here on CSS-Tricks, including a thorough guide with documentation for different approaches using JavaScript. In short, we’re talking about a mechanism that defers the network traffic necessary to load content when it’s needed — or rather when trigger the load when the content enters the viewport.

The benefit? A smaller initial page that loads faster and saves network requests for items that may not be needed if the user never gets there.

If you read through other lazy-loading guides on this or other sites, you’ll see that we’ve had to resort to different tactics to make lazy-loading work. Well, that’s about to change when lazy-loading will be available natively in HTML as a new loading attribute… at least in Chrome which will hopefully lead to wider adoption. Chrome has already merged the code for native lazy-loading and is expected to ship it in Chrome 75, which is slated to release June 4, 2019.

The pre-native approach

Until now, developers like ourselves have had to use JavaScript (whether it’s a library or something written from scratch) in order to achieve lazy-loading. Most libraries work like this:

  • The initial, server-side HTML response includes an img element without the src attribute so the browser does not load any data. Instead, the image's URL is set as another attribute in the element's data set, e. g. data-src.
  • <img data-src="https://tiny.pictures/example1.jpg" alt="...">
  • Then, a lazy-loading library is loaded and executed.
  • <script src="LazyLoadingLibrary.js"></script> <script>LazyLoadingLibrary.run()</script>
  • That keeps track of the user's scrolling behavior and tells the browser to load the image when it is about to be scrolled into view. It does that by copying the data-src attribute's value to the previously empty src attribute.
  • <img src="https://tiny.pictures/example1.jpg" data-src="https://tiny.pictures/example1.jpg" alt="...">

This has worked for a pretty long time now and gets the job done. But it’s not ideal for good reasons.

The obvious problem with this approach is the length of the critical path for displaying the website. It consists of three steps, which have to be carried out in sequence (after each other):

  1. Load the initial HTML response
  2. Load the lazy-loading library
  3. Load the image file

If this technique is used for images above the fold the website will flicker during loading because it is first painted without the image (after step 1 or 2, depending on if the script uses defer or async) and then — after having been loaded — include the image. It will also be perceived as loading slowly.

In addition, the lazy-loading library itself puts an extra weight on the website's bandwidth and CPU requirements. And let’s not forget that a JavaScript approach won't work for people who have JavaScript disabled (although we shouldn't really care about them in 2019, should we?).

Oh, and what about sites that rely on RSS to distribute content, like CSS-Tricks? The initial image-less render means there are no images in the RSS version of content as well.

And so on.

Native lazy-loading to the rescue!

As we noted at the start, Chromium and Google Chrome will ship a native lazy-loading mechanism in the form of a new loading attribute, starting in Chrome 75. We’ll go over the attribute and its values in just a bit, but let’s first get it working in our browsers so we can check it out together.

Enable native lazy-loading

Until Chrome 75 is officially released, we have Chrome Canary and can enable lazy-loading manually by switching two flags.

  1. Open chrome://flags in Chromium or Chrome Canary.
  2. Search for lazy.
  3. Enable both the "Enable lazy image loading" and the "Enable lazy frame loading" flag.
  4. Restart the browser with the button in the lower right corner of the screen.
Native lazy-loading flags in Google Chrome

You can check if the feature is properly enabled by opening your JavaScript console (F12). You should see the following warning:

[Intervention] Images loaded lazily and replaced with placeholders. Load events are deferred."

All set? Now we get to dig into the loading attribute.

The loading attribute

Both the img and the iframe elements will accept the loading attribute. It's important to note that its values will not be taken as a strict order by the browser but rather as a hint to help the browser make its own decision whether or not to load the image or frame lazily.

The attribute can have three values which are explained below. Next to the images, you'll find tables listing your individual resource loading timings for this page load. Range response refers to a kind of partial pre-flight request made to determine the image's dimensions (see How it works) for details). If this column is filled, the browser made a successful range request.

Please note the startTime column, which states the time image loading was deferred after the DOM had been parsed. You might have to perform a hard reload (CTRL + Shift + R) to re-trigger range requests.

The auto (or unset) value <img src="auto-cat.jpg" loading="auto" alt="..."> <img src="auto-cat.jpg" alt="..."> <iframe src="https://css-tricks.com/" loading="auto"></iframe> <iframe src="https://css-tricks.com/"></iframe> Auto cat loaded automatically

Setting the loading attribute to auto (or simply leaving the value blank, as in loading="") lets the browser decide whether or not to lazy-load an image. It takes many things into consideration to make that decision, like the platform, whether Data Saver mode is enabled, network conditions, image size, image vs. iframe, the CSS display property, among others. (See How it works) for info about why all this is important.)

The eager value <img src="auto-cat.jpg" loading="eager" alt="..."> <iframe src="https://css-tricks.com/" loading="eager"></iframe> Eager cat loaded eagerly

The eager value provides a hint to the browser that an image should be loaded immediately. If loading was already deferred (e. g. because it had been set to lazy and was then changed to eager by JavaScript), the browser should start loading the image immediately.

The lazy value <img src="auto-cat.jpg" loading="lazy" alt="..."> <iframe src="https://css-tricks.com/" loading="lazy"></iframe> Lazy cat loaded lazily

The lazy value provides a hints to the browser that an image should be lazy-loaded. It's up to the browser to interpret what exactly this means, but the explainer document states that it should start loading when the user scrolls "near" the image such that it is probably loaded once it actually comes into view.

How the loading attribute works

In contrast to JavaScript lazy-loading libraries, native lazy-loading uses a kind of pre-flight request to get the first 2048 bytes of the image file. Using these, the browser tries to determine the image's dimensions in order to insert an invisible placeholder for the full image and prevent content from jumping during loading.

The image's load event is fired as soon as the full image is loaded, be it after the first request (for images smaller than 2 KB) or after the second one. Please note that the load event may never be fired for certain images because the second request is never made.

In the future, browsers might make twice as many image requests as there would be under the current proposal. First the range request, then the full request. Make sure your servers support the HTTP Range: 0-2047 header and respond with status code 206 (Partial Content) to prevent them from delivering the full image twice.

Due to the higher number of subsequent requests made by the same user, web server support for the HTTP/2 protocol will become more important.

Let’s talk about deferred content. Chrome's rendering engine Blink uses heuristics to determine which content should be deferred and for how long to defer it. You can find a comprehensive list of requirements in Scott Little's design documentation. This is a short breakdown of what will be deferred:

  • Images and frames on all platforms which have loading="lazy" set
  • Images on Chrome for Android with Data Saver enabled and that satisfy all of the following:
    • loading="auto" or unset
    • no width and height attributes smaller than 10px
    • not created programmatically in JavaScript
  • Frames which satisfy all of the following:
    • loading="auto" or unset
    • is from a third-party (different domain or protocol than the embedding page)
    • larger than 4 pixels in height and width (to prevent deferring tiny tracking frames)
    • not marked as display: none or visibility: hidden (again, to prevent deferring tracking frames)
    • not positioned off-screen using negative x or y coordinates
Responsive images with srcset

Native lazy-loading also works with responsive img elements using the srcset attribute. This attribute offers a list of image file candidates to the browser. Based on the user's screen size, display pixel ratio, network conditions, etc., the browser will choose the optimal image candidate for the occasion. Image optimization CDNs like tiny.pictures are able to provide all image candidates in real-time without any back end development necessary.

<img src="https://demo.tiny.pictures/native-lazy-loading/lazy-cat.jpg" srcset="https://demo.tiny.pictures/native-lazy-loading/lazy-cat.jpg?width=400 400w, https://demo.tiny.pictures/native-lazy-loading/lazy-cat.jpg?width=800 800w" loading="lazy" alt="..."> Browser support

At the time of this writing, no browser supports native-loading by default. However, Chrome will enable the feature, as we’ve covered, starting in Chrome 75. No other browser vendor has announced support so far. (Edge being a kind of exception because it will soon make the switch to Chromium.)

You can detect the feature with a few lines of JavaScript:

if ("loading" in HTMLImageElement.prototype) { // Support. } else { // No support. You might want to dynamically import a lazy-loading library here (see below). }

See the Pen
Native lazy-loading browser support
by Erk Struwe (@erkstruwe)
on CodePen.

Automatic fallback to JavaScript solution with low-quality image placeholder

One very cool feature of most JavaScript-based lazy-loading libraries is the low-quality image placeholder (LQIP). Basically, it leverages the idea that browsers load (or perhaps I should say used to load) the src of an img element immediately, even if it gets later replaced by another URL. This way, it’s possible to load a tiny file size, low-quality image file on page load and later replace it with a full-sized version.

We can now use this to mimic the native lazy-loading’s 2 KB range requests in browsers that do not support this feature in order to achieve the same result, namely a placeholder with the actual image dimensions and a tiny file size.

See the Pen
Native lazy-loading with JavaScript library fallback and low-quality image placeholder
by Erk Struwe (@erkstruwe)
on CodePen.

Conclusion

I'm really excited about this feature. And frankly, I'm still wondering why it hasn't got much more attention until now, given the fact that its release is imminent and the impact on global internet traffic will be remarkable, even if only small parts of the heuristics are changed.

Think about it: After a gradual roll-out for the different Chrome platforms and with auto being the default setting, the world's most popular browser will soon lazy-load below-the-fold images and frames by default. Not only will the traffic amount of many badly-written websites drop significantly, but web servers will be hammered with tiny requests for image dimension detection.

And then there's tracking: Assuming many unsuspecting tracking pixels and frames will be prevented from being loaded, the analytics and affiliate industry will have to act. We can only hope they don't panic and add loading="eager" to every single image, rendering this great feature useless for their users. They should rather change their code to be recognized as tracking pixels by the heuristics described above.

Web developers, analytics and operations managers should check their website's behavior with this feature and their servers' support for Range requests and HTTP/2 immediately.

Image optimization CDNs could help out in case there are any issues to be expected or if you’d like to take image delivery optimization to the max (including automatic WebP support, low-quality image placeholders, and much more). Read more about tiny.pictures!

References

The post A Deep Dive into Native Lazy-Loading for Images and Frames appeared first on CSS-Tricks.

Categories: Web Technologies

A Better Approach for Using Purgecss with Tailwind

Wed, 05/15/2019 - 07:29

Greg Kohn looks at how to use Purgecss — a tool that helps remove unused styles — and Tailwind — a utility-based CSS framework — and why we might want to pair these tools together:

Tailwind, by intention, is aiming to equip you with an arsenal of utility classes by generating more than you need. There are some best practices which will help keep this overall build size down, like limiting your colors and breakpoints or turning off the modules by default before adding them as necessary. Still, you’ll inevitably generate classes that go unused. And honestly, approaching your configuration with an unrelenting miserly attitude will slow you down and make development less fun. By leaning on Purgecss, there’s no worry that the CSS your users download will only include classes that are ultimately needed.

I’ve never used Tailwind or Purgecss, but I reckon the latter could be particularly useful if you have a giant old codebase and you don’t have the resources to refactor things just yet. I guess my only concern with introducing a tool like that is it could encourage folks to not refactor large and problematic areas in their styles – taking the safest route with this tool instead.

For more info about Tailwind, though, Ben Tinsley wrote a great post a while back about how to get started and Nick Basile showed us how to style a form with Tailwind.

Direct Link to ArticlePermalink

The post A Better Approach for Using Purgecss with Tailwind appeared first on CSS-Tricks.

Categories: Web Technologies

Integrating Third-Party Animation Libraries to a Project

Tue, 05/14/2019 - 07:28

Creating CSS-based animations and transitions can be a challenge. They can be complex and time-consuming. Need to move forward with a project with little time to tweak the perfect transition? Consider a third-party CSS animation library with ready-to-go animations waiting to be used. Yet, you might be thinking: What are they? What do they offer? How do I use them?

Well, let’s find out.

A (sort of) brief history of :hover

Once there was a time that the concept of a hover state was a trivial example of what is offered today. In fact, the idea of having a reaction to the cursor passing on top of an element was more-or-less nonexistent. Different ways to provide this feature were proposed and implemented. This small feature, in a way, opened the door to the idea of CSS being capable of animations for elements on the page. Over time, the increasing complexity possible with these features have led to CSS animation libraries.

Macromedia’s Dreamweaver was introduced in December 1997 and offered what was a simple feature, an image swap on hover. This feature was implemented with a JavaScript function that would be embedded in the HTML by the editor. This function was named MM_swapImage() and has become a bit of web design folklore. It was an easy script to use, even outside of Dreamweaver, and it’s popularity has resulted in it still being in use even today. In my initial research for this article, I found a question pertaining to this function from 2018 on Adobe’s Dreamweaver (Adobe acquired Macromedia in 2005) help forum.

The JavaScript function would swap an image with another image through changing the src attribute based on mouseover and mouseout events. When implemented, it looked something like this:

<a href="#" onMouseOut="MM_swapImgRestore()" onMouseOver="MM_swapImage('ImageName','','newImage.jpg',1)"> <img src="originalImage.jpg" name="ImageName" width="100" height="100" border="0"> </a>

By today’s standards, it would be fairly easy to accomplish this with JavaScript and many of us could practically do this in our sleep. But consider that JavaScript was still this new scripting language at the time (created in 1995) and sometimes looked and behaved differently from browser to browser. Creating cross-browser JavaScript was not always an easy task and not everyone creating web pages even wrote JavaScript. (Though that has certainly changed.) Dreamweaver offered this functionality through a menu in the editor and the web designer didn’t even need to write the JavaScript. It was based around a set of "behaviors" that could be selected from a list of different options. These options could be filtered by a set of targeted browsers; 3.0 browsers, 4.0 browsers, IE 3.0, IE 4.0, Netscape 3.0, Netscape 4.0. Ah, the good old days.

Choosing Behaviors based on browser versions, circa 1997. The Swap Image Behaviors panel in Macromedia Dreamweaver 1.2a

About a year after Dreamweaver was first released, the CSS2 specification from W3C mentioned :hover in a working draft dated January 1998. It was specifically mentioned in terms of anchor links, but the language suggests it could have possibly been applied to other elements. For most purposes it would seem this pseudo selector would be the beginning of an easy alternative to MM_swapImage(), since background-image was in the same draft. Although browser support was an issue as it took years before enough browsers properly supported CSS2 to make it a viable option for many web designers. There was finally a W3C recommendation of CSS2.1, this could be considered to be the basis of "modern" CSS as we know it, which was published in June 2011.

In the middle of all this, jQuery came along in 2006. Thankfully, jQuery went a long way in simplifying JavaScript among the different browsers. One thing of interest for our story, the first version of jQuery offered the animate() method. With this method, you could animate CSS properties on any element at any time; not just on hover. By its sheer popularity, this method exposed the need for a more robust CSS solution baked into the browser — a solution that wouldn’t require a JavaScript library that was not always very performant due to browser limitations.

The :hover pseudo-class only offered a hard swap from one state to another with no support for a smooth transition. Nor could it animate changes in elements outside of something as basic as hovering over an element. jQuery’s animate() method offered those features. It paved the way and there was no going back. As things go in the dynamic world of web development, a working draft for solving this was well underway before the recommendation of CSS2.1 was published. The first working draft for CSS Transitions Module Level 3 was first published by the W3C in March 2009. The first working draft for CSS Animations Module Level 3 was published at roughly the same time. Both of these CSS modules are still in a working draft status as of October 2018, but of course, we are already making heavy use of them

So, what first started as a JavaScript function provided by a third-party, just for a simple hover state, has led to transitions and animations in CSS that allow for elaborate and complex animations — complexity that many developers wouldn’t necessarily wish to consider as they need to move quickly on new projects. We have gone full circle; today many third-party CSS animation libraries have been created to offset this complexity.

Three different types of third-party animation libraries

We are in this new world capable of powerful, exciting, and complex animations in our web pages and apps. Several different ideas have come to the forefront on how to approach these new tasks. It’s not that one approach is better than any other; indeed, there is a good bit of overlap in each. The difference is more about how we implement and write code for them. Some are full-blown JavaScript-only libraries while others are CSS-only collections.

JavaScript libraries

Libraries that operate solely through JavaScript often offer capabilities beyond what common CSS animations provide. Usually, there is overlap as the libraries may actually use CSS features as part of their engine, but that would be abstracted away in favor of the API. Examples of such libraries are Greensock and Anime.js. You can see the extent of what they offer by looking at the demos they provide (Greensock has a nice collection over on CodePen). They’re mostly intended for highly complex animations, but can be useful for more basic animations as well.

JavaScript and CSS libraries

There are third-party libraries that primarily include CSS classes but provide some JavaScript for easy use of the classes in your projects. One library, Micron.js, provides both a JavaScript API and data attributes that can be used on elements. This type of library allows for easy use of pre-built animations that you can just select from. Another library, Motion UI, is intended to be used with a JavaScript framework. Although, it also works on a similar notion of a mixture of a JavaScript API, pre-built classes, and data attributes. These types of libraries provide pre-built animations and an easy way to wire them up.

CSS libraries

The third kind of library is CSS-only. Typically, this is just a CSS file that you load via a link tag in your HTML. You then apply and remove specific CSS classes to make use of the provided animations. Two examples of this type of library are Animate.css and Animista. That said, there are even major differences between these two particular libraries. Animate.css is a total CSS package while Animista provides a slick interface to choose the animations you want with provided code. These libraries are often easy to implement but you have to write code to make use of them. These are the type of libraries this article will focus on.

Three different types of CSS animations

Yes, there’s a pattern; the rule of threes is everywhere, after all.

In most cases, there are three types of animations to consider when making use of third-party libraries. Each type suits a different purpose and has different ways to make use of them.

Hover animations

These animations are intended to be involved in some sort of hover state. They’re often used with buttons, but another possibility is using them to highlight sections the cursor happens to be on. They can also be used for focus states.

Attention animations

These animations are intended to be used on elements that are normally outside of the visual center of the person viewing the page. An animation is applied to a section of the display that needs attention. Such animations could be subtle in nature for things that need eventual attention but not dire in nature. They could also be highly distracting for when immediate attention is required.

Transition animations

These animations are often intended to have an element replace another in the view, but can be used for one element as well. These will usually include an animation for "leaving" the view and mirror animation for "entering" the view. Think of fading out and fading in. This is commonly needed in single page apps as one section of data would transition to another set of data, for example.

So, let’s go over examples of each of these type of animations and how one might use them.

Let’s hover it up!

Some libraries may already be set for hover effects, while some have hover states as their main purpose. One such library is Hover.css, which is a drop-in solution that provides a nice range of hover effects applied via class names. Sometimes, though, we want to make use of an animation in a library that doesn’t directly support the :hover pseudo-class because that might conflict with global styles.

For this example, I shall use the tada animation that Animate.css provides. It’s intended more as an attention seeker, but it will nicely suffice for this example. If you were to look through the CSS of the library, you’ll find that there’s no :hover pseudo-class to be found. So, we’ll have to make it work in that manner on our own.

The tada class by itself is simply this:

.tada { animation-name: tada; }

A low-lift approach to make this react to a hover state is to make our own local copy of the class, but extend it just a bit. Normally, Animate.css is a drop-in solution, so we won’t necessarily have the option to edit the original CSS file; although you could have your own local copy of the file if you wish. Therefore, we only create the code we require to be different and let the library handle the rest.

.tada-hover:hover { animation-name: tada; }

We probably shouldn’t override the original class name in case we actually want to use it elsewhere. So, instead, we make a variation that we can place the :hover pseudo-class on the selector. Now we just use the library’s required animated class along with our custom tada-hover class to an element and it will play that animation on hover.

If you wouldn’t want to create a custom class in this way, but prefer a JavaScript solution instead, there’s a relatively easy way to handle that. Oddly enough, it’s a similar method to the MM_imageSwap() method from Dreamweaver we discussed earlier.

// Let's select elements with ID #js_example var js_example = document.querySelector('#js_example'); // When elements with ID #js_example are hovered... js_example.addEventListener('mouseover', function () { // ...let's add two classes to the element: animated and tada... this.classList.add('animated', 'tada'); }); // ...then remove those classes when the mouse is not on the element. js_example.addEventListener('mouseout', function () { this.classList.remove('animated', 'tada'); });

There are actually multiple ways to handle this, depending on the context. Here, we create some event listeners to wait for the mouse-over and mouse-out events. These listeners then apply and remove the library’s animated and tada classes as needed. As you can see, extending a third-party library just a bit to suit our needs can be accomplished in relatively easy fashion.

Can I please have your attention?

Another type of animation that third-party libraries can assist with are attention seekers. These animations are useful for when you wish to draw attention to an element or section of the page. Some examples of this could be notifications or unfilled required form inputs. These animations can be subtle or direct. Subtle for when something needs eventual attention but does not need to be resolved immediately. Direct for when something needs resolution now.

Some libraries have such animations as part of the whole package, while some are built specifically for this purpose. Both Animate.css and Animista have attention seeking animations, but they are not the main purpose for those libraries. An example of a library built for this purpose would be CSShake. Which library to use depends on the needs of the project and how much time you wish to invest in implementing them. For example, CSShake is ready to go with little trouble on your part — simply apply classes as needed. Although, if you were already using a library such as Animate.css, then you’re likely not going to want to introduce a second library (for performance, reliance on dependencies, and such).

So, a library such as Animate.css can be used but needs a little more setup. The library’s GitHub page has examples of how to go about doing this. Depending on the needs of a project, implementing these animations as attention seekers is rather straightforward.

For a subtle type of animation, we could have one that just repeats a set number of times and stops. This usually involves adding the library’s classes, applying an animation iteration property to CSS, and waiting for the animation end event to clear the library’s classes.

Here’s a simple example that follows the same pattern we looked at earlier for hover states:

var pulse = document.querySelector('#pulse'); function playPulse () { pulse.classList.add('animated', 'pulse'); } pulse.addEventListener('animationend', function () { pulse.classList.remove('animated', 'pulse'); }); playPulse();

The library classes are applied when the playPulse function is called. There’s an event listener for the animationend event that will remove the library’s classes. Normally, this would only play once, but you might want to repeat multiple times before stopping. Animate.css doesn’t provide a class for this, but it’s easy enough to apply a CSS property for our element to handle this.

#pulse { animation-iteration-count: 3; /* Stop after three times */ }

This way, the animation will play three times before stopping. If we needed to stop the animation sooner, we can manually remove the library classes outside of the animationend function. The library’s documentation actually provides an example of a reusable function for applying the classes that removes them after the animation; very similar to the above code. It would even be rather easy to extend it to apply the iteration count to the element.

For a more direct approach, let’s say an infinite animation that won’t stop until after some sort of user interaction takes place. Let’s pretend that clicking the element is what starts the animation and clicking again stops it. Keep in mind that however you wish to start and stop the animation is up to you.

var bounce = document.querySelector('#bounce'); bounce.addEventListener('click', function () { if (!bounce.classList.contains('animated')) { bounce.classList.add('animated', 'bounce', 'infinite'); } else { bounce.classList.remove('animated', 'bounce', 'infinite'); } });

Simple enough. Clicking the element tests if the library’s "animated" class has been applied. If it has not, we apply the library classes so it starts the animation. If it has the classes, we remove them to stop the animation. Notice that infinite class on the end of the classList. Thankfully, Animate.css provides this for us out-of-the-box. If your library of choice doesn’t offer such a class, then this is what you need in your CSS:

#bounce { animation-iteration-count: infinite; }

Here’s a demo showing how this code behaves:

See the Pen
3rd Party Animation Libraries: Attention Seekers
by Travis Almand (@talmand)
on CodePen.

Moving stuff out of the way

When researching for this article, I found that transitions (not to be confused with CSS transitions) are easily the most common type of animations in the third-party libraries. These are simple animations that are built to allow an element to enter or leave the page. A very common pattern seen in modern Single Page Applications is to have one element leave the page while another replaces it by entering the page. Think of the first element fading out and the second fading in. This could be replacing old data with new data, moving to the next panel in a sequence, or moving from one page to another with a router. Both Sarah Drasner and Georgy Marchuk have excellent examples of these types of transitions.

For the most part, animation libraries will not provide the means to remove and add elements during the transition animations. The libraries that provide additional JavaScript may actually have this functionality, but since most do not, we’ll discuss how to handle this functionality now.

Inserting a single element

For this example, we’ll again use Animate.css as our library. In this case, I’ll be using the fadeInDown animation.

Now, please keep in mind there are many ways to handle inserting an element into the DOM and I don’t wish to cover them here. I’ll just be showing how to leverage an animation to make the insertion nicer and more natural than the element simply popping into view. For Animate.css (and likely many other libraries), inserting an element with the animation is quite easy.

let insertElement = document.createElement('div'); insertElement.innerText = 'this div is inserted'; insertElement.classList.add('animated', 'fadeInDown'); insertElement.addEventListener('animationend', function () { this.classList.remove('animated', 'fadeInDown'); }); document.body.append(insertElement);

However you decide to create the element doesn’t much matter; you just need to be sure the needed classes are already applied before inserting the element. Then it’ll nicely animate into place. I also included an event listener for the animationend event that removes the classes. As usual, there are several ways to go about doing this and this is likely the most direct way to handle it. The reason for removing the classes is to make it easier to reverse the process if we wish. We wouldn’t want the entering animation competing with a leaving animation.

Removing a single element

Removing a single element is sort of similar to inserting an element. The element already exists, so we just apply the desired animation classes. Then at the animationend event we remove the element from the DOM. In this example, we’ll use the fadeOutDown animation from Animate.css because it works nicely with the fadeInDown animation.

let removeElement = document.querySelector('#removeElement'); removeElement.addEventListener('animationend', function () { this.remove(); }); removeElement.classList.add('animated', 'fadeOutDown');

As you can see, we target the element, add the classes, and remove the element at the end of the animation.

An issue with all this is that with inserting and removing elements this way will cause the other elements on the page to jump around to adjust. You’ll have to account for that in some way, most likely with CSS and the layout of the page to keep a constant space for the elements.

Get out of my way, I’m coming through!

Now we are going to swap two elements, one leaving while another enters. There are several ways of handling this, but I’ll provide an example that’s essentially combining the previous two examples.

See the Pen
3rd Party Animation Libraries: Transitioning Two Elements
by Travis Almand (@talmand)
on CodePen.

I’ll go over the JavaScript in parts to explain how it works. First, we cache a reference to a button and the container for the two elements. Then, we create two boxes that’ll be swapped inside the container.

let button = document.querySelector('button'); let container = document.querySelector('.container'); let box1 = document.createElement('div'); let box2 = document.createElement('div');

I have a generic function for removing the animation classes for each animationEnd event.

let removeClasses = function () { box1.classList.remove('animated', 'fadeOutRight', 'fadeInLeft'); box2.classList.remove('animated', 'fadeOutRight', 'fadeInLeft'); }

The next function is the bulk of the swapping functionality. First, we determine the current box being displayed. Based on that, we can deduce the leaving and entering elements. The leaving element gets the event listener that called the switchElements function removed first so we don’t find ourselves in an animation loop. Then, we remove the leaving element from the container since its animation has finished. Next, we add the animation classes to the entering element and append it to the container so it’ll animate into place.

let switchElements = function () { let currentElement = document.querySelector('.container .box'); let leaveElement = currentElement.classList.contains('box1') ? box1 : box2; let enterElement = leaveElement === box1 ? box2 : box1; leaveElement.removeEventListener('animationend', switchElements); leaveElement.remove(); enterElement.classList.add('animated', 'fadeInLeft'); container.append(enterElement); }

We need to do some general setup for the two boxes. Plus, we append the first box to the container.

box1.classList.add('box', 'box1'); box1.addEventListener('animationend', removeClasses); box2.classList.add('box', 'box2'); box2.addEventListener('animationend', removeClasses); container.appendChild(box1);

Finally, we have a click event listener for our button that does the toggling. How these sequences of events are started is technically up to you. For this example, I decided on a simple button click. I figure out which box is currently being displayed, which will be leaving, to apply the appropriate classes to make it animate out. Then I apply an event listener for the animationEnd event that calls the switchElements function shown above that handles the actual swap.

button.addEventListener('click', function () { let currentElement = document.querySelector('.container .box'); if (currentElement.classList.contains('box1')) { box1.classList.add('animated', 'fadeOutRight'); box1.addEventListener('animationend', switchElements); } else { box2.classList.add('animated', 'fadeOutRight'); box2.addEventListener('animationend', switchElements); } }

One obvious issue with this example is that it is extremely hard-coded for this one situation. Although, it can be easily extended and adjusted for different situations. So, the example is useful in terms of understanding one way of handling such a task. Thankfully, some animation libraries, like MotionUI, provide some JavaScript to help with element transitions. Another thing to consider is that some JavaScript frameworks, such as VueJS have functionality to assist with animating element transitions.

I have also created another example that provides a more flexible system. It consists of a container that stores references to leave and enter animations with data attributes. The container holds two elements that will switch places on command. The way this example is built is that the animations are easily changed in the data attributes via JavaScript. I also have two containers in the demo; one using Animate.css and the other using Animista for animations. It’s a large example, so I won’t examine code here; but it is heavily commented, so take a look if it is of interest.

See the Pen
3rd Party Animation Libraries: Custom Transition Example
by Travis Almand (@talmand)
on CodePen.

Take a moment to consider...

Does everyone actually want to see all these animations? Some people could consider our animations over-the-top and unnecessary, but for some, they can actually cause problems. Some time ago, WebKit introduced the prefers-reduced-motion media query to assist with possible Vestibular Spectrum Disorder issues. Eric Bailey also posted a nice introduction to the media query, as well as a follow-up with considerations for best practices. Definitely read these.

So, does your animation library of choice support the prefers-reduced-motion? If the documentation doesn’t say that it does, then you may have to assume it does not. Although, it is rather easy to check the code of the library to see if there is anything for the media query. For instance, Animate.css has it in the _base.scss partial file.

@media (print), (prefers-reduced-motion) { .animated { animation: unset !important; transition: none !important; } }

This bit of code also provides an excellent example of how to do this for yourself if the library doesn’t support it. If the library has a common class it uses — like Animate.css uses "animated" — then you can just target that class. If it does not support such a class then you’ll have to target the actual animation class or create your own custom class for that purpose.

.scale-up-center { animation: scale-up-center 0.4s cubic-bezier(0.390, 0.575, 0.565, 1.000) both; } @keyframes scale-up-center { 0% { transform: scale(0.5); } 100% { transform: scale(1); } } @media (print), (prefers-reduced-motion) { .scale-up-center { animation: unset !important; transition: none !important; } }

As you can see, I just used the example as provided by Animate.css and targeted the animation class from Animista. Keep in mind that you’ll have to repeat this for every animation class you choose to use from the library. Although, in Eric’s follow-up piece, he suggests treating all animations as progressive enhancement and that could be one way to both reduce code and make a more accessible user experience.

Let a framework do the heavy lifting for you

In many ways, the various frameworks such as React and Vue can make using third-party CSS animation easier than with vanilla JavaScript, mainly because you don’t have to wire up the class swaps or animationend events manually. You can leverage the functionality the frameworks already provide. The beauty of using frameworks is that they also provide several different ways of handling these animations depending on the needs of the project. The examples below is only a small example of options.

Hover effects

For hover effects, I would suggest setting them up with CSS (as I suggested above) as the better way to go. If you really need a JavaScript solution in a framework, such as Vue, it would be something like this:

<button @mouseover="over($event, 'tada')" @mouseleave="leave($event, 'tada')"> tada </button> methods: { over: function(e, type) { e.target.classList.add('animated', type); }, leave: function (e, type) { e.target.classList.remove('animated', type); } }

Not really that much different than the vanilla JavaScript solution above. Also, as before, there are many ways of handling this.

Attention seekers

Setting up the attention seekers is actually even easier. In this case, we’re just applying the classes we require, again, using Vue as an example:

<div :class="{animated: isPulse, pulse: isPulse}">pulse</div> <div :class="[{animated: isBounce, bounce: isBounce}, 'infinite']">bounce</div>

In the pulse example, whenever the boolean isPulse is true, the two classes are applied. In the bounce example, whenever the boolean isBounce is true the animated and bounce classes are applied. The infinite class is applied regardless so we can have our never-ending bounce until the isBounce boolean goes back to false.

Transitions

Thankfully, Vue’s transition component provides an easy way to use third-party animation classes with custom transition classes. Other libraries, such as React, could offer similar features or add-ons. To make use of the animation classes in Vue, we just implement them in the transition component.

<transition enter-active-class="animated fadeInDown" leave-active-class="animated fadeOutDown" mode="out-in" > <div v-if="toggle" key="if">if example</div> <div v-else key="else">else example</div> </transition>

Using Animate.css, we merely apply the necessary classes. For enter-active, we apply the required animated class along with fadeInDown. For leave-active, we apply the required animated class along with fadeOutDown. During the transition sequence, these classes are inserted at the appropriate times. Vue handles the inserting and removing of the classes for us.

For a more complex example of using third-party animation libraries in a JavaScript framework, explore this project:

See the Pen
KLKdJy
by Travis Almand (@talmand)
on CodePen.

Join the party!

This is a small taste of the possibilities that await your project as there are many, many third-party CSS animation libraries out there to explore. Some are thorough, eccentric, specific, obnoxious, or just straight-forward. There are libraries for complex JavaScript animations such as Greensock or Anime.js. There are even libraries that will target the characters in an element.

Hopefully all this will inspire you to play with these libraries on the way to creating your own CSS animations.

The post Integrating Third-Party Animation Libraries to a Project appeared first on CSS-Tricks.

Categories: Web Technologies

Google Fonts is Adding font-display

Tue, 05/14/2019 - 07:20

Google announced at I/O that their font service will now support the font-display property which resolves a number of web performance issues. If you're hearing cries of joy, that's probably Chris as he punches the air in celebration. He's wanted this feature for some time and suggests that all @font-face blocks ought to consider using the property.

Zach Leatherman has the lowdown:

This is big news—it means developers now have more control over Google Fonts web font loading behavior. We can enforce instant rendering of fallback text (when using font-display: swap) rather than relying on the browser default behavior of invisible text for up to 3 seconds while the web font request is in-flight.

It’s also a bit of trailblazing, too. To my knowledge, this is the first web font host that’s shipping support for this very important font-display feature.

Yes, a big deal indeed! You may recall that font-display instructs the browser how (and kinda when) to load fonts. That makes it a possible weapon to fight fight FOUT and FOIT issues. Chris has mentioned how he likes the optional value for that exact reason.

@font-face { font-family: "Open Sans Regular"; src: url("..."); font-display: optional; }

Oh and this is a good time to remind everyone of Monica Dinculescu’s font-display demo where she explores all the various font-display values and how they work in practice. It’s super nifty and worth checking out.

Direct Link to ArticlePermalink

The post Google Fonts is Adding font-display appeared first on CSS-Tricks.

Categories: Web Technologies

Change Color of SVG on Hover

Mon, 05/13/2019 - 07:44

There are a lot of different ways to use SVG. Depending on which way, the tactic for recoloring that SVG in different states or conditions — :hover, :active, :focus, class name change, etc. — is different.

Let's look at the ways.

Inline SVG

Inline SVG is my favorite way to use SVG anyway, in part because of how easy it is to access and style the SVG.

See the Pen
bJXNyy
by Chris Coyier (@chriscoyier)
on CodePen.

If you're used to working with icon fonts, one thing you might enjoy about them is how easy it is to change the color. You're largely limited to a single color with icon fonts in a way that SVG isn't, but still, it is appealingly easy to change that single color with color. Using inline SVG allows you to set the fill, which cascades to all the elements within the SVG, or you can fill each element separately if needed.

SVG Symbol / Use

There is such thing as an SVG sprite, which is a group of SVGs turned into <symbol> elements such that any given icon can be referenced easily with a <use> element.

See the Pen
Use SVG Hovers
by Chris Coyier (@chriscoyier)
on CodePen.

You can still set the fill color from outside CSS rather easily this way, but there are caveats.

  • The internal SVG elements (like the <path>) can have no fill themselves. This allows the fill set from the parent SVG to cascade into the Shadow DOM created by <use>. As soon as you have something like <path fill="blue" ... /> in the <symbol>, you've lost outside CSS control.
  • Likewise, the fill of individual elements cannot be controlled within the SVG like you could with inline SVG. This means you're pretty firmly in single-color territory. That covers most use cases anyway, but still, a limitation nonetheless.
SVG background images

SVG can be set as a background image just like PNG, JPG, or whatever other graphics format. At this point, you've sort of given up on being able to change the fill. One possibility, which I'd argue isn't a particularly good one, is to have two versions of every icon, in the respective colors, and swap between them:

See the Pen
Background SVG Hovers
by Chris Coyier (@chriscoyier)
on CodePen.

I don't blame you if you'd rather not swap sources, so another possibility is to get gnarly with filters.

See the Pen
Background SVG Hovers with Filters
by Chris Coyier (@chriscoyier)
on CodePen.

Trying to finagle the right filters to get the color right is tricky stuff. Fortunately, Barrett Sonntag made a tool to calculate the filters for you! Turning black to red ends up a whacky combination like this: invert(27%) sepia(51%) saturate(2878%) hue-rotate(346deg) brightness(104%) contrast(97%);.

SVG also has object, which is kinda neat in that it had a built-in fallback back in the day — although browser support is so good these days, I honestly have never used it. But if you're using it, you would probably have to use this filter technique to swap color on hover.

See the Pen
Background SVG Object Hovers
by Chris Coyier (@chriscoyier)
on CodePen.

Use a mask instead of a background image

This way, the SVG is still in charge of essentially drawing the shape, but the color comes from the background-color (or image! or gradient!) behind it rather than the SVG itself.

See the Pen
Background SVG Hovers with Mask
by Chris Coyier (@chriscoyier)
on CodePen.

SVG background images as data URLs

This doesn't change that much from above, but it does open up one interesting possibility: Using a variable for the internal fills. Here that is with Sass keeping the URLs as variables:

See the Pen
Background SVG Hovers with Data URL variables
by Chris Coyier (@chriscoyier)
on CodePen.

You can also do this with native CSS custom properties!

The post Change Color of SVG on Hover appeared first on CSS-Tricks.

Categories: Web Technologies

SVG Properties and CSS

Mon, 05/13/2019 - 07:44

There are many Scalable Vector Graphics (SVG), but only certain attributes can be applied as CSS to SVG. Presentation attributes are used to style SVG elements and can be used as CSS properties. Some of these attributes are SVG-only while others are already shared in CSS, such as font-size or opacity.

For example, to change the color of a <circle> element to red, use the fill property in CSS. The fill attribute is a presentation attribute, therefore it can be used as a CSS property:

circle { fill: red; }

See the Pen
vMqaay
by Geoff Graham (@geoffgraham)
on CodePen.

So, with that, let's take a deep and thorough dive into all of the SVG elements that are available to us as well as the CSS properties for them. We'll also look at various styling approaches, including general presentational styles and animations.

SVG Elements by Category

The presentation attributes that can be used as CSS properties can be found below. For reference, supported elements will be classified by category. This does not include deprecated elements.

Element Type Elements Container elements <a>
<defs>
<g>
<marker>
<mask>
<pattern>
<svg>
<switch>
<symbol> Filter primitive elements <feBlend>
<feColorMatrix>
<feComponentTransfer>
<feComposite>
<feConvolveMatrix>
<feDiffuseLighting>
<feDisplacementMap>
<feFlood>
<feGaussianBlur>
<feImage>
<feMerge>
<feMorphology>
<feOffset>
<feSpecularLighting>
<feTile>
<feTurbulence> Gradient elements <linearGradient>
<radialGradient>
<stop> Graphics elements <circle>
<ellipse>
<image>
<line>
<path>
<polygon>
<polyline>
<rect>
<text>
<use> Shape elements <circle>
<ellipse>
<line>
<path>
<polygon>
<polyline>
<rect> Text content elements <text>
<textPath>
<tspan> Properties shared between CSS and SVG Font properties Presentation attribute Supported elements font Text content elements font-family Text content elements font-size Text content elements font-size-adjust Text content elements font-stretch Text content elements font-style Text content elements font-variant Text content elements font-weight Text content elements Text properties Presentation attribute Supported elements direction <text>
<tspan> letter-spacing Text content elements text-decoration Text content elements unicode-bidi Text content elements word-spacing Text content elements writing-mode <text> Masking properties Presentation attribute Supported elements overflow <foreignObject>
<image>
<marker>
<pattern>
<svg>
<symbol> Interactivity properties Presentation attribute Supported elements cursor Container elements
Graphics elements Color properties Presentation attribute Supported elements color Applies to elements using:
fill
stroke
stop-color
flood-color
lighting-color Visibility properties Presentation attribute Supported elements display Graphics elements
Text content elements
<a>
<foreignObject>
<g>
<svg>
<switch> visibility Graphics elements
Text content elements SVG CSS Properties Text properties Presentation attribute Supported elements alignment-baseline <textPath>
<tspan> baseline-shift <textPath>
<tspan> dominant-baseline Text content elements glyph-orientation-horizontal Text content elements glyph-orientation-vertical Text content elements kerning Text content elements text-anchor Text content elements Clip properties Presentation attribute Supported elements clip <foreignObject>
<image>
<marker>
<pattern>
<svg>
<symbol> clip-path Container elements
Graphics elements clip-rule <clipPath> Masking properties Presentation attribute Supported elements mask Container elements
Graphics elements opacity Graphics elements
<a>
<defs>
<g>
<marker>
<pattern>
<svg>
<switch>
<symbol> Filter effects Presentation attribute Supported elements enable-background Container elements filter Container elements
Graphics elements flood-color <feFlood> flood-opacity <feFlood> lighting-color <feDiffuseLighting>
<feSpecularLighting> Gradient properties Presentation attribute Supported elements stop-color <stop> stop-opacity <stop> Interactivity properties Presentation attribute Supported elements pointer-events Graphics elements Color properties Presentation attribute Supported elements color-profile <image> referring to raster image Painting properties Presentation attribute Supported elements color-interpolation Container elements
Graphics elements color-interpolation-filters Filter primitive elements color-rendering Container elements
Graphics elements fill Shape elements
Text content elements fill-rule Shape elements
Text content elements fill-opacity Shape elements
Text content elements image-rendering <image> marker <line>
<path>
<polygon>
<polyline> marker-start <line>
<path>
<polygon>
<polyline> marker-mid <line>
<path>
<polygon>
<polyline> marker-end <line>
<path>
<polygon>
<polyline> shape-rendering Shape elements stroke Shape elements
Text content elements stroke-dasharray Shape elements
Text content elements stroke-dashoffset Shape elements
Text content elements stroke-linecap Shape elements
Text content elements stroke-linejoin Shape elements
Text content elements stroke-miterlimit Shape elements
Text content elements stroke-opacity Shape elements
Text content elements stroke-width Shape elements
Text content elements text-rendering <text> SVG 2

While presentation attributes can be used as CSS properties to style SVG, what about controlling the coordinates and dimensions of SVG elements using CSS? SVG 2, which is in Candidate Recommendation at the time of this writing, makes it is possible to style and animate these properties.

The SVG 2 specification states:

Some styling properties can be specified not only in style sheets and 'style' attributes, but also in presentation attributes. These are attributes whose name matches (or is similar to) a given CSS property and whose value is parsed as a value of that property."

Not only does it mean that SVG properties can be styled using CSS as presentation attributes or in style sheets, but this also can be applied to CSS pseudo-classes such as :hover or :active.

SVG 2 also introduces more presentation attributes that can be used as styling properties. These attributes can be found in SVG 2 specification.

Element-specific properties

It is important to note that not every SVG element will support the same CSS properties. Much like how there are CSS properties that can be applied to certain SVG elements, there are specific properties that are supported by certain SVG elements.

For example, the <circle>or <ellipse> elements support the cxand cyproperties as coordinates of the center of the shape. The <ellipse> element also supports the rx and ry properties as the radius, but the <circle> element cannot use these properties.

Geometry properties

In SVG 2, properties such as rx and ry are defined as geometry properties. Geometry properties can be used as CSS properties, just like presentation attributes such as fill or stroke properties. These CSS properties and the corresponding SVG elements include:

SVG Element Geometry Property <circle> cx
cy
r <ellipse> cx
cy
rx
ry <rect> rx
ry
height
width
x
y <path> path <image> height
width
x
y <foreignObject> height
width
x
y <svg> code>height
width
x
y Positioning SVG elements

SVG 2 also makes it is possible to position SVG elements using CSS. Let’s begin with drawing a rectangle shape having the following SVG:

<svg width="170" height="170"> <rect x="10" y="10" width="150" height="150" /> </svg>

And the following CSS:

rect { fill: #6e40aa; }

See the Pen
QPeNGj
by Geoff Graham (@geoffgraham)
on CodePen.

This will produce a rectangle shape with its coordinates set to 10, 10. With SVG 2, x and y can be applied as CSS properties:

/* This will work with SVG 2 */ rect { x: 10; y: 10; ... }

The SVG code would be reduced to this:

<svg width="170" height="170"> <rect width="150" height="150" /> </svg>

You can even set the width and height for the <rect> element using CSS like so:

rect { ... width: 150px; height: 150px; ... }

That leaves us with just the following for SVG markup:

<svg width="170" height="170"> <rect /> </svg>

See the Pen
Positioning SVG elements
by Katherine Kato (@kathykato)
on CodePen.

At the time of writing, the following demos will work in Blink (e.g. Chrome and Opera) and WebKit (e.g. Safari) browsers as these browsers support SVG 2 features. Until then, let’s dive into how to override SVG properties using CSS.

SVG shape morphing

The <path> element can be overridden with CSS to create shape morphing.

The SVG paths that morph one into the other must have the same commands and same number of points or else the morphing will not work.

Let’s start with drawing a <path> element in the shape of a triangle. Using the d property will specify the shape of the <path> element:

<svg height="220" width="300"> <path d="M150 10 L40 200 L260 200Z" /> </svg>

To get the triangle to morph into a different shape, let’s override the SVG <path> element with the d property with CSS:

path { d: path("M150, 10 L40, 200 L260, 200Z"); fill: #4c6edb; }

Let’s also add a :active pseudo-class to the <path> property so when the element is clicked, the shape will morph into a square and change its fill color. Let’s also add a transition property to make the shape morphing action appear smooth. Here is the CSS:

path:active { d: path("M150, 10 L40, 200 L260, 200 L260, 200Z"); fill: #4c6edb; transition: all 0.35s ease; }

And the SVG would be:

<svg height="220" width="300"> <path /> </svg>

See the Pen
SVG shape morphing
by Katherine Kato (@kathykato)
on CodePen.

Want another demo? Here is a cool demo from Chris Coyier demonstrating SVG shape morphing on hover!

See the Pen
Simple Path Examples
by Chris Coyier (@chriscoyier)
on CodePen.

Animating SVG properties

SVG properties can be animated using CSS through CSS animations and transitions.

In this demo, we will draw various SVG <circle> elements and create a wave animation. Start by drawing five <circle> elements:

<svg width="350" height="250"> <circle class="shape" /> <circle class="shape" /> <circle class="shape" /> <circle class="shape" /> <circle class="shape" /> </svg>

We’ll be using CSS variables and :nth-child() CSS pseudo-class to define each .shape class. The .shape class will have a cy of 50 and a r of 20. Each of the .shape classes will have their own cx and fill CSS properties set:

:root { --color-1: #6e40aa; --color-2: #4c6edb; --color-3: #24aad8; --color-4: #1ac7c2; --color-5: #1ddea3; } .shape { cy: 50; r: 20; } .shape:nth-child(1) { cx: 60; fill: var(--color-1); } .shape:nth-child(2) { cx: 120; fill: var(--color-2); } .shape:nth-child(3) { cx: 180; fill: var(--color-3); } .shape:nth-child(4) { cx: 240; fill: var(--color-4); } .shape:nth-child(5) { cx: 300; fill: var(--color-5); }

Here is how it should look so far.

See the Pen
Animating SVG properties: Pre-animation
by Geoff Graham (@geoffgraham)
on CodePen.

Now it’s time to animate! Start by using @keyframes rule to define the moveCircle animation:

@keyframes moveCircle { 50% { cy: 150; r: 13; } }

This will get each <circle> element to change their cy coordinates from 50 to 150 and r from 20 to 13. Add the following to the CSS to the .shape class get the animation running infinitely:

.shape { ... animation: moveCircle 1250ms ease-in-out both infinite; }

Finally, add an animation-delay to each of the .shape classes to the CSS with the exception of .shape:nth-child(1) like this:

.shape:nth-child(2) { ... animation-delay: 100ms; } .shape:nth-child(3) { ... animation-delay: 200ms; } .shape:nth-child(4) { ... animation-delay: 300ms; } .shape:nth-child(5) { ... animation-delay: 400ms; }

See the Pen
Animating SVG properties
by Katherine Kato (@kathykato)
on CodePen.

Shapes in SVG <pattern> elements can also be animated using CSS. Here is a cool demo by Dudley Storey showcasing that!

See the Pen
Screen
by Dudley Storey (@dudleystorey)
on CodePen.

Wrapping up

As SVG 1.1 is the current standard, few browsers currently support SVG 2 features. It is not recommended to put these techniques into production yet. SVG 2 implementation is currently at Candidate Recommendation stage, thus support for styling SVG geometry properties with CSS should improve in the future.

The post SVG Properties and CSS appeared first on CSS-Tricks.

Categories: Web Technologies

Deploying a Client-Side Rendered create-react-app to Microsoft Azure

Fri, 05/10/2019 - 12:54

Deploying a React app to Microsoft Azure is simple. Except that... it isn’t. The devil is in the details. If you're looking to deploy a create-react-app — or a similar style front-end JavaScript framework that requires pushState-based routing — to Microsoft Azure, I believe this article will serve you well. We’re going to try to avoid the headaches of client and server side routing reconciliation.

First, a quick story.

Back in 2016, when Donovan Brown, a Senior DevOps Program Manager at Microsoft, had given a "but it works on my machine speech" at Microsoft Connect that year, I was still in my preliminary stages as a web developer. His talk was about micro-services and containers.

[...] Gone are the days when your manager comes running into your office and she is frantic and she has found a bug. And no matter how hard I try, I can't reproduce it and it works perfectly on my machine. She says: fine Donovan, then we are going to ship your machine because that is the only place where it works. But I like my machine, so I'm not going to let her ship it...

I had a similar sort of challenge, but it had to do with routing. I was working on a website with a React front end and ASP.NET Core back end, hosted as two separate projects that were deployed to Microsoft Azure. This meant we could deploy both apps separately and enjoy the benefits that comes with separation of concern. We also know who to git blame if and when something goes wrong. But it had downsides as well, as front-end vs. back-end routing reconciliation was one of those downsides.

One day I pushed some new code to our staging servers. I received a message shortly after telling me the website was failing on page refresh. It was throwing a 404 error. At first, I didn’t think it was my responsibility to fix the error. It had to be some server configuration issue. Turns out I was both right and wrong.

I was right to know it was a server configuration issue (though at the time, I didn’t know it had to do with routing). I was wrong to deny it my responsibility. It was only after I went on a web searching rampage that I found a use case for deploying a create-react-app to Azure under the Deployment tab on the official documentation page.

Building React for production

When building a React app for production (assuming we’re are using create-react-app), it’s worth noting the folders that get generated. Running npm run build will generate a build folder where an optimized static version of the application lives. To get the application on a live server, all we need do is feed the server the content of the build folder. If we were working on localhost, there is no live server involved, so it is not always equivalent to having the application on a live server.

Generally, the build folder will have this structure:

→ build → static → css → css files → js → js files → media → media files → index.html → other files... Client-side routing with React Router

React Router uses the HTML5 pushState history API internally. What pushState does is quite interesting. For example, navigating (or using Link in react router) from the page https://css-tricks.com to the page https://css-tricks.com/archives/ will cause the URL bar to display https://css-tricks.com/archives/ but won't cause the browser to load the page /archives or even check that it exists. Couple this with the component-based model of React, it becomes a thing to change routes while displaying different pages based on those routes — without the all-seeing eye of the server trying to serve a page in its own directory. What happens, then, when we introduce servers by pushing the code to a live server? The docs tell it better:

If you use routers that use the HTML5 pushState history API under the hood (for example, React Router with browserHistory), many static file servers will fail. For example, if you used React Router with a route for /todos/42, the development server will respond to localhost:3000/todos/42 properly, but an Express serving a production build as above will not. This is because when there is a fresh page load for a /todos/42, the server looks for the file build/todos/42 and does not find it. The server needs to be configured to respond to a request to /todos/42 by serving index.html.

Different servers require different configuration. Express, for example, requires this:

app.get('*', (req, res) => { res.sendFile(path.resolve(__dirname, 'client', 'build', 'index.html')); });

...as documented in the create-react-app docs. Keep in mind though, this assumes that we’re hosting create-react-app at the server root, which is making use of a wildcard route (*) that catches all route and respond to all route request by serving the index.html file in the build folder which sits at the root of the server application. Also, this is tightly coupled with the back-end. If that’s the case, we would most likely have this kind of folder structure (assuming the back-end is in NodeJS):

→ Server → Client (this is where your react code goes) → build (this is the build folder, after you npm run build) → src → node_modules → package.json → other front-end files and folders → Other back-end files and folders

Since my front-end (create-react-app) and back-end (ASP.NET) were two different projects, serving static files by navigating the directory was sort of an impossibility.

In fact, since we are deploying a static app, we do not need the back-end. As Burke Holland put it: "Static" means that we aren’t deploying any server code; just the front-end files.

I keep mentioning ASP.NET here because during the course of my research, I figured configuring Azure required a configuration file in a wwwroot folder and ASP.NET's folder structure typically has a wwwroot folder. Remember the application’s back-end was in ASP.NET? But that’s just about it. The wwwroot folder seemed to be hidden somewhere on Azure. And I can’t show you without deploying a create-react-app. So let’s go do that.

Getting started with App Services on Microsoft Azure

To get started, if you do not already have a Azure account, get a free trial then head over to the Azure portal.

  1. Navigate to All services → Web → App Services
    Navigating on the Azure portal from All services, to Web, to App services

  2. We want to add a new app, give it a name, subscription (should be free if you’re on a free trial, or if you already have one), resource group (create one or use existing), then click on the Create button down at the bottom of the panel.
    Creating a new App service on the Azure portal.
  3. We should get a notification that the resource has been created. But it won’t immediately show up, so hit "Refresh" — I have other resources, but the AzureReactDemo2 is what I’m using here. You’ll click on the name of your newly created app, which is AzureReactDemo2 in my case.
    Displaying all App Services on the Azure portal.
  4. The blade shows you information about your app, the navigation to the left has everything you need to manage your application (overview, activity log, deployment center...).

For example, the Deployment Center is where the app deployment is managed, Slots is where things like staging, production, test are managed. Configuration is where things like environmental variables, node versions and — an important one — Kudu are managed.

The overview screen shows a general view of the application Status, URL... Click on the URL to see the live site.

Showing the various parts of an App Service on the Azure CLI.

The app is up and running!

Showing the default live page of an App Service.

What we’ve done is create a new App Service, but we have none of our code on Azure yet. As said earlier, all we need to do is to feed Azure the content of the build folder generated by building React for production, but we don’t have one yet. So let’s go local and get some React app.

Going local

We need to create a new React app, and install react-router as a dependency.

npx create-react-app azure-react-demo cd azure-react-demo

We also want to install react-router (react-router-dom, actually)

npm i react-router-dom

All things being equal, starting the app with npm start, we should get the default page.

Showing the default page generated by React.

Because this will be about testing routes, I needed to make some pages. I’ve modified my local version and uploaded it to GitHub. I’m banking on the fact that you can find your way around react and react-router. Download a demo.

My folder looks like this:

Showing the folders and files in the modified create-react-app app.

The changed files have the following code:

// App.js import React, { Component } from "react"; import "./App.css"; import Home from "./pages/Home"; import Page1 from "./pages/Page1"; import Page2 from "./pages/Page2"; import { BrowserRouter as Router, Switch, Route } from "react-router-dom"; class App extends Component { render() { return ( <Router> <Switch> <Route exact path="/" component={Home} /> <Route path="/page1" component={Page1} /> <Route path="/page2" component={Page2} /> </Switch> </Router> ); } } export default App; // Page1.js import React from "react"; import { Link } from "react-router-dom"; const Page1 = () => { return ( <div className="page page1"> <div className="flagTop" /> <div className="flagCenter"> <h1 className="country">Argentina (PAGE 1)</h1> <div className="otherLinks"> <Link to="/page2">Nigeria</Link> <Link to="/">Home</Link> </div> </div> <div className="flagBottom" /> </div> ); }; export default Page1; // Page2.js import React from "react"; import { Link } from "react-router-dom"; const Page2 = () => { return ( <div className="page page2"> <div className="flagTop" /> <div className="flagCenter"> <h1 className="country">Nigeria (PAGE 2)</h1> <div className="otherLinks"> <Link to="/page1">Argentina</Link> <Link to="/">Home</Link> </div> </div> <div className="flagBottom" /> </div> ); }; export default Page2; /* App.css */ html { box-sizing: border-box; } body { margin: 0; } .page { display: grid; grid-template-rows: repeat(3, 1fr); height: 100vh; } .page1 .flagTop, .page1 .flagBottom { background-color: blue; } .page2 .flagTop, .page2 .flagBottom { background-color: green; } .flagCenter { display: flex; align-items: center; flex-direction: column; justify-content: center; text-align: center; } .page a { border: 2px solid currentColor; font-weight: bold; margin: 0 30px; padding: 5px; text-decoration: none; text-transform: uppercase; } .flags { display: flex; width: 100%; } .flags > .page { flex: 1; }

Running the app works locally, so the routes deliver when links are clicked and even when the page is refreshed.

Deploy the app to Azure

Now, let’s get it up on Azure! There are a few steps to make this happen.

Step 1: Head to the Deployment Center

On Azure, we need to go to the Deployment Center. There are quite a few options each with its pros and cons. We’ll be using Local Git (which means your local git app straight directly to Azure) for source control, Kudu for Build Provider.

Remember to click continue or finish when you select an option, or else, the portal will just keep staring at you.

Showing Deployment Center on the Azure portal and choosing a source control as the first step in deploying a new App Service. Showing the Build Provider section in the Deployment Center on Azure portal.

After the third step, Azure generates a local git repo for you. And it gives you a remote link to point your react app to.

One thing to note at this point. When you push, Azure will ask for your GitHub credentials. It is under the deployment tab. There are two: App and User. App credential will be specific to an app. User will be general to all the apps you as a user has Read/Write access to. You can do without User Credentials and use App credentials, but I find that after a while, Azure stops asking for credentials and just tells me authentication failed automatically. I set a custom User Credentials. Either way, you should get past that.

Showing the Deployment Credentials for the App Service on Azure portal.

In the React app, after modification, we need to build for production. This is important because what we want to upload is the content of the build folder.

We need to tell Kudu what node engine we’ll be using, or else, the build will most likely fail,
due to the reported fact that react-scripts requires a node version higher than the default set on Azure. There are other ways to do that, but the simplest is to add a nodes engine in package.json. I’m using version 10.0 here. Unfortunately, we can’t just add what we like, since Azure has Node versions it supports and the rest are unsupported. Check that with the CLI with the command: az webapp list-runtimes

Add the preferred node version to the package.json file, as in:

"engines": { "node": "10.0" } Displaying a list of Azure runtimes in the Azure CLI. Step 2: Build the App

To build the React app, let’s run npm build in the Terminal.

Step 3: Initialize the Git repo

Navigate into the build folder and initialize a Git repo in there. The URL to clone the repo is in the overview page. Depending on what credentials you’re using (App or User), it will be slightly different.

Showing the overview of the App Service on Azure and the Git clone URL. git init git add . git commit -m "Initial Commit" git remote add azure <git clone url> git push azure master

Now, visit the live app by using the URL on the overview page. As you can see, the app fails on /page2 refresh. Looking at the network tab, a 404 is thrown because the page tried to be fetched from the server — with client-side routing, as we have already set up, the page shouldn’t even be server fetched at all.

Showing the failed page request and the network tab to verify. Configuring Azure to reconcile client and server side routing

In the public folder, let’s add a web.config XML file with the following content:

<?xml version="1.0"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="React Routes" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> <add input="{REQUEST_URI}" pattern="^/(api)" negate="true" /> </conditions> <action type="Rewrite" url="/" /> </rule> </rules> </rewrite> </system.webServer> </configuration>

I’ve intentionally decided to not format the code snippet because XML is strict about that. If you miss the formatting, the file has no effect. You can download an XML formatter for your text editor. For VSCode, that would be the XML Tools plugin.

Showing an XML formatter and an XML formatted file in VSCode.

The app can be built again at this point, although we’ll lose the Git info in the build folder since the new build overrides the old build. That means it would have to be added again, then pushed.

Now the app works as shown below! Whew.

We don’t want to have to npm run build every time — that’s where continuous deployment comes in. Check out the link below for appropriate references.

Conclusion

There is a lot to Azure, as it can do a lot for you. That’s nice because there are times when you need it to do something that seems super specific — as we’ve seen here with client and server side routing reconciliation — and it already has your back.

That said, I’ll leave you with a couple of related resources you can turn to as you look to deploying a React app to Azure.

The post Deploying a Client-Side Rendered create-react-app to Microsoft Azure appeared first on CSS-Tricks.

Categories: Web Technologies

Weekly Platform News: Feature Policy, Signed Exchanges, iOS browsers

Fri, 05/10/2019 - 07:22

&#x1f44b; Hey folks! This is the first edition of a new weekly update we'll be posting that covers timely news at the intersection of development standards and the tools that make them available on the web. We often talk about the pace of change in our industry. It's fast and touches everything from the HTML, CSS and JavaScript we write to the landscape of browsers that renders them. Please help us welcome Šime Vidas, who will be keeping us all on the up and up with curated updates from his own blog of regular development updates, webplatform.news.

Feature Policy in Chrome

Andrew Betts: Websites can use the HTTP Feature-Policy response header to prevent third parties from secretly using powerful features such as geolocation, and to disable certain bad practices (e.g. document.write, parser-blocking JavaScript, un-optimized images).

This allows good practices to be more easily rewarded. … Search results could be badged with some approving "fast" logomark or (more controversially perhaps) get a higher result ranking if they disallow themselves certain policy-controlled behaviors.

Feature Policy is an emerging technology. See featurepolicy.info for more information about individual policies and their level of support in browsers.

Signed exchanges on Google Search

The mobile version of Google Search includes AMP results on search results pages. When the user taps on an AMP result, the AMP page loads from Google’s domain (google.com) and is displayed in the AMP Viewer.

Google Search now supports an alternative: If a website signs its AMP pages, and the visitor uses Chrome for Android, then tapping on an AMP result instead loads the signed version of the AMP page from Google’s servers, but to the user it appears as if they have navigated to the website normally.

The technology that enables this is called Signed HTTP Exchanges (SXG). See the announcement on Google Webmaster Central Blog for more details. The specification describes the following use case:

In order to speed up loading but still maintain control over its content, an HTML page in a particular origin "O.com" could tell clients to load its sub-resources from an intermediate content distributor that’s not authoritative, but require that those resources be signed by "O.com" so that the distributor couldn’t modify the resources.

Websites can add support for signed exchanges by running AMP Packager on the server side. Cloudflare has launched a free feature called "AMP Real URL" that fully automates the signing process for AMP pages served from its CDN.

Alternative iOS browsers

Henrik Joreteg: On iOS, several important APIs are limited to Safari and are not available in any of the alternative iOS browsers. These include service workers, web payments, and camera access.

Chrome on iOS is such a pain. A surprising number of people seem to use it and no one realizes it's not actually Chrome but just a crippled webkit webview missing major features:

1. No Service Worker
2. Can't print or save as PDF
3. No support for GetUserMedia

Why is this OK?!

— Henrik Joreteg (@HenrikJoreteg) March 30, 2019

Chrome for iOS supports web payments via a custom implementation. I’ve created a browser support table on HTML5test that highlights the differences between some of the popular iOS browsers.

The post Weekly Platform News: Feature Policy, Signed Exchanges, iOS browsers appeared first on CSS-Tricks.

Categories: Web Technologies

CSS-Tricks Chronicle XXXV

Thu, 05/09/2019 - 17:55

I like to do these little roundups of things going on with myself, this site, and the other sites that are part of the CSS-Tricks family.

I spoke at Smashing Conf San Francisco.

There's a video! I can't embed it here because of privacy settings or something, so here's a link to the Vimeo.

It's an evolution of my "How To Think Like A Front-End Developer" talk. That's kinda how I like to roll with talks. Give the same one for about a year, but every time it's different as I learn more.

I was on the One Month podcast.

Chris Castiglione and I chat about:

  • How Chris Coyier learned to code
  • What’s a front-end developer?
  • What resources does Chris Coyier use to stay up to date on web dev?
  • Lessons learned from over 300+ episodes of the ShopTalkShow Podcast

There's a full transcript available.

We've released a number of new things on CodePen.

Quick hits:

And, as always on CodePen, we have a new CodePen Challenge, a new CodePen Spark (newsletter), and a new CodePen Radio (podcast) every single week.

I'm speaking at some upcoming conferences. The front-end conference website got some upgrades.

We keep a list of all conferences out there related to the topics we write about here on CSS-Tricks! All things front-end web design and development!

It's a little 11ty site on Netlify, where you can contribute to anytime — particularly by adding conferences that fit the vibe that you know about.

Notably, every conference listed has a permalink (example). We did that so we could play around with dynamically generating images for them. It's super basic right now, but it was fun to play with. Dynamic CMS data is fed into an SVG, then also converted to a PNG at build time. Fancy. My hope is to upgrade the CMS to allow for cool custom backgrounds for each conference and then use them in these generated graphics.

Also, each conference has a little button where you can email it to somebody via Netlify functions, like we wrote about.

Jobs are $100 off in May

You know we have a Job Board here on CSS-Tricks. It's powered by the CodePen Job Board, which also powers the ShopTalk Show Job Board.

The price of posting a job is reduced from $299 to $199 just in May and runs for 60 days instead of 30.

Post one!

Dave and I have talked with people like Heydon Pickering, Jessica Ivins, Scott Jehl, and Guillermo Rauch on ShopTalk Show.

It's a great podcast, really ;). You should subscribe.

I bought a new bike!

A Specialized Vado (eBike). Cool right?

The trip from my house to work is a short bike ride, but it's a fairly dramatic elevation change, and my big ass is not capable of hauling itself up there. It's much easier with this, even with a couple of loaded saddlebags and a toddler on the back of it.

The post CSS-Tricks Chronicle XXXV appeared first on CSS-Tricks.

Categories: Web Technologies

The Thinking Behind Simplifying Event Handlers

Thu, 05/09/2019 - 07:24

Events are used to respond when a user clicks somewhere, focuses on a link with their keyboard, and changes the text in a form. When I first started learning JavaScript, I wrote complicated event listeners. More recently, I've learned how to reduce both the amount of code I write and the number of listeners I need.

Let’s start with a simple example: a few draggable boxes. We want to show the user which colored box they dragged.

<section> <div id="red" draggable="true"> <span>R</span> </div> <div id="yellow" draggable="true"> <span>Y</span> </div> <div id="green" draggable="true"> <span>G</span> </div> </section> <p id="dragged">Drag a box</p>

See the Pen
Dragstart events
by Tiger Oakes (@NotWoods)
on CodePen.

The intuitive way to do it

I wrote separate event listener functions for each element when I first started learning about JavaScript events. It’s a common pattern because it's the simplest way to start. We want specific behavior for each element, so we can use specific code for each.

document.querySelector('#red').addEventListener('dragstart', evt => { document.querySelector('#dragged').textContent = 'Dragged red'; }); document.querySelector('#yellow').addEventListener('dragstart', evt => { document.querySelector('#dragged').textContent = 'Dragged yellow'; }); document.querySelector('#green').addEventListener('dragstart', evt => { document.querySelector('#dragged').textContent = 'Dragged green'; }); Reducing duplicate code

The event listeners in that example are all very similar: each function displays some text. This duplicate code can be collapsed into a helper function.

function preview(color) { document.querySelector('#dragged').textContent = `Dragged ${color}`; } document .querySelector('#red') .addEventListener('dragstart', evt => preview('red')); document .querySelector('#yellow') .addEventListener('dragstart', evt => preview('yellow')); document .querySelector('#green') .addEventListener('dragstart', evt => preview('green'));

This is much cleaner, but it still requires multiple functions and event listeners.

Taking advantage of the Event object

The Event object is the key to simplifying listeners. When an event listener is called, it also sends an Event object as the first argument. This object has some data to describe the event that occurred, such as the time the event happened. To simplify our code, we can use the evt.currentTarget property where currentTarget refers to the element that the event listener is attached to. In our example, it will be one of the three colored boxes.

const preview = evt => { const color = evt.currentTarget.id; document.querySelector('#dragged').textContent = `Dragged ${color}`; }; document.querySelector('#red').addEventListener('dragstart', preview); document.querySelector('#yellow').addEventListener('dragstart', preview); document.querySelector('#green').addEventListener('dragstart', preview);

Now there is only one function instead of four. We can re-use the exact same function as an event listener and evt.currentTarget.id will have a different value depending on the element that fires the event.

Using bubbling

One final change is to reduce the number of lines in our code. Rather than attaching an event listener to each box, we can attach a single event listener to the <section> element that contains all the colored boxes.

An event starts off at the element where the event originated (one of the boxes) when it is fired. However, it won't stop there. The browser goes to each parent of that element, calling any event listeners on them This will continue until the root of the document is reached (the <body> tag in HTML). This process is called "bubbling" because the event rises through the document tree like a bubble.

Attaching an event listener to the section will cause the focus event to bubble from the colored box that was dragged up to the parent element. We can also take advantage of the evt.target property, which contains the element that fired the event (one of the boxes) rather than the element that the event listener is attached to (the <section> element).

const preview = evt => { const color = evt.target.id; document.querySelector('#dragged').textContent = `Dragged ${color}`; }; document.querySelector('section').addEventListener('dragstart', preview);

Now we’ve reduced many event listeners to just one! With more complicated code, the effect will be greater. By utilizing the Event object and bubbling, we can tame JavaScript events and simplify code for event handlers.

What about click events?

evt.target works great with events like dragstart and change, where there are only a small number of elements that can receive focus or have input changed.

However, we usually want to listen for click events so we can respond to a user clicking on a button in an application. click events fire for any element in the document, from large divs to small spans.

Let’s take our draggable color boxes and make them clickable instead.

<section> <div id="red" draggable="true"> <span>R</span> </div> <div id="yellow" draggable="true"> <span>Y</span> </div> <div id="green" draggable="true"> <span>G</span> </div> </section> <p id="clicked">Clicked a box</p> const preview = evt => { const color = evt.target.id; document.querySelector('#clicked').textContent = `Clicked ${color}`; }; document.querySelector('section').addEventListener('click', preview);

See the Pen
Click events: Not quite working
by Tiger Oakes (@NotWoods)
on CodePen.

When testing this code, notice that sometimes nothing is appended to “Clicked” instead of when clicking on a box. The reason that it doesn't work is that each box contains a <span> element that can be clicked instead of the draggable <div> element. Since the spans don’t have a set ID, the evt.target.id property is an empty string.

We only care about the colored boxes in our code. If we click somewhere inside a box, we need to find the parent box element. We can use element.closest() to find the parent closest to the clicked element.

const preview = evt => { const element = evt.target.closest('div[draggable]'); if (element != null) { const color = element.id; document.querySelector('#clicked').textContent = `Clicked ${color}`; } };

See the Pen
Click events: Using .closest
by Tiger Oakes (@NotWoods)
on CodePen.

Now we can use a single listener for click events! If element.closest() returns null, that means the user clicked somewhere outside of a colored box and we should ignore the event.

More examples

Here are some additional examples to demonstrate how to take advantage of a single event listener.

Lists

A common pattern is to have a list of items that can be interacted with, where new items are inserted dynamically with JavaScript. If we have event listeners attached to each item, then y\our code has to deal with event listeners every time a new element is generated.

<div id="buttons-container"></div> <button id="add">Add new button</button> let buttonCounter = 0; document.querySelector('#add').addEventListener('click', evt => { const newButton = document.createElement('button'); newButton.textContent = buttonCounter; // Make a new event listener every time "Add new button" is clicked newButton.addEventListener('click', evt => { // When clicked, log the clicked button's number. document.querySelector('#clicked').textContent = `Clicked button #${newButton.textContent}`; }); buttonCounter++; const container = document.querySelector('#buttons-container'); container.appendChild(newButton); });

See the Pen
Lists: no bubbling
by Tiger Oakes (@NotWoods)
on CodePen.

By taking advantage of bubbling, we can have a single event listener on the container. If we create many elements in the app, this reduces the number of listeners from n to two.

let buttonCounter = 0; const container = document.querySelector('#buttons-container'); document.querySelector('#add').addEventListener('click', evt => { const newButton = document.createElement('button'); newButton.dataset.number = buttonCounter; buttonCounter++; container.appendChild(newButton); }); container.addEventListener('click', evt => { const clickedButton = evt.target.closest('button'); if (clickedButton != null) { // When clicked, log the clicked button's number. document.querySelector('#clicked').textContent = `Clicked button #${clickedButton.dataset.number}`; } }); Forms

Perhaps there’s a form with lots of inputs, and we want to collect all the user responses into a single object.

<form> <label>Name: <input name="name" type="text"/></label> <label>Email: <input name="email" type="email"/></label> <label>Password: <input name="password" type="password"/></label> </form> <p id="preview"></p> let responses = { name: '', email: '', password: '' }; document .querySelector('input[name="name"]') .addEventListener('change', evt => { const inputElement = document.querySelector('input[name="name"]'); responses.name = inputElement.value; document.querySelector('#preview').textContent = JSON.stringify(responses); }); document .querySelector('input[name="email"]') .addEventListener('change', evt => { const inputElement = document.querySelector('input[name="email"]'); responses.email = inputElement.value; document.querySelector('#preview').textContent = JSON.stringify(responses); }); document .querySelector('input[name="password"]') .addEventListener('change', evt => { const inputElement = document.querySelector('input[name="password"]'); responses.password = inputElement.value; document.querySelector('#preview').textContent = JSON.stringify(responses); });

See the Pen
Forms: no bubbling
by Tiger Oakes (@NotWoods)
on CodePen.

Let's switch to a single listener on the parent <form> element instead.

let responses = { name: '', email: '', password: '' }; document.querySelector('form').addEventListener('change', evt => { responses[evt.target.name] = evt.target.value; document.querySelector('#preview').textContent = JSON.stringify(responses); }); Conclusion

Now we know how to take advantage of event bubbling and the event object to simplify complex jumbles of event handlers into just a few… and sometimes down to just one! Hopefully this article has helped you think about your event handlers in a new light. I know this was a revelation to me after I’d spent my early development years writing duplicative code to accomplish the same thing.

The post The Thinking Behind Simplifying Event Handlers appeared first on CSS-Tricks.

Categories: Web Technologies

A responsive grid layout with no media queries

Thu, 05/09/2019 - 07:23

Andy Bell made a really cool demo that shows us how to create a responsive grid layout without any media queries at all. It happens to look like this when you change the size of the browser window:

I think this is a wonderful layout technique that’s just 6 lines (!) of CSS.

.auto-grid { --auto-grid-min-size: 16rem; display: grid; grid-template-columns: repeat(auto-fill, minmax(var(--auto-grid-min-size), 1fr)); grid-gap: 1rem; }

What this shows us is that we don’t have to write a million media queries to change the number of columns in a grid. Andy also proves that CSS Grid can automate so much of the tedious work of styling layouts.

I’ve seen this technique used in a couple of places (and we have a few starter grid templates to boot) but Andy’s article about how it all works finally made it all sink in just how useful grid is.

Direct Link to ArticlePermalink

The post A responsive grid layout with no media queries appeared first on CSS-Tricks.

Categories: Web Technologies

The Impact of Team Collaboration and Communication on Projects

Thu, 05/09/2019 - 07:22

(This is a sponsored post.)

The CSS-Tricks team was cracking up the other day when Miranda introduced us to something called "swoop and poop." That was a new term for most of us, but tell me if you've ever experienced this for yourself.

The idea is that someone in an organization — usually someone higher up on the chain, like a manager or director — has had no involvement in a project but "swoops" into a review session for it (like a team demo) and "poops" all over the work that's been done. You know, things like colors in the design, why we're using this framework versus that, or any number of various things that pay no mind to the scope of the project or the meeting. And it's not like anyone want to push back on a HiPPO.

We then all turned to Chris because, well, case in point. Just kidding!

The thing about "swoop and poop" is that it's totally avoidable. Sure, it's a funny thing to say and there's a lot of truth in it, but the issue really comes down to a lack of transparency and communication.

That's where a system like monday.com can swoop in and make things shine. It's a project management platform that's more than project management. It has all the time tracking, milestones, calendars and task lists that you might expect, but there's a lot more to help facilitate better collaboration and communication among — not just the immediate team members of a project — but everyone across the organization.

We're talking about things like shared assets, comments and chat to help everyone on the team communicate better. Even better, monday.com puts all of these things in a central place so everyone has access to it. And if you feel out of the loop on a project, simply check your personalized news feed to catch up on all the latest activity for the things that directly affect your work.

That's exactly the sort of remedy that prevents any ol' person from swooping into a meeting and dropping bombs all over the work. By capturing important details, assets, decisions, discussions, budgets and everything else you could ever need on a project, monday.com makes it tough to be out of the loop, which leads to better team collaboration and communication.

Try monday.com and experience the difference better communication makes. It's free to sign up, so go ahead and give it a spin.

Get Started

Direct Link to ArticlePermalink

The post The Impact of Team Collaboration and Communication on Projects appeared first on CSS-Tricks.

Categories: Web Technologies

A CSS Golfing Exercise

Mon, 05/06/2019 - 07:32

Code golfing is a type of programming where the goal is to accomplish a task using as few bytes as possible. CSSBattle is a code golfing battleground where players complete to recreate target images using CSS and HTML.

The rules are fairly simple:

  • No external resources (sorry, no <img src="the-solution.png">)
  • Your solution must render correctly in Chrome (just for scoring purposes)

This can be a pretty fun departure from day-to-day front-end work. There’s no need to worry about maintainability, semantics, performance, accessibility, or anything other than making a thing really, really small and still render correctly.

A golf solution in 12 attempts

This type of thinking is a pretty dramatic departure from how most of us are writing front-end code for production sites (I hope!), so I’ve been posting all of my solutions on GitHub in an effort to both share some knowledge and learn from others. As a fortunate side effect, it also means there’s a fairly detailed history of my submissions.

Here’s a start-to-finish account of my attempts CSSBattle’s 7th target, which looks like this:

CSSBattle Target #7 — Leafy Trail The "just center the dang thing" method

A reasonable first approach is to simply stick an element in the middle of the page, slap a box shadow and a border radius on it, and call it done. If we were writing this "for real," it might look like this:

<!DOCTYPE html> <html> <head> <style> body { background: #0B2429; margin: 0; } .leaf { width: 150px; height: 150px; border-radius: 67% 0; background: #F3AC3C; margin: 75px 0 75px 175px; box-shadow: -50px 0 #998235, -100px 0 #1A4341 } </style> </head> <body> <div class="leaf"/> </body> </html>

But that’s 423 bytes! That won’t do for CSS golf, so let’s see what we can remove.

Attempt 1: 144 bytes <p style="margin:75 167;height:150;width:150;border-radius:67%0;box-shadow:-50px 0#998235,-100px 0#1A4341,0 0 0 5in #0B2429;background:#F3AC3C">

Here’s a golfed version. There’s definitely some weirdness going on here — no <!DOCTYPE>, no <html>, no <body>, no nothin’. The browser doesn’t need them (and, in fact, inserts them for us), so we save a lot of bytes by leaving them out. We’re using <p> instead of <div> since it’s shorter, and we don’t close the tag at all since it’s not required for things to render.

The CSS itself isn’t much different, aside from the fact that we’ve used a huge box shadow instead of a background on the body element ("background" is long so avoiding it can be beneficial). It’s also inlined in the element since a <style></style> tag costs extra bytes.

You may have noticed that we used 5in for the spread in our last box shadow. Playing with weird units is a huge part of CSS golfing. In this case, we just need the shadow to cover the 400x300 canvas and ‘5in' (480px) is shorter than any pixel value.

Attempt 2: 141 bytes <p style=margin:75+167;height:150;width:150;border-radius:67%0;box-shadow:-50px+0#998235,-100px+0#1A4341,0+0+0+5in#0B2429;background:#F3AC3C>

This introduces a pretty important golfing trick: replacing spaces with plus signs allows us to remove the quotes around attributes, saving a couple bytes. I’m not totally sure why this works. Someone suggested it may be related to this part of the HTML spec. If you have a better answer, please let me know!

This attempt also cleans up a couple of whitespace mistakes from the last attempt.

Attempt 3: 126 bytes <body bgcolor=F3AC3C style=margin:75+75+75+175;border-radius:67%+0;box-shadow:-50px+0#998235,-100px+0#1A4341,0+0+0+5in#0B2429>

Using a <body> tag instead of a <p> means that:

  • We no longer spend bytes setting height or width on a paragraph
  • We get access to bgcolor

bgcolor is a deprecated attribute that comes up often in CSS golf solutions. It only works on a few tags (<body> included), and does two great things:

  • Saves us from spending bytes on "background:"
  • Saves us a byte by allowing us to omit # in hex colors. Additionally, if a color ends in one or two zeros, we can remove them and it will still render correctly. For example, FFFF00 is the same as FFFF.

There’s a golf regression in this iteration! Can you spot it?

The "border" method

By this point, I had spent quite a few hours tinkering on and off with this target and was getting pretty stuck. Fortunately, CSSBattle has a friendly community on Spectrum that is more than willing to lend a hand.

At the time, Praveen held the #1 spot with two bytes fewer than I had managed, so I asked for some help. He suggested leveraging both the <body> and <html> elements to position everything while using borders in place of a background color.

Attempt 4: 126 bytes <style>*{border-radius:67%+0;border:75px solid#F3AC3C;margin:0 50;box-shadow:-50px 0#998235,-100px 0#1A4341,0 0 0 5in#0B2429

This is a pretty huge departure from our last strategy. Our body tag is gone and we’re using <style>*{ to target the <html> and <body> tags that the browser inserts for us. The combination of margin and border nudges our shape exactly where it needs to be, and the box-shadow on <body> covers all the excess stuff you’d see from styling on <html>.

This was tough for me to grok, but Praveen made a diagram that explains things pretty well. Here’s a prettied up version:

Margins and borders on <html> and <body>

a and b are the margin and border on <html>, and c is the margin on <body>. The right margin on <body> doesn’t do anything since there’s no room to push the <body> to the left and it already has zero width.

Once our box shadows are applied, b is covered up and all that’s left is our target image.

There are still some optimizations missing here though. Dorus van den Oord was able to take the border method down to a lean 121 bytes, offering this cryptic bit of advice:

small hint for getting to that 121: What if you could move an element by a quarter of a ...?

Attempts 5 and 6: 122 bytes <style>*{border-radius:67%+0;border:75px solid#F3AC3C;margin:0 50;box-shadow:-53q 0#998235,-25vw 0#1A4341,0 0 0 5in#0B2429

Turns out all we needed was a unit hardly anyone’s ever heard of (q) (and the humble vw). Having to write "px" is rarely correct in CSS golf, so it’s something to be on the lookout for. Here, we can replace 100px with 25vw and 50px with 53q.

A q, or quarter-millimeter, is exactly that — 1/4th of a millimeter, or just under a pixel. The q unit is a staple of CSS golf as one of two values (the other being %) that require just one byte to express. I’ve combined my 5th and 6th attempts here since both were just unit tweaks. We’re still a byte off from 121 though!

Attempt 7: 121 bytes <style>*{border-radius:67%0;border:75px solid#F3AC3C;margin:0 50;box-shadow:-53q 0#998235,-25vw 0#1A4341,0 0 0 5in#0B2429

We finally fixed that regression from the third attempt, thanks to a pull request from Praveen. A percentage doesn’t need a space between it and subsequent values, so we can save a byte in our border-radius. This is a great example of how sharing code can help everyone involved. I had been stuck on this for a pretty dang long time.

The "funky margin" method

Borders aren’t the only approach, though! Enter Rasmus Fløe’s funky margin:

I got 123 chars on #7 by using box-shadow and a funky margin:75 400 75-150 :)

Attempt 8: 120 bytes <body bgcolor=0B2429 style=border-radius:67%0;margin:75+400+75-150;box-shadow:86mm+0#F3AC3C,73mm+0#998235,75vh+0#1A4341>

Here’s how this works, as Rasmus explains it:

positive right margin pushes it off canvas to the left — and negative left margin stretches the element to the wanted width :)

Here it is drawn out:

The Rasmus Fløe "funky margin" method

The right margin (b) pushes the <body> element all the way to the left, collapsing it to zero width. The negative left margin (a) then stretches it back to 150px wide (the width of the leaf shape), and then our box shadow (c) is offset enough to be in view. This is awesome because we no longer have to deal with negative box shadows in order to get everything to layer correctly.

We’re also back to bgcolor and get to leverage a nice quirk of background colors: because <html> doesn’t have its own background color, it inherits one from <body>.

Attempts 9 and 10: 118 bytes <body bgcolor=0B2429 style=border-radius:67%0;margin:75+340+75-90;box-shadow:7cm+0#F3AC3C,57mm+0#998235,55vh+0#1A4341>

With a bit more unit-wrangling we’re able to save ourselves two more bytes (props to Dorus, who was the first to discover this optimization). Adjusting the margins saves a digit (150 becomes 90), and, as a sweet bonus, we get to convert 86mm to 70mm, which becomes 7cm. I’ve again combined two attempts here which were minor unit fixes. (I’m embarrassed to say I initially missed the mm-cm conversion.)

Attempt 11: 117 bytes <body bgcolor=0B2429 style=border-radius:67%0;margin:75+85%75-90;box-shadow:7cm+0#F3AC3C,57mm+0#998235,55vh+0#1A4341>

Romain Deltour was the first to find this 117-byte solution. Changing 340 to 85% means we get to omit a space after one of our values (just like we did with border-radius), saving another byte.

Attempt 12: 115 bytes <body bgcolor=0B2429 style=border-radius:67%0;margin:75+85%75-90;box-shadow:7cm+0#F3AC3C,57mm+0#998235,55vh+0#7fd2>

Two full weeks after Romain’s 117-byte solution, Viacheslav Popov was able to alpha composite his way to 115 bytes via 4-digit hex codes.

I really love this because — not only is it dang clever — but a lot of people (myself included) thought the target had already been fully optimized. Viacheslav’s persistence both sparked a new round of discussion and added another CSS-Trick™ to our arsenal for future targets.

Attempt 13: <115 bytes?

This seems awfully close to optimal to me but that certainly doesn’t mean it can’t be beat — why not give it a shot? There's prior art to get you started, plenty of folks willing to help, and even some tooling. Happy golfing ⛳️

The post A CSS Golfing Exercise appeared first on CSS-Tricks.

Categories: Web Technologies

A Conspiracy to Kill IE6

Mon, 05/06/2019 - 07:22

Chris Zacharias published a few notes about why the team at YouTube added a banner that asked users to switch from IE6 to a more modern browser back in 2009:

The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.

I do not recall the exact triggering event that led to our web development team laying out plans to kill IE6 over lunch in the YouTube cafeteria. Perhaps it was the time I pushed out a CSS stylesheet that included an attribute selector on a semi-supported HTML element. Any reasonable web developer would expect this to be ignored by browsers not up to the task. This was not the case with older flavors of IE. Under very specific conditions, an attribute selector on an unsupported HTML element in IE would create an internal recursion that would at best, cause the browser to crash and at worst, trigger a blue screen of death.

There are a lot of interesting things to consider here. IE6 was notoriously difficult for developers to work with and would cause teams to spend a great deal of time fixing game-breaking bugs for what often represented a mere slither of their overall site traffic. However, it’s important to note that as soon as you make a call like this, where do you stop? It suddenly becomes easier to make a Chrome-only website, to ignore basic accessibility principles, to ignore semantic markup, and to make a website optimized for yourself. That leads us to more sticky topics, such as browser diversity and proprietary resources that seem at odds with an open, inclusive web.

I’m reminded here of Jeremy Keith’s book, Resilient Web Design, where he writes:

If a website is built using progressive enhancement then it’s okay if a particular feature isn’t supported or fails to load: Ajax, geolocation, whatever. As long as the core functionality is still available, web designers don’t need to bend over backwards trying to crowbar support for newer features into older browsers.

And Jeremy quotes Mat Marquis, who happened to work on the responsive redesign of The Boston Globe, where he argued that:

Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.

Maybe there’s a middle ground here; maybe there’s not. But I find Mat and Jeremy’s approach to be more inspiring and kinder to the overall health of the web.

Direct Link to ArticlePermalink

The post A Conspiracy to Kill IE6 appeared first on CSS-Tricks.

Categories: Web Technologies

Making the Move from jQuery to Vue

Fri, 05/03/2019 - 07:27

As someone who has used jQuery for many. years and has recently become a Vue convert, I thought it would be an interesting topic to discuss the migration process of working with one to the other.

Before I begin though, I want to ensure one thing is crystal clear. I am not, in any way whatsoever, telling anyone to stop using jQuery. That's been pretty fashionable lately, and heck, I wrote up something similar myself a few year ago ("How I'm (Not) Using jQuery"). If you get things done with jQuery and your end users are successfully using your site, then more power to you. Keep using what works for you.

This guide is more for people who may be coming from years of jQuery experience and want to see how things can be done with Vue. With that in mind, I'm going to focus on what I consider "core" jQuery use cases. I won't cover every single possible feature but instead take a "I often did [X] with jQuery" approach that may be more relatable to people considering learning Vue. (As an aside, also note that how I write my examples are simply one way of performing a task. Both jQuery and Vue give provide multiple ways to accomplish the same goal and that's a great thing!)

With that in mind, let's consider some high level things we might turn to jQuery for:

  • Finding something in the DOM (with the idea of doing something with it later)
  • Changing something in the DOM (e.g. the text of a paragraph or the class of a button)
  • Reading and setting form values
  • Form validation (which is really just a combination of the items above)
  • Ajax calls and handling the results
  • Event handling (e.g. on button click, do something)
  • Measuring or changing the styles of an element

There's more to jQuery, of course, but these uses (at least in my opinion), cover the most common use cases. Also note there's a lot of cross pollination in the list above. So, should we start with a simple one-to-one comparison of each? Nope, not so fast. Let's begin by covering the major difference in Vue applications.

Defining where Vue "works"

When we drop jQuery onto a page, we are basically adding a Swiss Army knife to JavaScript code to handle common web development tasks. We can do any of the uses case we’re going to cover in whatever order we see fit. For example, a client may ask for form validation today, then in a month or so, ask to do an Ajax-based search form in the header of the site.

Vue has one significant difference in that respect. When starting a with Vue project, we start by defining an "area" in the DOM we want it to focus on. So, let’s consider a simple prototype web page:

<body> <header> Fancy header stuff here </header> <div id="sidebar"> Some sidebar doohicky here </div> <main> <p> Main site content here, super important stuff... </p> <div id="loginForm"> A login form of course </div> </main> </body>

In a typical jQuery application, we may write code to work with the header, sidebar, and login form or something. No big whoop:

$(document).ready(function() { $('header') // something... $('#sidebar') // something... $('#loginForm') // something... });

In a Vue application, we first specify what are we're working with. Imagine our client first asked to add validation to the loginForm element. Our Vue code would specify that:

new Vue({ el: '#loginForm', // Code here... });

This means that we’d typically end up adding a second Vue application if the client later decides to have us add something to the sidebar:

new Vue({ el:'#loginForm', // Code here... }); new Vue({ el:'#sideBar', // Code here... });

Is that a bad thing? Absolutely not. Right away, we get the benefit of encapsulation. If we accidentally use a variable with a generic name (we've all done that), we don't have to worry about conflicts with other parts of your code. Later on when the client adds yet another request, having our unique, logical sets of Vue code separated out like this gives us some great peace of mind that things won't step on each other.

So, yes, a good thing. But it absolutely caused me to stop a bit when I first began using Vue. Now, onto our use cases.

Finding Stuff in the DOM

Another aspect you'll find interesting, or scary, is how to "find stuff in the DOM." That's a bit vague, but let's consider a firm example. We have a button, and when it’s clicked, we something to happen. Here's an abbreviated example of how this could look:

<button id="myButton">Click Me!</button> <!-- More stuff... --> <script> $(document).ready(function() { $('#myButton').click(function() { alert(1); }); }); </script>

Now let's compare that to how it can be done with Vue:

<div id="app"> <button v-on:click="doSomething">Click Me!</button> </div> <script> const app = new Vue({ el:'#app', methods: { doSomething: function() { alert(1); } } }); </script>

The Vue application is a bit more verbose, but note how the markup has a direct connection between the action ("click") and the function that will be called. Vue's code doesn't have a tie back to the DOM (outside of the el portion where we define where it needs to work). This was easily one of the things that sold me on Vue the most — it feels easier to tell what is going on. Also, I didn't need to worry so much about the ID value and selectors. If I change the class or ID of the button, I don't need to go back into my code and worry about updating selectors.

Let's consider another example: finding and changing text in the DOM. Imagine that button, on click, now changes the text of another part of the DOM.

<button id="myButton">Click Me!</button> <span id="result"></span> <!-- More stuff... --> <script> $(document).ready(function() { $('#myButton').click(function() { $('#result').text('You clicked me, thanks!'); }); }); </script>

I've added a new span and now, when the button is clicked, we use another selector to find it and use a jQuery utility method to change the text inside it. Now consider the Vue version:

<div id="app"> <button v-on:click="doSomething">Click Me!</button> <!-- On click, change text in this span --> <span>{{resultText}}</span> </div> <script> const app = new Vue({ el: '#app', data: { resultText: '' }, methods: { doSomething: function() { this.resultText = 'You clicked me, thanks!'; } } }); </script>

In this example, we're using Vue's template language (the highlighted line) to specify that we want to render a variable inside the span, which is resultText in this case. Now, when the button is clicked, we change that value and the span's inner text will change automatically.

As an aside, Vue supports a shorthand for the v-on attribute, so the button in the example could have been written with @click="doSomething" instead.

Reading and writing form variables

Working with forms is probably one of the most common — and useful — things that we can do with JavaScript. Even before JavaScript, most of my early "web development" was writing Perl script to handle form submissions. As the primary way of accepting user input, forms have always been critical to the web and that's probably going to stay the same for quite some time. Let's consider a simple jQuery example of reading a few form fields and setting another:

<form> <input type="number" id="first"> + <input type="number" id="second"> = <input type="number" id="sum"> <button id="sumButton">Sum</button> </form> <script> $(document).ready(function() { let $first = $('#first'); let $second = $('#second'); let $sum = $('#sum'); let $button = $('#sumButton'); $button.on('click', function(e) { e.preventDefault(); let total = parseInt($first.val(),10) + parseInt($second.val(),10); $sum.val(total); }); }); </script>

This code demonstrates how jQuery can both read and write via the val() method. We end up getting four items from the DOM (all three form fields and the button) and use simple math to generate a result. Now consider the Vue version:

<form id="myForm"> <input type="number" v-model.number="first"> + <input type="number" v-model.number="second"> = <input type="number" v-model="sum"> <button @click.prevent="doSum">Sum</button> </form> <script> new Vue({ el: '#myForm', data: { first: 0, second: 0, sum: 0 }, methods: { doSum: function() { this.sum = this.first + this.second; } } }) </script>

This introduces some interesting Vue shortcuts. First, v-model is how Vue creates two way data binding between values in the DOM and in JavaScript. The data block variables will automatically sync up with the form fields. Change the data, and the form updates. Change the form, and the data updates. The .number is a flag to Vue to treat the inherit string values of form fields as numbers. If we leave this off and do addition as we are, we'll see string additions and not arithmetic. I've been working with JavaScript for nearly a century and still screw this up.

Another neat "trick" is @click.prevent. First, @click defines a click handler for the button, then the .prevent portion blocks the browser’s default behavior of submitting the form (the equivalent of event.preventDefault()).

The final bit is the addition of the doSum method that's bound to that button. Note that it simply works with the data variables (which Vue makes available in the this scope).

While this is mostly my personal feeling here, I really love the lack of query selectors in the script when writing in Vue and how the HTML is much more clear about what it's doing.

Finally, we could even get rid of the button completely:

<form id="myForm"> <input type="number" v-model.number="first"> + <input type="number" v-model.number="second"> = <input type="number" v-model="sum"> </form> <script> new Vue({ el: '#myForm', data: { first: 0, second: 0 }, computed: { sum: function() { return this.first + this.second; } } }) </script>

One of the cooler features of Vue is computed properties. They are virtual values that recognize when their derived values are updated. In the code above, as soon as any of the two form fields change, the sum will update. This works outside of form fields too. We could render the sum like so:

The total is {{sum}}. Working with Ajax

It’s commendable how easy jQuery has made it to use Ajax. In fact, I can say I've done Ajax "the vanilla" way probably a grand total of one time. (If you're curious, you can take a look at the spec for XMLHttpRequest and probably be happy you avoided it yourself.) jQuery's simple $.get(...) method worked in a large number of cases and when it’s needed for something more complex, $.ajax() made it easy as well. Another thing jQuery did well is the way it handles JSONP requests. While mostly unnecessary now with CORS, JSONP was a way to handle making requests to APIs on different domains.

So, what does Vue do for you to make Ajax easier? Nothing!

OK, that sounds scary but it really isn't. There are many options out there for working with HTTP requests, and Vue.js took a more agnostic route of letting us, the developers, decide how we want to handle it. So yes, that does mean a bit more work, but we've got some great options.

The first one to consider is Axios, this is a Promise-based library that is very popular among the Vue community. Here's a simple example of it in action (taken from their README file):

axios.get('/user?ID=12345') .then(function (response) { // handle success console.log(response); }) .catch(function (error) { // handle error console.log(error); }) .then(function () { // always executed });

Axios supports POST requests, of course, and lets us specify headers among many other options.

While Axios is very popular among Vue developers, it isn't something that really clicked with me. (At least not yet.) Instead, I've been much more a fan of Fetch. Fetch is not an external library but is a web standard way of performing HTTP requests. Fetch has very good support at roughly 90% of browsers, though that means it isn't completely safe to use, but we can always use a polyfill we need to.

While it's totally out of the scope of what we're discussing here, Kingsley Silas has written an excellent guide on using both Axios and Fetch with React.

Like Axios, Fetch is Promise-based and has a friendly API:

fetch('http://example.com/movies.json') .then(function(response) { return response.json(); }) .then(function(myJson) { console.log(JSON.stringify(myJson)); });

Both Axios and Fetch cover all types of HTTP requests, so either will fit an any number of needs. Let's look at a simple comparison. Here's a simple jQuery demo that makes use of the Star Wars API.

<h1>Star Wars Films</h1> <ul id="films"> </ul> <script> $(document).ready(function() { $.get('https://swapi.co/api/films', function(res) { let list = ''; res.results.forEach(function(r) { list += `<li>${r.title}</li>`; }); $('#films').html(list); }); }); </script>

In the sample above, I use $.get to hit the API and return a list of films. Then I generate a list of titles as li tag elements with that data and insert it all into a ul block.

Now, let's consider an example of this using Vue:

<div id="app"> <h1>Star Wars Films</h1> <ul> <li v-for="film in films">{{film.title}}</li> </ul> </div> <script> const app = new Vue({ el: '#app', data: { films: [] }, created() { fetch('https://swapi.co/api/films') .then(res => res.json()) .then(res => { this.films = res.results; }); } }) </script>

Probably the best part of this is the use of the v-for template. Notice how Vue isn't concerned with the layout (well, at least the JavaScript). The data is fetched from the API. It’s assigned a variable. The layout handles displaying it. I've always hated having HTML in my JavaScript and, while solutions exist for that with jQuery, having it baked into Vue makes it a natural fit.

A full (if somewhat trivial) example

To bring it home a bit, let's consider a more real world example. Our client has asked us to build a fancy Ajax-enabled front-end search interface to a product API. The feature list includes:

  • Support filtering by name and product category
  • Form validation such that we must supply a search term or a category
  • While the API is being hit, show a message to the user and disable the submit button
  • When done, handle reporting that no products were shown or list the matches

Let's begin with the jQuery version. First, the HTML:

<form> <p> <label for="search">Search</label> <input type="search" id="search"> </p> <p> <label for="category">Category</label> <select id="category"> <option></option> <option>Food</option> <option>Games</option> </select> </p> <button id="searchBtn">Search</button> </form> <div id="status"></div> <div id="results"></div>

There's a form with our two filters and two divs. One's used as a temporary status when searching or reporting errors and one is used to render results. Now, check out the code.

const productAPI = 'https://wt-c2bde7d7dfc8623f121b0eb5a7102930-0.sandbox.auth0-extend.com/productSearch'; $(document).ready(() => { let $search = $('#search'); let $category = $('#category'); let $searchBtn = $('#searchBtn'); let $status = $('#status'); let $results = $('#results'); $searchBtn.on('click', e => { e.preventDefault(); // First clear previous stuff $status.html(''); $results.html(''); // OK, now validate form let term = $search.val(); let category = $category.val(); if(term === '' && category === '') { $status.html('You must enter a term or select a category.'); return false; } $searchBtn.attr('disabled','disabled'); $status.html('Searching - please stand by...'); $.post(productAPI, { name:term, category:category }, body => { $searchBtn.removeAttr('disabled'); $status.html(''); if(body.results.length === 0) { $results.html('<p>Sorry, no results!</p>'); return; } let result = '<ul>'; body.results.forEach(r => { result += `<li>${r.name}</li>` }); result += '</ul>'; $results.html(result); }); }); });

The code begins by creating a set of variables for each of the DOM items we want to work with — the form fields, button, and divs. The core of the logic is within the click handler for the button. We do validation, and if everything is OK, do a POST request against the API. When it returns, we either render the results or show a message if nothing was matched.

You can work with a complete version of this demo using the CodePen below.

See the Pen
jQuery Full
by Raymond Camden (@cfjedimaster)
on CodePen.

Now let's consider the Vue version. Again, let's start with the layout:

<div id="app"> <form> <p> <label for="search">Search</label> <input type="search" v-model="search"> </p> <p> <label for="category">Category</label> <select v-model="category"> <option></option> <option>Food</option> <option>Games</option> </select> </p> <button @click.prevent="searchProducts" :disabled="searchBtnDisabled">Search</button> </form> <div v-html="status"></div> <ul v-if="results"> <li v-for="result in results">{{result.name}}</li> </ul> </div>

From the top, the changes include:

  • Wrapping the layout in a div that can be used to let Vue know where to work.
  • Using v-model for the form fields to make it easy to work with the data.
  • Using @click.prevent to handle doing the main search operation.
  • Using :disabled to bind whether or not the button is disabled to a value in the Vue application (we'll see that in action in a moment).
  • The status value is a bit different than earlier examples. While jQuery has a specific method to set text in a DOM item and another for HTML, Vue requires using v-html when assigning HTML to a value that's going to be rendered. If we tried to do {{status}} with HTML, the tags would be escaped.
  • Finally, using v-if to conditionally render a list of results along with v-for to handle the iteration.

Now let's look at the code.

const productAPI = 'https://wt-c2bde7d7dfc8623f121b0eb5a7102930-0.sandbox.auth0-extend.com/productSearch'; const app = new Vue({ el: '#app', data: { search: '', category: '', status: '', results: null, searchBtnDisabled: false }, methods: { searchProducts:function() { this.results = null; this.status = ''; if(this.search === '' && this.category === '') { this.status = 'You must enter a term or select a category.'; return; } this.searchBtnDisabled = true; this.status = 'Searching - please stand by...'; fetch(productAPI, { method: 'POST', headers: { 'Content-Type':'application/json' }, body: JSON.stringify({name:this.search,category:this.category}) }).then(res => res.json()) .then(res => { this.status = ''; this.searchBtnDisabled = false; this.results = res.results; if(this.results.length === 0) this.status = '<p>Sorry, no results!</p>'; }); } } });

The first block worth calling out is the set of data fields. Some map to form fields and others to results, status messages, and the like. The searchProducts method handles much of the same stuff as the jQuery version but, in general, there's much less code directly tied to the DOM. For example, even though we know the results are listed in an unordered list, the code itself doesn't worry about that. It simply assigns the value and the markup handles rendering it. Overall, the JavaScript code is much more concerned about logic in comparison to the jQuery code which "feels" like a much nicer separation of concerns.

As before, I've got a CodePen for you to try this out yourself:

See the Pen
Vue Full
by Raymond Camden (@cfjedimaster)
on CodePen.

Death to jQuery! Long Live Vue!

OK, that's a bit over the top. As I said in the beginning, I absolutely think that you shouldn't change a thing if like working with jQuery and it's working for you.

I can say, however, that Vue feels like a great "next step" for people who are used to working with jQuery. Vue supports complex applications and has a great command line tool for scaffolding and building projects. But for simpler tasks, Vue works as a great "modern jQuery" replacement that has become my tool of choice for development!

For another perspective on using Vue in place of jQuery, check out Sarah Drasner's "Replacing jQuery With Vue.js: No Build Step Necessary" because it includes a handful of other super helpful examples.

The post Making the Move from jQuery to Vue appeared first on CSS-Tricks.

Categories: Web Technologies

Currently Reading: Progressive Web Apps by Jason Grisby

Fri, 05/03/2019 - 07:27

I’ve been reading Jason Grigsby’s new book on progressive web apps this past week and it’s exciting. Jason explains what PWAs are and how they work while while doing a bang-up job covering the business case for using them them, too. But perhaps you might be thinking that a PWA isn’t necessary for the project you’re working on right now. Well, Jason argues that progressive web apps are for everybody:

Should your website be a progressive web app? The answer is almost certainly yes. Even if you don’t think of your website as an “app,” the core features of progressive web apps can benefit any website. Who wouldn’t profit from a fast, secure, and reliable website?

One of the challenges I’ve experienced when thinking about how to apply a progressive web app to a project I’m working on is figuring out what content to cache. Should the homepage be cached? Do we make a custom offline page? What is useful information to provide a user in that context?

Jason goes there, too, and even describes how he tackles that for his own projects:

For cloudfour.com, we chose to only cache recently viewed pages because the main reason people come to our site is to read the articles. If we tried to anticipate which articles someone would want offline access to, we’d likely guess incorrectly. If we precached top-level pages, we might force people on a metered network connection to download content they would never look at...

That makes a ton of sense to me and I realize that the offline cache should probably be different depending on the situation and the website. For example, maybe a design agency website could replace the big flashy homepage with an offline page that only shows the phone number of the agency instead. Or perhaps a restaurant website could cache the food menu and make that experience offline, but remove all the images to make sure it’s not too impactful for folks on those metered networks.

Anyway, I think that Jason’s book is wonderful as it reveals to us all this complexity and a whole new set of opportunities to improve the design and experience of our websites, which, by the way, is something we should strive for in this new and exciting age of web app development.

The post Currently Reading: Progressive Web Apps by Jason Grisby appeared first on CSS-Tricks.

Categories: Web Technologies

Split

Thu, 05/02/2019 - 11:08

Jeremy on the divide between the core languages of the web, and all the tooling that exists to produce code in those languages:

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Jeremy likes the raw materials side the best, but acknowledges a healthy balance of both worlds is a healthy mix.

I think a great front-end developer is hyper-aware of this split. Every choice we make is a trade-off between developer productivity and complexity management and the user's experience. The trick is to punish the user as little as possible while giving yourself as much as you can.

Direct Link to ArticlePermalink

The post Split appeared first on CSS-Tricks.

Categories: Web Technologies

Pages