Tag: Link

A grand total of 77,609 responses from WordPress users and professionals collected by Automattic between 2015 and 2017. The stats for 2015 and 2016 have been shared at the annual State of the Word address and 2017 marks the first time they have been published on WordPress News.

A few items that caught my attention at first glance:

Between 66% and 75% of WordPress users installed WordPress on their own. In other words, they were savvy enough to do it without the help of a developer. Hosting providers were next up and clocked in at 13-14% of installs.

WordPress professionals described their clients as large and enterprise companies only 6-7% of the time. I guess this makes sense if those companies are relying on in-house resourcing, but I still would have pegged this higher.

What do users love most about WordPress? It’s simple and user-friendly (49-52%). What frustrates them most about it? Plugins and themes (19-28%). Seems like those two would go hand-in-hand to some degree.

I’m not a statistician and have no idea how much the results of these surveys accurately reflect the 26% of all sites on the internet that are powered by WordPress, but it sure is interesting.

Our goal is to create a script that will measure the percentage of unused CSS of this page. Notice that the user can interact with the page and navigate using the different tabs.

DevTools can be used to measure the amount of unused CSS in the page using the Coverage tab. Notice that the percentage of unused CSS after the page loads is ~55%, but after clicking on each of the tabs, more CSS rules are applied and the percentage drops down to just ~15%.

That’s why I’m so skeptical of anything that attempts to measure “unused CSS.” This is an incredibly simple demo (all it does is click some tabs) and the amount of unused CSS changes dramatically.

If you are looking for accurate data on how much unused CSS is in your codebase, in an automated fashion, you’ll need to visit every single URL on your site and trigger every possible event on every element and continue doing that until things stop changing. Then do that for every possible state a user could be in—in every possible browser.

Here’s another incredibly exotic way I’ve heard of it being done:

Wait a random amount of time after the page loads

Loop through all the selectors in the CSSOM

Put a querySelector on them and see if it finds anything or not

Report those findings back to a central database

Run this for enough time on a random set of visitors (or all visitors) that you’re certain is a solid amount of data representing everywhere on your site

Take your set of selectors that never matched anything and add a tiny 1px transparent GIF background image to them

Run that modified CSS for an equal amount of time

Check your server logs to make sure those images were never requested. If they were, you were wrong about that selector being unused, so remove it from the list

And the end of all that, you have a set of selectors in your CSS that are very likely to be unused.

Clever, but highly unlikely that anyone is using either of these methods in a consistent and useful way.

I’m a little scared for tools like Lighthouse that claim to audit your unused CSS telling you to “remove unused rules from stylesheets to reduce unnecessary bytes consumed by network activity.” The chances seem dangerously high that someone runs this, finds this so-called unused CSS and deletes it only to discover it wasn’t really unused.

Direct Link to Article — Permalink

Monitoring unused CSS by unleashing the raw power of the DevTools Protocol is a post from CSS-Tricks

We’ve covered fluid type a number of times. This page probably covers it in the best detail. It’s a little more complicated than simply using a vw unit to set the font-size since that’s far too dramatic. Ideally, the font-size is literally fluid between minimum and maximum values.

Someday there will be min-font-size and max-font-size (probably), but until then, our fluid type implementations will probably need to resort to some @media queries to lock those mins/maxes.

Or…

Around a year ago Matt Smith documented a technique I had missed. It calculates font-size using a little bit of vw, a little bit of vh, and a little bit of the smaller of the two…

:root { font-size: calc(1vw + 1vh + .5vmin);
}

Of course, it depends on the font and what you are doing with it, but it seems to me this tempers the curve such that you might not really need a min and max.

Vitaly Friedman swings wide with a massive list of performance considerations. It’s a well-considered mix of old tactics (cutting the mustard, progressive enhancement, etc.) and newer considerations (tree shaking, prefetching, etc.). I like the inclusion of a quick wins section since so much can be done for little effort; it’s important to do those things before getting buried in more difficult performance tasks.

Speaking of considering performance, Philip Walton recently dug into what interactive actually means, in a world where we throw around acronyms like Front-End Checklist.

Here’s something you can do: kick off 2018 with your own professional website. The only thing you’ll need to get started is your imagination, a little free time, and an innovative website builder.

Wix is the world’s most technologically advanced website builder. Sign up for Wix, choose a template, and start customizing it. Whether you’re a novice, a business owner, a sophisticated designer, or a professional website builder, you’ll have full control of your website – from design prototyping to production.

