Tag: mean

“Evergreen” Does Not Mean Immediately Available

I have a coworker who is smart, capable, and technologically-literate. Like me, they work on the web full-time.

When they are sharing their screen in a meeting, I find myself disassociating fixating on the red update button in their copy of Chrome.

An angry red button labeled "Update".

Clicking this button would start the process to update Chrome to the latest stable version.

I’ve asked some probing questions about how frequently they reboot, which would also force Chrome to update upon relaunch. That’s the point of an “evergreen” browser, right? It’s easy to make sure you’re always using the latest and greatest version.

It turns out they prefer to wait until they absolutely have to because of the disruption it would cause in their daily workflow. Their behavior makes sense. They are prioritizing the quality of their overall computing experience, rather than catering to the demands of one specific app.

Like me, my coworker also uses a top-of-the-line laptop to get things done. This means that the laptop can go for months without needing a reboot. Ironically, this might be a situation where a craptop is conditionally forced to have a faster browser upgrade path.

Evergreen browsers

Before the advent of evergreen browsers, you would need to go to the manufacturer’s website and manually download and install the update. Prior to that you had to use a CD or floppy disk.

A floppy disk used for installing Netscape Navigator.
Source: Floppy Disk of Netscape Navigator. Toshihiro Oimatsu, CC BY 2.0, via Wikimedia Commons.

By contrast, an evergreen browser is any browser that can automatically update itself. By this, I mean the browser will automatically pull down the code required to add new features and fix bugs once it has been released by the browser’s manufacturer. The update itself occurs with:

  • a prompt shown to the person using the browser that prompts an application restart,
  • a download that happens in the background and gets applied on application restart, or
  • on device restart.

The browsers themselves

Nearly all major browsers are evergreen. This includes Google Chrome, Microsoft Edge, and Mozilla Firefox.

Apple Safari is quasi-evergreen. By this I mean it automatically receives updates, but awkwardly requires them to be done when updating the macOS operating system with other system-wide updates.

A sub-window floating over macOS’s Software Update preference pane. It shows options for updating macOS Big Sur to version 11.6.2, Command Line Tools for Xcode to version 13.2, Safari to version 15.2, and Safari Technology Preview to version 137, all of which are considered Evergreen software. Screenshot.

If you haven’t been paying attention, the Safari team has been making a ton of improvements to their browser in the past few months—I’d love to see them continue with this trend by making the browser update path decoupled from existing macOS and iOS upgrade workflows.

The situation

With the actual, final, no-seriously-we-mean-it-this-time death of Internet Explorer, evergreen browsers are now the main consideration for desktop and laptop browsers. This is great! It means we can spend a lot less time fretting about who can use what.

Spending less time does not mean spending no time, however.

Delayed effects

Support from all evergreen browsers on caniuse.com does not necessarily mean support exists on the device a person is using—updates that have been “pushed” out don’t automatically get instantly applied.

Because of these two factors, I advocate for tempering your excitement with some restraint. It can be very tempting to rush and use the new and the shiny. Believe me, I’m not exempt from this urge—CSS is about to go from great to amazing, and the urge to use new features is very real.

Instead, wait a bit. Work with the platform’s ability to create progressively enhanced experiences with CSS and JavaScript.

Leverage the platform

The web is really good at being resilient, provided you work with its grain.

Both CSS and JavaScript have the ability to conditionally serve up experiences for browsers that support new features while providing alternatives for those that don’t.

Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”

—Jeremy Keith, “Continuous partial browser support”

JavaScript

You can use JavaScript to query whether or not a browser supports a certain feature. For example, the Navigator interface provides a mechanism for querying a user agent’s capabilities.

