If you are lazy loading, do you really need to do the content-visibilty thing also? They seem very related.
Serving AVIF is usually good, but it seems less cut-and-dry than WebP was. You need to make sure your AVIF version is both better and smaller, which feels like a manual process right now.
The decoding thing seems weird. I’ll totally use it if it’s a free perf win, but if it’s always a good idea, shouldn’t the browser just always do it?
I’m not super convinced blurry placeholders are in the same category of necessary as the rest of this stuff. Feels like a trend.
I can’t stop thinking about this site. It looks like a pretty standard fare; a website with links to different pages. Nothing to write home about except that… the whole website is contained within a single HTML file.
What about clicking the navigation links, you ask? Each link merely shows and hides certain parts of the HTML.
<section id="home">
<!-- home content goes here -->
</section>
<section id="about">
<!-- about page goes here -->
</section>
Each <section> is hidden with CSS:
section { display: none; }
Each link in the main navigation points to an anchor on the page:
And once you click a link, the <section> for that particular link is displayed via:
section:target { display: block; }
See that :target pseudo selector? That’s the magic! Sure, it’s been around for years, but this is a clever way to use it for sure. Most times, it’s used to highlight the anchor on the page once an anchor link to it has been clicked. That’s a handy way to help the user know where they’ve just jumped to.
Anyway, using :target like this is super smart stuff! It ends up looking like just a regular website when you click around:
Anyone of you can check my website and let me know that how i've done its designing and its seo is good or not? Should i carry on with some links at the backend strategy or you guys can suggest me some tools.
Adam Argyle has a post over on web.dev digging into this. He starts with the assumption that you need to do vertical centering and horizontal centering. It’s that vertical centering that has traditionally been a bit trickier for folks, particularly when the height of the content is unknown.
Adam details five(!) methods for handling it, even getting into centering unknown vertical and horizontal dimensions, plus a handful of other restraints like language direction and multiple elements. I guess all the silly jokes about the difficulty of centering things in CSS need to be updated. Maybe they should poke fun about how many great ways there are to center things in CSS.
Adam does a great job listing out the pros and cons of all the techniques, and demonstrating them clearly. There is also a video. He picks “the gentle flex” as the winning approach:
You can always find it in my stylesheets because it’s useful for both macro and micro layouts. It’s an all-around reliable solution with results that match my expectations. Also, because I’m an intrinsic sizing junkie, I tend to graduate into this solution. True, it’s a lot to type out, but the benefits it provides outweighs the extra code.
Remember that when you’re “centering in CSS” it’s not always within these extreme situations. Let’s look at another situation, just for fun. Say you need to horizontally center some inline-*¹ elements… text-align: center; gets you there as a one-liner:
But what if you need to center the parent of those items? You’d think you could do a classic margin: 0 auto; thing, and you can, but it’s likely the parent is block-level and thus either full-width or has a fixed width. Say instead you want it to be as wide as the content it contains. You could make the parent inline-*, but then you need another parent in which to set the text-align on to get it centered.
Stefan Judis talked about this recently. The trick is to leave the element block-level, but use width: fit-content;
The ol’ gentle flex could have probably gotten involved here too, but we’d need an additional parent again. Always something to think about.
What I mean by inline-* is: inline, inline-block, inline-flex, inline-grid, or inline-table. Did I miss any?
Me, I really dislike FOUT. I like that it’s an option, because not displaying text quickly on the web is no good. I know font-display: swap; is popular because it’s good for performance, but that FOUT stuff pains me. Matt Hobbs:
If there’s one thing I’d like readers to take away from this post it’s that font-display: swap is a very good option for users with a fast internet connection. But its infinite swap period could be frustrating for users on very slow and unstable connections. If you have users viewing your site under these conditions (I’m pretty certain you will at some point in time), then it may be worth considering font-display: fallback or even font-display: optional.
Seeeee, I told ya. I like how font-display: optional; totally stops FOUT. The font is either applied super fast, or isn’t used at all (but still downloaded async). Chances are, on the next page load, the font is loaded and cached and will be used.
Note this is about slow connections, not necessarily connections where the user would prefer as little data usage as possible. If that’s the case, check out some of the recent posts we linked up in Responsible, Conditional Loading.
This article has no byline and is on a website that is even more weirdly specific than this one is, but I appreciate the trick here. A seven-column grid makes for a calendar layout pretty quick. You can let the days (grid items) fall onto it naturally, except kick the first day over to the correct first column with grid-column-start.
Thoughts:
I’d go with an <ol> rather than a <ul> just because it seems like days are definitely ordered.
The days as-a-list don’t really bother me since maybe that makes semantic sense to the content of the calendar (assuming it has some)
But… seeing the titles of the days-of-the-week as the first items in the same list feels weird. Almost like that should be a separate list or something.
Or maybe it should all just be a <table> since it’s sort of tabular data (it stands to reason you might want to cross-reference and look at all Thursdays or whatever).
I feel we, the community, have to acknowledge that CSS is easy to get started with and hard to master. Let’s reflect on the language and find out what makes it hard.
Tim’s reasons CSS is hard (in my own words):
You can look at a matching Ruleset, and still not have the whole styling story. There might be multiple matching rulesets in disparate places, including in places that only apply conditionally, like within @media queries.
Even if you think you’ve got a complete handle on the styling information in the CSS, you still may not, because styling is DOM-dependent. You need information from both places to know how something will be styled.
You have no control over the device, browser, version, resolution, input mode, etc., all of which can be CSS concerns.
Making changes to CSS can be scary because it’s hard to understand everywhere it applies.
I’m not sure people making sweeping generalizations about CSS either being too hard or too easy is helpful for anyone. It’s much more interesting to look at what can be straightforward about CSS and what can be tricky, like Tim has done here.
How you approach measuring a web page’s performance can tell you whether it’s built for speed or whether it feels fast. We call them lab and field tools. Lab tools are the microscopes that inspect a page for all possible points of friction. Field tools are the binoculars that give you an overview of how users are experiencing the page.
This to me suggests that field tools are the future of performance monitoring. But Rick’s post goes into a lot more depth beyond that.
If you’re purely talking about perceived performance and connection speed isn’t an issue then I’d say font-display: swap is best. When used, this setting renders the fallback font almost instantly. Allowing a user to start reading page content while the webfont continues to load in the background. Once loaded the font is swapped in accordingly. On a fast, stable connection this usually happens very quickly.
My recommendation here would be to care deeply about the layout shift if you use this property. Once the font loads and is swapped out you could create a big shift of text moving all about over the place. I once shipped a change to a site with this property without minding the layout shift and users complained a lot.
It was a good lesson learned: folks sure care about performance even if they don’t say that out loud. They care deeply about “cumulative layout shift” too.
Do you want to add a WordPress logout link to your site?
If you run a membership site, bbPress forum, eCommerce store, or a learning management system (LMS) using WordPress, having a prominent logout link is helpful for your users.
In this article, we will show you how to add the WordPress logout link to your navigation menu, as well as to other areas of your site.
The Logout Link for WordPress
Normally you can log out of your WordPress site by clicking on the logout link. This link is located below your profile picture in the top right corner of the WordPress admin bar.
All you have to do is take your mouse over to your username, and it will appear in the dropdown menu.
In case you or your site administrator have disabled the WordPress admin bar, then you will not be able to see the WordPress logout link.
The good thing is that the WordPress logout link can be directly accessed to log out of your current WordPress session.
The logout link for your WordPress site looks like this:
http://example.com/wp-login.php?action=logout
Don’t forget to replace example.com with your own domain name.
You can access this link directly in your browser window to log out of your WordPress site.
When you visit the WordPress logout link, it will take you to a warning page. You will need to click on the logout link to confirm that you really want to log out.
You can also manually add this logout link anywhere on your WordPress site. Let’s take a look at how to do that.
Video Tutorial
If you don’t like the video or need more instructions, then continue reading.
Adding the Logout Link in WordPress Navigation Menus
Adding the WordPress logout link in your site’s navigation menu will make it easily accessible from any page on your website.
Simply head over to the Appearance » Menus page in your WordPress admin. After that, you need to click on the custom links tab to expand it and add the logout link in the URL field.
Once you are done, click on the ‘Add to menu’ button, and you will notice the link appear in the right column. You can adjust its position by simply dragging it up or down.
Don’t forget to click on the ‘Save Menu’ button to store your changes.
You can now visit your website to see the logout link in your navigation menu.
The problem with adding the logout link in the menu is that it is visible to all users (both logged-in and logged-out). It only makes sense to show the logout link to users who are actually logged in.
I first blogged about responsive data tables in 2011. When responsive web design was first becoming a thing, there were little hurdles like data tables that had to be jumped. The nature of <table> elements are that they have something a minimum width depending on the content they contain and that can easily exceed the width of a small screen device.
This image I made then still covers the issue pretty well:
Except… maybe they don’t equally suck. If that image on the left were scrollable, then maybe that’s actually… not so bad. In fact, that’s what I’ve done right here on CSS-Tricks recently. I think it’s the safest way of handling responsive tables when you have no idea what content the table contains. That’s the case here, where I need to set up base table styles that apply to any blog post which may contain a table.
The crux of the idea of a scrollable table is to wrap it in a <div> that has overflow: auto; on it. That way the <table> inside is free to exceed the width of the parent, but it won’t “blow out the width” and instead triggers a scrollbar. This isn’t quite enough though, so here’s Adrian Roselli with the real scoop. The wrapping <div> needs to be focusable and labelled, so:
If you’re going to further engineer responsive tables, there are all sorts of options. One of the classics is to display: block a lot of the elements, meaning that all the data in a row (<tr>) ends up as a chunk of stacked content together that stands less of a chance of breaking the parent element’s width. You can get all the data labels properly with pseudo-elements. But, this only makes sense when individual rows of content make perfect sense alone. That’s not the case with every table. A table’s purpose might be cross-referencing data, and in that case, you’ve ruined that with this approach. So again, there are nice approaches for responsive tables when you know exactly the content and purpose of the table. But the best responsive solution when you don’t know is to just make sure they are swipeable.
I was going to add a CodePen logo but there is already one in there at 375 Bytes. I’ve got one at 208 Bytes, based on a logo update David DeSandro did for us a couple years back.
The survey results from the State of CSS aren’t out yet, but they made this landing page that randomly shows you what one person wrote to answer that question. Just clicking the reload button a bunch, I get the sense that the top answers are:
Container Queries
Parent Selectors
Nesting
Something extremely odd that doesn’t really make sense and makes me wonder about people
Great tutorial from Alex Trost (based on some demos, like this one, from Andy Barefoot) showcasing how, while CSS grid has straight grid lines across and down, you can place items across grid lines creating a staggered effect that looks pretty rad. Grid-like, but it appears to align to diagonal lines rather than horizontal and vertical lines because of the staggering. And you still get all the flexibility of grid!
Just a little post I wrote up over at The Events Calendar blog. The idea is that a set of blocks can be grouped together in WordPress, then registered in a register_block_pattern() function that makes the group available to use as a “block pattern” in any page or post.
Block patterns are becoming upper-class citizens in the WordPress block editor. They were announced without much fanfare in WordPress 5.5 back in August, but have been given prominent real estate in the block inserter with its own tab next to blocks, including 10 or so default ones right out of the box.
Block patterns are sandwiched between Blocks and Reusable Blocks in the block inserter, which is a perfect metaphor for where it fits in the bigger picture of WordPress editing.
What I find interesting is how the blocks ecosystem is evolving. We started with a set of default blocks that can be inserted into a post. We got reusable blocks that provide a way to assemble a group of blocks with consistent content across all pages of posts. Now we have a way to do the same, but in a much more flexible and editable way. The differences are subtle, but the use cases couldn’t be more different. We’ve actually been using reusable blocks here at CSS-Tricks for post explanations, like this:
We drop some text in here when we think there’s something worth calling out or that warrants a little extra explanation.
Any reusable block can be converted to a “regular” block. The styles are maintained but the content is not. That’s been our hack-y approach for speeding up our process around here, but now that block patterns are a thing, previous reusable blocks we’ve been using now make more sense as patterns.
[On horizontal scrolling, like Netflix] This pattern is accessible, responsive and consistent across screen sizes. And it’s pretty easy to implement.
Too cold:
That’s a lot of pros for a pattern that in reality has some critical downsides.
Just right:
[On rows of content with “View All” links] This way, the content isn’t hidden; it’s easy to drill down into a category; data isn’t wasted; and an unconventional, labour intensive pattern is avoided.
Hi i am computer science students. I always confused to about php base websites or another website. Yesterday my teacher gave me assingement to check website either it is php base or other platform. But i haven't decided to give answer. I am week student in class. please help me in this regarding. I am sharing a weblink please expert tell me. is this php base or anohter platform
(https://www.malumaat.pk/latest-wapda-jobs)
Please tell above mentioned link is on php or not?
Thanks
Get that desk more cuter, fam. Amy (@sailorhg) has this perfectly cute minisite with assorted desktop backgrounds, fonts, editor themes, keyboard stuff, and other accessories. These rainbow cables are great.