Wix takes care of all the heavy lifting. You get reliable, safe, secure hosting that you’ll never need to worry about. You get a custom domain name and email. To get started, all you need is a computer and a little time.

Don’t underestimate what you can do with Wix. There are all kinds of advanced design features and functionality if that’s something you need. The web is your playground. We’ve come along way from the website building platforms of the 90s. Now, you can create any kind of website you want and even collaborate with friends or coworkers.

Save yourself time and money, and head over to Wix.com to get started for free. Kick off 2018 strong with your own professional website and share your ideas with the world.

Monica Dinculescu on ::part and ::theme, two pseudo-elements that are very likely to gain traction and receive more attention in the new year. They’re designed to help us create and style web components, as Monica explains:

The current new proposal is ::part and ::theme, a set of pseudo-elements that allow you to style inside a shadow tree, from outside of that shadow tree. Unlike :shadow and /deep/, they don’t allow you to style arbitrary elements inside a shadow tree: they only allow you to style elements that an author has tagged as being eligible for styling. They’ve already gone through the CSS working group and were blessed, and were brought up at TPAC at a Web Components session, so we’re confident they’re both the right approach and highly likely to be implemented as a spec by all browsers.

If the whole “shadow tree” phrase makes you panic as much as me then not to worry! Monica has already written an excellent piece that goes into great depth about web components and the Shadow DOM spec, too.

The Web Hypertext Application Technology Working Group (WHATWG) announced that it has adopted a formal governance structure:

The WHATWG has operated successfully since 2004 with no formal governance structure, guided by a strong culture of pragmatism and collaboration. Although this has worked well for driving the web forward, we realized that we could get broader participation by being clear about what rights and responsibilities members of the community have. Concretely, this involves creating an IPR Policy and governance structure.

WHATWG was founded by folks at Apple, Mozilla and Opera. The new structure will be comprised of individuals from Apple, Google, Microsoft and Mozilla. The Big Four, you might say.

I find this interesting because we often think of the Web as a wild west where standards are always evolving and adopted at a different pace. This change largely keeps public contributions to the Living Standards in tact, but establishes a clearer line of communication between working groups and provides a path to appeal and resolve disputes over standards.

Living Standards are informed by input from contributors, driven by workstream participants, articulated by editors, and coordinated by the Steering Group. If necessary, controversies are resolved by the Steering Group with members appointed from the organizations that develop browser engines.

And, with representatives from leading browsers at the table, we may see more agreement with adoption. I’m speculating here, but it seems reasonable.

If you’re like me and are fuzzy on the differences between WHATWG and W3C, Bruce Lawson has a pretty simple explanation. It still kinda blows my mind that they’re both standards we often refer to but come from two completely different groups.

Mina Markham on refactoring a large and complex codebase into an agile design system, slowly over time:

If you’re not lucky enough to be able to start a new design system from scratch, you can start small and work on a single feature or component. With each new project comes a new opportunity to flesh out a new part of the system, and another potential case study to secure buy-in and showcase its value. Make sure to carefully and thoroughly document each new portion of the system as it’s built. After a few projects, you’ll find yourself with a decent start to a design system.

As a side note, Mina’s point here also reminds me of an old blog post called “Things You Should Never Do” by Joel Spolsky where he talks about how all this work and all this code you feel you needs to be refactored is actually solving a problem. Deleting everything and starting from scratch is almost never a good idea:

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

I’m not entirely sure that Joel’s piece about programming fits snuggly with Mina’s point but I think it’s an interesting one to make nonetheless: new code doesn’t necessarily mean that it’s better.

Yeah, we see browser updates all the time these days and you may have already caught this one. Aside from slick new JavaScript features, there is one new CSS update in Chrome 63 that is easy to overlook but worth calling out:

Chrome 63 now supports the CSS overscroll-behavior property, making it easy to override the browser’s default overflow scroll behavior.

The property is interesting because it natively supports the pull to refresh UI that we often see in native and web apps, defines scrolling regions that are handy for popovers and slide-out menus, and provides a method to control the rubber-banding effect on some touch devices so that a page does a hard stop at the top and bottom of the viewport.

For now, overscroll-behavior is not a W3C standard (here’s the WICG proposed draft). It’s currently only supported by Chrome (63, of course) which also means it’s in Opera (version 50). Chrome Platform Status reports that it is currently in development for Firefox and has public support from Edge.