if (!(“geolocation” in navigator)) {   // Logic if a user's current geographic location isn't available } else {   // Logic that is based on a user's current geographic location }

In this example, I am inverting a request for support for a browser’s Geolocation interface. Although its syntax is initially a little confusing to parse, it helps emphasize a progressive enhancement approach. That is, assume geolocation functionality isn’t supported and be sure to prove a way to accommodate the person using this browser. This could have been any other feature, like letting a user type in an address or ZIP Code. With that use case covered, you can then confidently build an experience that utilizes a browser’s geolocation capabilities.

This thinking also extends to all other browser features and capabilities.

CSS

Like most other programming languages, CSS also lets us use if-like statements.

For example, the @supports at rule allows you to create a conditional statement that targets whether or not a browser supports something, and then apply logic to it. Browsers that honor the feature will utilize those styles, and browsers that don’t will ignore them. It is a concise, clever, adaptable solution.

.component {   /* Base appearance */ }  @supports (grid-template-columns: subgrid;) {   .component {     /* Styling and positioning enhancement tweaks if subgrid is supported */   } }

For this example, this progressive enhancement approach ensures that a component’s content and functionality is preserved for every browser, but only creates fancy layouts for browsers capable of supporting them.

When can I remove this stuff?

Yes, this approach adds more code, and more code means more complexity and maintenance. But it’s very important code. You may even call it technical debt and you’d be correct. But technical debt can be a good thing, like an investment in the future.

You may want to remove that complexity when it’s no longer needed. Knowing the right time to do that in this age of evergreen browsers is difficult, but I have a couple of suggestions:

Patience is a virtue

In terms of waiting, I’d advise a conservative 6-ish months from release of a new feature before even beginning to think about investigating if you can remove feature detection. This accounts for:

  • Reboots
  • Update procrastinators
  • Update avoiders
  • Hardware refresh cycles
  • Corporate update policies,
  • etc.

I would also say that rough six month timeframe is in terms of a general, global web audience. This guesstimate changes if you cater to a specialized audience. The way to know who you actually serve? Analytics, yes, but also talking to people.

Maybe don’t

Remember: survivor bias is real. Is the brand new feature you’re using preventing someone from using your website or web app? I say this because some people:

There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.

Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.

The future is uncertain

We’re long past the age of desktop computers. Browsers are showing up in more and more places: phones, tablets, watches, ebook readers, digital cameras, kiosks, televisions, home assistants, vending machines, photo frames, graphing calculators, ATMs, point of sale terminals, exercise equipment, video game consoles, billboards, refrigerators, virtual reality, and cars.

Who knows what devices browsers will be included with in the future, or what capabilities they’ll have? Future-proof (and, er, past-proof) yourself with an approach that accommodates it.


Thank you to to Jim Nielsen for their feedback.


“Evergreen” Does Not Mean Immediately Available originally published on CSS-Tricks. You should get the newsletter and become a supporter.

CSS-Tricks

, , ,

What the Heck Does “npm” Mean?

One of the things that makes this new, tooling-heavy era of front-end development so seemingly hard to understand at first is that, while we often call things by a singular name, they tend to be actually comprised of several different interconnected pieces. The same is true for npm and the ecosystem around it.

For example: Think of how we casually refer to “the internet,” even though the web itself is not a single, unified thing, but a collection of protocols, DNS, servers, browsers, networks, requests and responses, plus lots of other things assembled over years of iterations. For that matter, even the browser itself is one machine with many parts.

Guide chapters

  1. Who the Heck is This Guide For?
  2. What the Heck Does “npm” Mean? (You are here!)
  3. What the Heck is the Command Line?
  4. What the Heck is Node?
  5. What the Heck is a Package Manager?
  6. How the Heck Do You Install npm?
  7. How the Heck Do You Install npm Packages?
  8. What the Heck Are npm Commands?
  9. How the Heck Do You Install an Existing npm Project?

npm is a collection of technologies

In that same way, what we generally think of as “npm” (yes, all lowercase) and “back-of-the-front-end” in particular is a single name for a collection of many different individual technologies and systems; a sort of Rube Goldberg machine to generate browser-friendly code.

I mentioned the command line already; that’s a big part of the ecosystem because it’s how we interact with it. But more on that in the next chapter.

And then there’s npm, which is in a category known as “package management” software. We’ll cover that as well. In fact, you’ll likely see me refer to npm as a package manager throughout this guide.

And finally, there’s Node itself, which is so tricky to explain succinctly I often describe it by paraphrasing Douglas Adams: it’s a programming language that’s almost—but not quite—entirely like JavaScript.

npm manages project tools

To further muddy the waters, many projects where you type npm install into the command line might come with pre-installed tools to help you do a wide variety of things in your project, like process your code (e.g., turn Sass code into CSS). There are many all-in-one, preconfigured projects out there just waiting for you to install them and get started (Create React App, Next, Nuxt, and SvelteKit, to name a few). This is convenient when done well, of course, but it’s also added complexity—meaning many more names we need to add to our list of back-of-the-front-end things.

This list often includes tools like Babel (for compiling JavaScript), Sass (for compiling CSS), webpack (for asset bundling), Vite (for development servers and other tooling), PostCSS (for transforming one syntax into another); Autoprefixer (which can be a PostCSS plugin for CSS vendor prefixes); TypeScript (for additional JavaScript syntax); ESlint (for checking code quality); Prettier (for formatting code), and testing libraries like Jest or Cypress.

The stark stark white interior of a library building with multiple floors and bookcases filled with brightly colored books, illustrating how npm manages front-end development tools.
npm is like a library building with floors of book collections that are organized, making things easier to find and manage. (Photo: Johannes Mändle on Unsplash)

All those things (and more) fall into this broad, general category of tools that often come with npm-installed projects—or that can be installed and used via npm—but are not actually part of npm itself. They’re just examples of modern tools that help us do nice things with our code, and I mention them here only because it’s worth noting the distinction, to get a sense of where the boundaries lie in this large, new world.

And by the way, if you didn’t know what most (or any) of those tools mentioned above are, that’s ok. Maybe you haven’t come across them yet, or maybe you’ve worked on a project that had them installed without knowing them by name. Either way, all of this is merely for additional context.

Let’s break here

If you’re already feeling a bit overwhelmed at this point: don’t sweat it. The key thing I want you to walk away with after reading this specific chapter is that what we think of as “npm” (or maybe more casually as “all that command line, back-end-y stuff”) is not really one thing, but a collection of things that work together to make development easier for us.

And yes: while all that complication seems intimidating up-front, it does actually make things better. I promise.

While front-end seems to move very quickly, no, you have not been left behind. You may just have a bit of continuing education to get caught up on.


What the Heck Does “npm” Mean? originally published on CSS-Tricks. You should get the newsletter and become a supporter.

CSS-Tricks

, ,
[Top]

What does `font: 110%/1.4 system-ui` mean?

I use this line, or one like it, in a lot of quick demos. Not that it’s not a production-worthy line of code—I just tend to be a bit more explicit on bigger projects.

html {   font: 110%/1.4 system-ui; }

Someone wrote in confused by it, and I could see how a line like that is a bit bewildering at first.

The first thing to know is that it is called shorthand. The font property in CSS gives you the opportunity to set a bunch of font-* properties all at once. In this case, we’re setting:

html {   font-family: system-ui;   font-size: 110%;   line-height: 1.4; }

There are a few more little specific things to know. For example, the order matters.

/* invalid */ html {   font: system-ui 100%/1.4; }

You also can’t set the line-height without also setting the font-size. If you’re going to set line-height, you have to set both. Be extra careful there because something like 20px is both a valid line-height and font-size, and if you only set one, it’ll be the font-size. If you go for a unitless number, which is a great idea for line-height, and try to set it alone, it’ll just fail.

/* invalid */ html {   font: 1.5 system-ui; }

Of course, we’ve got all this detailed in the Almanac entry for font. But I’ll also give a shout to Mateusz Hadryś who has a detailed article titled “Full Text Styling With a Single Line of CSS” with some detailed figures like this that are helpful in understanding everything:

Showing the font property declaration. Style, variant and weight are in yellow with a label above that says order doesn't matter and a label beneath saying these have to be first. Next is size with a forward slash then line-height in red. Above them is a label that says these have to be next to each other. Next is family in light blue with a label that says it has to be last. There is an additional white label that connects size and family that says they are required.

Lastly, if system-ui was part of the confusion there, that’s one of those System Things.


The post What does `font: 110%/1.4 system-ui` mean? appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,
[Top]

What does 100% mean in CSS?

When using percentage values in CSS like this…

.element {   margin-top: 40%; }

…what does that % value mean here? What is it a percentage of? There’ve been so many times when I’ll be using percentages and something weird happens. I typically shrug, change the value to something else and move on with my day.

But Amelia Wattenberger says no! in this remarkable deep dive into how percentages work in CSS and all the peculiar things we need to know about them. And as is par for the course at this point, any post by Amelia has a ton of wonderful demos that perfectly describe how the CSS in any given example works. And this post is no different.

Direct Link to ArticlePermalink


The post What does 100% mean in CSS? appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

,
[Top]

What Does `playsinline` Mean in Web Video?

I got myself confused about this the other day, went around searching for an answer and came up empty on finding something clear. The answer actually is quite clear and I feel a little silly for not knowing it.

With it in place, like this:

<video src="..." controls playsinline></video>

Mobile browsers, will play the video right where it is instead of the default, which is to open it up fullscreen while it plays.

Here’s what it looks like without playsinline:

Here’s what it looks like with playsinline:

(If you’re like me, you tried to play that video from the play button on the video in the video, only to realize it’s not a real play button. 🤯)

(While we’re getting meta, I’m making sure those videos above have playsinline on them right here in this blog post.)

Note that the user still has the ability to go fullscreen with the video even in the playsinline scenario, so I’d say it’s probably a smart default choice. It’s not literally the default — you have to add it, but you know what I mean.

One of the places this shows up regularly is in the attribute soup that is required to make video be a GIF-replacement:

<video autoplay loop muted playsinline src="..."></video>

If you have all four of those attributes, the video will actually autoplay (and loop) on mobile browsers, just like a GIF would, only with far better performance. You can skip loop if you don’t want that, but all the other three are required if you want the autoplay attribute to work.

I also learned that the (only?) way to get a thumbnail to show up on mobile (at least for iOS) is to use a poster attribute. Even if you preload, you don’t see anything but blank white unless you have a poster.

Without a poster:

With a poster:

<video   src="movie.mov"   poster="thumbnail.jpg"    controls ></video>mo

If you can’t be troubled to deal with a poster, you might wanna toss a border or something on video elements to sort of visually block off that area. Otherwise, the floating play button is a little awkward.

The post What Does `playsinline` Mean in Web Video? appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

What Does it Mean to Be “Full Stack”?

I was asked this recently by a fellow developer who was at the same web tech conference I was at. This developer had met a lot of new people who literally introduced themselves as full-stack developers sort of the way Bob Vance, Vance Refrigeration would on The Office, but it was Tony Frank, Full-Stack Developer instead.

I suspect the developer asking the question taken from the title of this post already knew the basic idea of what people mean by “full-stack developer,” but was wondering what the heck it’s all about. There was a tone in the question. A tone that suggested this person isn’t exactly in love with the term.

These days, probably a bit of DevOps (e.g. Git, testing, and getting sites to production). The “stack” is all these things combined, so a full-stack developer is shorthand for: when it comes to building websites, I can do it all.

There are some stacks that have achieved notoriety over the years. Maybe you’ve heard of the LAMP stack?

Linux Apache MySQL PHP

A full-stack developer on that stack means you know Linux, Apache, MySQL, and PHP. (Abstractly: server software, web server, database, back-end language.) This site runs on that stack, and I’m solely responsible for its development, so I guess I’m a full-stack developer in some loose sense.

But “loose” is a generous interpretation. I don’t know the first thing about Linux, except that’s what runs my web servers. I don’t know much about Apache, except that I sometimes use HTAccess directives to do things. I could count the number of MySQL queries I’ve written on my two hands, and I only really know PHP in the context of WordPress.

Looked at that way, I’m barely a developer at all. Full stack, on the other hand, generally refers to tossing front-end tasks into the mix and I’m competent enough in that space that my front-end skill set alone, has allowed me to build dozens (or hundreds!) of sites throughout my career. Full-stack-enough, anyway.

There are loads of other stacks.

LAMP isn’t particularly prescriptive about how you build the front-end. It came from an era where it was assumed you’d build a back end to spit out HTML and that’s your front end.

Another stack that’s achieved notoriety since the Grand Arrival of JavaScript is the MEAN stack.

MongoDB Express Angular Node

It is perfectly plausible to replace parts of a stack. Perhaps you’d use Nginx instead of Apache, or PostgreSQL instead of MySQL in what’s otherwise LAMP stack. MEAN is notable in that every layer of the stack was replaced with new technology. Node brought JavaScript to the back end, which could power web servers, handle routing, connect data sources, run build processes, compile code, and more.

A full-stack developer in this world is writing nearly everything in JavaScript. No wonder there is somewhat of an explosion of people considering themselves “full” stack. A single language, like JavaScript, that runs in browsers itself and is a paramount front-end technology is a widely transferrable skill.

The MEAN stack can have layers swapped out just as easily as LAMP. Perhaps you use a data store like Fauna or Firebase instead. Perhaps you use Vue or React instead of Angular. Perhaps you don’t need Express because you leave your routing to a framework or do it client-side.

Shawn Wang calls another a popular stack STAR:

Design Systems TypeScript Apollo React

That’s JavaScript all the way down.

It’s notable that, while we’re still thinking of this as a stack, we’re thinking less about our servers and server software to the point they aren’t really a key part of the stack. Not that developers and companies don’t take it seriously, but it’s more abstracted now than it has traditionally been. I’d point to the world of serverless as a case in point. The questions aren’t about what operating system our servers should use; it’s what platform is the most cost-effective to run our JavaScript functions.

So, stacks evolve over time. But it’s not just what technologies they use, but what technology we even consider a part of a stack. What full-stack means morphs over time.. We’re in a place right now where knowing JavaScript grants you a full-stack merit badge. You can work with client site frameworks, architect components and piece them together to build an entire front end. You can write web servers. You can write back-end code that talks to APIs. You can do all the state management you need. You can construct build processes and deployment pipelines. You can even bring CSS into JavaScript if you’re so inclined.

Even if you’re largely focused on JavaScript, people’s skillsets are generally wider than that. Throw in some HTML and CSS competency, Git foo, and a little DevOps hobby and you’re a real web powerhouse. You can do it all! A renaissance man! Lord of the seven kingdoms!

I think that’s kinda awesome, actually. It truly empowers developers. While it’s worth considering where the barriers of entrance for front-end development or high, it’s also interesting to consider all the places where that bar has been lowered. It’s particularly cool for me to see front-end development grow and grow to the point of nearly swallowing up the entire stack. The All-Powerful Front-End Developer, as it were.

It reminds me an awful lot of how powerful being a WordPress site-slinger feels. You can do a lot, even if you don’t deeply understand every little bit of it.

My conference acquaintance went on:

Why are some developers so proud of being a full stack? Many of them say it with a prideful smile. They, for some reason, feel the need to emphasize full stack when introducing themselves.

I suspect it’s just that: Pride.

Pride is a tricky thing. It meant the world to me when my parents ceaselessly told me they were proud of me or something I did. A positive thing on both sides. But, strangely enough, pride is also one of the seven deadly sins and one, as they say, that might be the root of all the rest. I don’t want to over-blow things, but I think there is some connection here. It’s one thing to be empowered and to feel strong and capable, but it’s another to be boastful and not sense the edges of your ability.

We’ve all got plenty of edges, particularly when it comes to doing an exemplary job versus merely getting the job done. Standing out these days requires being exemplary. How is your visual design skill? Are you building design systems or implementing existing ones? How many years have you maintained systems? Do you have a good eye for the most painful kinds of technical debt? How are you at helping co-workers succeed? Can you facilitate a user testing session? How good are you at diagnosing performance bottlenecks? What if there are serious server problems? Does your full stack moniker help you comprehend server logs? Are you versed in accessibility audits? Have you ever dealt with tricky relational data and slow queries?

I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills. If you’re interviewing for a job asking for a full-stack developer, by all means, tell them how full-stack-y you are.

The post What Does it Mean to Be “Full Stack”? appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Edge Goes Chromium: What Does it Mean for Front-End Developers?

In December 2018, Microsoft announced that Edge would adopt Chromium, the open source project that powers Google Chrome. Many within the industry reacted with sadness at the loss of browser diversity. Personally, I was jubilant. An official release date has yet to be announced, but it will be at some point this year. With its release, a whole host of HTML, JavaScript and CSS features will have achieved full cross-browser support.

The preview build is now available for Windows, and coming soon for Mac.

Not so long ago, I penned an article titled “The Long Slow Death of Internet Explorer.” Some of us are lucky enough have abandoned that browser already. But it wasn’t the only thing holding us back. Internet Explorer was the browser we all hated and Edge was meant to be its much-improved replacement. Unfortunately, Edge itself was quite the laggard. EdgeHTML is a fork of Trident, the engine that powered Internet Explorer. Microsoft significantly under-invested in Edge. The apple didn’t fall far from the tree. Edge’s User Voice website was a nice idea, allowing developers to vote for which features they wanted to be implemented. Unfortunately, as Dave Rupert put it, voting on the site was “like throwing coins in a wishing well.” The most requested features were left unimplemented for years.

There are a lot of features that pre-Chromium Edge doesn’t currently support but are available in other modern browsers and, once they’ve made the switch, we’ll be able to use them. Many of them can’t be polyfilled or worked around, so this release is a big deal.

caniuse.com comparing the final non-Chromium version of Edge to the other popular modern browser

Features we can look forward to using

So just what are those features, exactly? Let’s outline them right here and start to get excited about all the new things we’ll be able to do.

Custom Elements and Shadow DOM

Together, custom elements and shadow DOM allow developers to define custom, reusable and encapsulated components. A lot of people were asking for this one. People have been voting for its implementation since 2014, and we’re finally getting it.

HTML details and summary elements

The <details> and <summary> elements are part of HTML5 and have been supported since 2011 in Chrome. Used together, the elements generate a simple widget to show and hide content. While it is trivial to implement something similar using JavaScript, the <details> and <summary> elements work even when JavaScript is disabled or has failed to load.

See the Pen
details/summary
by CSS GRID (@cssgrid)
on CodePen.

Javascript Font Loading API

This one means a lot to some people. All modern browsers now support the CSS font-display property. However, you still might want to load your fonts with JavaScript. Font-loading monomaniac Zach Leatherman has an explainer of why you might want to load fonts with JavaScript even though we now have broad support for font-display. Ditching polyfills for this API is important because this JavaScript is, according to Zach:

[…] usually inlined in the critical path. The time spent parsing and executing polyfill JavaScript is essentially wasted on browsers that support the native CSS Font Loading API.”

In an article from 2018, Zach lamented:

[…] browser-provided CSS Font Loading API has pretty broad support and has been around for a long time but is confoundedly still missing from all available versions of Microsoft Edge.”

No longer!

JavaScript flat and flatMap

Most easily explained with a code snippet, flat() is useful when you have an array nested inside another array.

const things = ['thing1', 'thing2', ['thing3', ['thing4']]] const flattenedThings = things.flat(2); // Returns ['thing1', 'thing2', 'thing3', 'thing4']

As its name suggests, flatMap() is equivalent to using both the map() method and flat().

These methods are also supported in Node 11. 🎉

JavaScript TextEncoder and TextDecoder

TextEncoder and TextDecoder are part of the encoding spec. They look to be useful when working with streams.

JavaScript Object rest and object spread

These are just like rest and spread properties for arrays.

const obj1 = {   a: 100,   b: 2000 }  const obj2 = {   c: 11000,   d: 220 }  const combinedObj = {...obj1, ...obj2}  // {a: 100, b: 2000, c: 11000, d: 220}

JavaScript modules: dynamic import

Using a function-like syntax, dynamic imports allow you to lazy-load ES modules when a user needs them.

button.addEventListener("click", function() {   import("./myModule.js").then(module => module.default()); });

CSS background-blend-mode property

background-blend-mode brings Photoshop style image manipulation to the web.

CSS prefers-reduced-motion media query

I can’t help feeling that not making people feel sick should be the default of a website, particularly as not all users will be aware that this setting exists. As animation on the web becomes more common, it’s important to recognize that animation can cause causes dizziness, nausea and headaches for some users.

CSS font-display property

font-display has been well-covered on CSS-Tricks before. It’s a way to control the perceived performance of font loading.

CSS caret-color property

Admittedly a rather trivial feature, and one that could have safely and easily been used as progressive enhancement. It lets you style the blinking cursor in text input fields.

8-digit hex color notation

It’s nice to have consistency in a codebase. This includes sticking to either
the RGB, hexadecimal or HSL color format. If your preferred format is hex, then you had a problem because it required a switch to rgba() any time you needed to define transparency. Hex can now include an alpha (transparency) value. For example, #ffffff80 is equivalent to rgba(255, 255, 255, .5). Arguably, it’s not the most intuitive color format and has no actual benefit over rgba().

Intrinsic sizing

I’ve not seen as much hype or excitement for intrinsic sizing as some other new CSS features, but it’s the one I’m personally hankering for the most. Intrinsic sizing determines sizes based on the content of an element and introduces three new keywords into CSS: min-content, max-content and fit-content(). These keywords can be used most places that you would usually use a length, like height, width, min-width, max-width, min-height, max-height, grid-template-rows, grid-template-columns, and flex-basis.

CSS text-orientation property

Used in conjunction with the writing-mode property, text-orientation, specifies the orientation of text, as you might expect.

See the Pen
text-orientation: upright
by CSS GRID (@cssgrid)
on CodePen.

CSS :placeholder-shown pseudo-element

placeholder-shown was even available in Internet Explorer, yet somehow never made it into Edge… until now. UX research shows that placeholder text should generally be avoided. However, if you are using placeholder text, this is a handy way to apply styles conditionally based on whether the user has entered any text into the input.

CSS place-content property

place-content is shorthand for setting both both the align-content and justify-content.

See the Pen
place-content
by CSS GRID (@cssgrid)
on CodePen.

CSS will-change property

The will-change property can be used as a performance optimization, informing the browser ahead of time that an element will change. Pre-Chromium Edge was actually good at handling animations performantly without the need for this property, but it will now have full cross-browser support.

CSS all property

button { background: none; border: none; color: inherit; font: inherit; outline: none; padding: 0; }

Sadly, though, the revert keyword still hasn’t been implemented anywhere other than Safari, which somewhat limits the mileage we can get out of the all property.

CSS Shapes and Clip Path

Traditionally, the web has been rectangle-centric. It has a box model, after all. While we no longer need floats for layout, we can use them creatively for wrapping text around images and shapes with the shape-outside property. This can be combined with the clip-path property, which brings the ability to display an image inside a shape.

Clippy is an online clip-path editor

CSS :focus-within pseudo-class

If you want to apply special styles to an entire form when any one of its inputs are in focus, then :focus-within is the selector for you.

CSS contents keyword

This is pretty much essential if you’re working with CSS grid. This had been marked as “not planned” by Edge, despite 3,920 votes from developers.

For both flexbox and grid, only direct children become flex items or grid items, respectively. Anything that is nested deeper cannot be placed using flex or grid-positioning. In the words of the spec, when display: contents is applied to a parent element, “the element must be treated as if it had been replaced in the element tree by its contents,” allowing them to be laid out with a grid or with flexbox. Chris goes into a more thorough explanation that’s worth checking out.

There are, unfortunately, still some bugs with other browser implementations that affect accessibility.

The future holds so much more promise

We’ve only looked at features that will be supported by all modern browsers when Edge makes the move to Chromium. That said, the death of legacy Edge also makes a lot of other features feel a lot closer. Edge was the only browser dragging its feet on the Web Animation API and that showed no interest in any part of the Houdini specs, for example.

Credit: https://ishoudinireadyyet.com

The impact on browser testing

Testing in BrowserStack (left) and various browser apps on my iPhone (right)

Of course, the other huge plus for web developers is less testing. A lot of neglected Edge during cross-browser testing, so Edge users were more likely to have a broken experience. This was the main reason Microsoft decided to switch to Chromium. If your site is bug-free in one Chromium browser, then it’s probably fine in all of them. In the words of the Edge team, Chromium will provide “better web compatibility for our customers and less-fragmentation of the web for all web developers.” The large variety of devices and browsers makes browser testing one of the least enjoyable tasks that we’re responsible for as front-end developers. Edge will now be available for macOS users which is great for the many of us who work on a Mac. A subscription to BrowserStack will now be slightly less necessary.

Do we lose anything?

To my knowledge, the only feature that was supported everywhere except Chrome is SVG color fonts, which will no longer work in the Edge browser. Other color font formats (COLR, SBIX, CBDT/CBLC) will continue to work though.

What about other browsers?

Admittedly, Edge wasn’t the last subpar browser. All the features in this article are unsupported in Internet Explorer, and always will be. If you have users in Russia, you’ll need to support Yandex. If you have users in Africa, you’ll need to support Opera Mini. If you have users in China, then UC and QQ will be important to test against. If you don’t have these regional considerations, there’s never been a better time to ditch support for Internet Explorer and embrace the features the modern web has to offer. Plenty of PC users have stuck with Internet Explorer purely out of habit. Hopefully, a revamped Edge will be enough to tempt them away. An official Microsoft blog entry titled “The perils of using Internet Explorer as your default browser” concluded that, “Internet Explorer is a compatibility solution…developers by and large just aren’t testing for Internet Explorer these days.” For its remaining users, the majority of the web must look increasingly broken. It’s time to let it die.

Is Google a megalomaniac?

Life is about to get easier for web developers, yet the response to the Microsoft’s announcement was far from positive. Mozilla, for one, had a stridently pessimistic response, which accused Microsoft of “officially giving up on an independent shared platform for the internet.” The statement described Google as having “almost complete control of the infrastructure of our online lives” and a “monopolistic hold on unique assets.” It concluded that “ceding control of fundamental online infrastructure to a single company is terrible.”

Many have harked back to the days of IE6, the last time a browser achieved such an overwhelming market share. Internet Explorer, having won the browser war, gave in to total stagnation. Chrome, by contrast, ceaselessly pushes new features. Google participates actively with the web standards bodies the W3C and the WHATWG. Arguably though, it has an oversized influence in these bodies and the power to dictate the future shape of the web. Google Developer Relations does have a tendency to hype features that have shipped only in Chrome.

From competition to collaboration

Rather than being the new IE, Edge can help innovate the web forward. While it fell behind in many areas, it did lead the way for CSS grid, CSS exclusions, CSS regions and the new HTML imports spec. In a radical departure from historical behavior, Microsoft have become one of the world’s largest supporters of open source projects. That means all major browsers are now open source. Microsoft have stated that they intend to become a significant contributor to Chromium — in fact, they’ve already racked up over 300 merges. This will help Edge users, but will also benefit users of Chrome, Opera, Brave, and other Chromium-based browsers.

The post Edge Goes Chromium: What Does it Mean for Front-End Developers? appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

What Hooks Mean for Vue

Not to be confused with Lifecycle Hooks, Hooks were introduced in React in v16.7.0-alpha, and a proof of concept was released for Vue a few days after. Even though it was proposed by React, it’s actually an important composition mechanism that has benefits across JavaScript framework ecosystems, so we’ll spend a little time today discussing what this means.

Mainly, Hooks offer a more explicit way to think of reusable patterns — one that avoids rewrites to the components themselves and allows disparate pieces of the stateful logic to seamlessly work together.

The initial problem

In terms of React, the problem was this: classes were the most common form of components when expressing the concept of state. Stateless functional components were also quite popular, but due to the fact that they could only really render, their use was limited to presentational tasks.

Classes in and of themselves present some issues. For example, as React became more ubiquitous, stumbling blocks for newcomers did as well. In order to understand React, one had to understand classes, too. Binding made code verbose and thus less legible, and an understanding of this in JavaScript was required. There are also some optimization stumbling blocks that classes present, discussed here.

In terms of the reuse of logic, it was common to use patterns like render props and higher-order components, but we’d find ourselves in similar “pyramid of doom” — style implementation hell where nesting became so heavily over-utilized that components could be difficult to maintain. This led me to ranting drunkenly at Dan Abramov, and nobody wants that.

Hooks address these concerns by allowing us to define a component’s stateful logic using only function calls. These function calls become more compose-able, reusable, and allows us to express composition in functions while still accessing and maintaining state. When hooks were announced in React, people were excited — you can see some of the benefits illustrated here, with regards to how they reduce code and repetition:

In terms of maintenance, simplicity is key, and Hooks provide a single, functional way of approaching shared logic with the potential for a smaller amount of code.

Why Hooks in Vue?

You may read through this and wonder what Hooks have to offer in Vue. It seems like a problem that doesn’t need solving. After all, Vue doesn’t predominantly use classes. Vue offers stateless functional components (should you need them), but why would we need to carry state in a functional component? We have mixins for composition where we can reuse the same logic for multiple components. Problem solved.

I thought the same thing, but after talking to Evan You, he pointed out a major use case I missed: mixins can’t consume and use state from one to another, but Hooks can. This means that if we need chain encapsulated logic, it’s now possible with Hooks.

Hooks achieve what mixins do, but avoid two main problems that come with mixins:

  • They allows us to pass state from one to the other.
  • They make it explicit where logic is coming from.

If we’re using more than one mixin, it’s not clear which property was provided by which mixin. With Hooks, the return value of the function documents the value being consumed.

So, how does that work in Vue? We mentioned before that, when working with Hooks, logic is expressed in function calls that become reusable. In Vue, this means that we can group a data call, a method call, or a computed call into another custom function, and make them freely compose-able. Data, methods, and computed now become available in functional components.

Example

Let’s go over a really simple hook so that we can understand the building blocks before we move on to an example of composition in Hooks.

useWat?

OK, here’s were we have, what you might call, a crossover event between React and Vue. The use prefix is a React convention, so if you look up Hooks in React, you’ll find things like useState, useEffect, etc. More info here.

In Evan’s live demo, you can see where he’s accessing useState and useEffect for a render function.

If you’re not familiar with render functions in Vue, it might be helpful to take a peek at that.

But when we’re working with Vue-style Hooks, we’ll have — you guessed it — things like: useData, useComputed, etc.

So, in order for us look at how we’d use Hooks in Vue, I created a sample app for us to explore.

In the src/hooks folder, I’ve created a hook that prevents scrolling on a useMounted hook and reenables it on useDestroyed. This helps me pause the page when we’re opening a dialog to view content, and allows scrolling again when we’re done viewing the dialog. This is good functionality to abstract because it would probably be useful several times throughout an application.

import { useDestroyed, useMounted } from "vue-hooks";  export function preventscroll() {   const preventDefault = (e) => {     e = e || window.event;     if (e.preventDefault)       e.preventDefault();     e.returnValue = false;   }    // keycodes for left, up, right, down   const keys = { 37: 1, 38: 1, 39: 1, 40: 1 };    const preventDefaultForScrollKeys = (e) => {     if (keys[e.keyCode]) {       preventDefault(e);       return false;     }   }    useMounted(() => {     if (window.addEventListener) // older FF       window.addEventListener('DOMMouseScroll', preventDefault, false);     window.onwheel = preventDefault; // modern standard     window.onmousewheel = document.onmousewheel = preventDefault; // older browsers, IE     window.touchmove = preventDefault; // mobile     window.touchstart = preventDefault; // mobile     document.onkeydown = preventDefaultForScrollKeys;   });    useDestroyed(() => {     if (window.removeEventListener)       window.removeEventListener('DOMMouseScroll', preventDefault, false);      //firefox     window.addEventListener('DOMMouseScroll', (e) => {       e.stopPropagation();     }, true);      window.onmousewheel = document.onmousewheel = null;     window.onwheel = null;     window.touchmove = null;     window.touchstart = null;     document.onkeydown = null;   }); } 

And then we can call it in a Vue component like this, in AppDetails.vue:

<script> import { preventscroll } from "./../hooks/preventscroll.js"; ...  export default {   ...   hooks() {     preventscroll();   } } </script>

We’re using it in that component, but now we can use the same functionality throughout the application!

Two Hooks, understanding each other

We mentioned before that one of the primary differences between hooks and mixins is that hooks can actually pass values from one to another. Let’s look at that with a simple, albeit slightly contrived, example.

Let’s say in our application we need to do calculations in one hook that will be reused elsewhere, and something else that needs to use that calculation. In our example, we have a hook that takes the window width and passes it into an animation to let it know to only fire when we’re on larger screens.

In the first hook:

import { useData, useMounted } from 'vue-hooks';  export function windowwidth() {   const data = useData({     width: 0   })    useMounted(() => {     data.width = window.innerWidth   })    // this is something we can consume with the other hook   return {     data   } }

Then, in the second we use this to create a conditional that fires the animation logic:

// the data comes from the other hook export function logolettering(data) {   useMounted(function () {     // this is the width that we stored in data from the previous hook     if (data.data.width > 1200) {       // we can use refs if they are called in the useMounted hook       const logoname = this.$  refs.logoname;       Splitting({ target: logoname, by: "chars" });        TweenMax.staggerFromTo(".char", 5,         {           opacity: 0,           transformOrigin: "50% 50% -30px",           cycle: {             color: ["red", "purple", "teal"],             rotationY(i) {               return i * 50             }           }         },         ...

Then, in the component itself, we’ll pass one into the other:

<script> import { logolettering } from "./../hooks/logolettering.js"; import { windowwidth } from "./../hooks/windowwidth.js";  export default {   hooks() {     logolettering(windowwidth());   } }; </script>

Now we can compose logic with Hooks throughout our application! Again, this is a contrived example for the purposes of demonstration, but you can see how useful this might be for large scale applications to keep things in smaller, reusable functions.

Future plans

Vue Hooks are already available to use today with Vue 2.x, but are still experimental. We’re planning on integrating Hooks into Vue 3, but will likely deviate from React’s API in our own implementation. We find React Hooks to be very inspiring and are thinking about how to introduce its benefits to Vue developers. We want to do it in a way that complements Vue’s idiomatic usage, so there’s still a lot of experimentation to do.

You can get started by checking out the repo here. Hooks will likely become a replacement for mixins, so although the feature still in its early stages, it’s probably a concept that would be beneficial to explore in the meantime.

(Sincere thanks to Evan You and Dan Abramov for proofing this article.)

The post What Hooks Mean for Vue appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

Designing for the web ought to mean making HTML and CSS

David Heinemeier Hansson has written an interesting post about the current state of web design and how designers ought to be able to still work on the code side of things:

We build using server-side rendering, Turbolinks, and Stimulus. All tools that are approachable and realistic for designers to adopt, since the major focus is just on HTML and CSS, with a few sprinkles of JavaScript for interactivity.

And it’s not like it’s some well kept secret! In fact, every single framework we’ve created at Basecamp that allows designers to work this way has been open sourced. The calamity of complexity that the current industry direction on JavaScript is unleashing upon designers is of human choice and design. It’s possible to make different choices and arrive at different designs.

I like this sentiment a whole lot — not every company needs to build their websites the same way. However, I don’t think that the approach that Basecamp has taken would scale to the size of a much larger organization. David continues:

Also not interested in retreating into the idea that you need a whole team of narrow specialists to make anything work. That “full-stack” is somehow a point of derision rather than self-sufficiency. That designers are so overburdened with conceptual demands on their creativity that they shouldn’t be bordered or encouraged to learn how to express those in the native materials of the web. Nope. No thanks!

Designing for the modern web in a way that pleases users with great, fast designs needn’t be this maze of impenetrable complexity. We’re making it that! It’s possible not to.

Again, I totally agree with David’s sentiment as I don’t think there’s anyone in the field who really wants to make the tools we use to build websites overly complicated; but in this instance, I tend to agree with what Nicolas recently had to say on this matter:

The interesting thing to note here is that the act of front-end development changes based on the size and scale of the organization. As with all arguments in front-end development, there is no “right” way! Our work has to adapt to the problems that we’re trying to solve. Is a large, complex React front-end useful for Basecamp? Maybe not. But for some organizations, like mine at Gusto, we have to specialize in certain areas because the product that we’re working on is so complicated.

I guess what I also might be rambling about is that I don’t think it’s engineers that are making front-end development complicated — perhaps it’s the expectations of our users.

Direct Link to ArticlePermalink

The post Designing for the web ought to mean making HTML and CSS appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]