Case Study: Armur—Alexandra Murgu Portfolio
Behind the scenes of one of Artemii Lebedev's projects: Armur, a portfolio website for the film industry, created for Alexandra Murgu.
Case Study: Design Education Series
Explore how the Design Education Series (DES) by Obys Agency was developed to provide a dynamic and engaging learning experience with innovative design and 3D features.
Design Finds: Detail Hovers on Images
A set of diverse image effects that reveal some more information on hover.
Recent Design Finds: Compact Navigation
A little collection of website menus that are compact and open into nifty boxes or shapes.
A Selection of Fonts That Future-Proof Your Web Design
A small selection of fonts ideal for keeping your web design timeless and forward-looking.
Early Days of Container Style Queries
We’re still in suuuuuper early days with container queries. Too early for broad browser support, but Chromium already supports it, Safari started supporting it in version 16, and Firefox is presumably not far behind.
Most early days conversations revolving around container queries usually compare the syntax to media queries.
/* Stacked flex container */
.post {
display: flex;
flex-direction: column;
}
/* Change direction when viewport is 600px or wider */
@media(min-width: 600px) {
.post {
flex-direction: row;
}
}/* Define the container */
.posts {
container-name: posts;
container-type: inline-size;
}
.post {
display: flex;
flex-direction: column;
}
/* Query the container's min-width */
@container posts (min-width: 600px) {
/* Change styles when `posts` container is 600px or wider */
.post {
flex-direction: row;
}
}Both of these are making queries for min-width: 600. The difference is that the media query is looking at the viewport’s width to trigger those style changes while the container query is looking at the computed width of the .posts element. Sweet!
But after listening to CSS Podcast Episode 59, Una and Adam poked at the future of container queries: style queries! The current working draft of the CSS Containment Module Level 3 spec defines container style queries:
A container style query allows querying the computed values of the query container. It is a boolean combination of individual style features (<style-feature>) that each query a single, specific property of the query container.
But no examples on syntax just yet — only a brief description:
The syntax of a <style-feature> is the same as for a declaration, and its query is true if the computed value of the given property on the query container matches the given value (which is also computed with respect to the query container), unknown if the property or its value is invalid or unsupported, and false otherwise. The boolean syntax and logic combining style features into a style query is the same as for CSS feature queries. (See @supports.)
So, yes, given time we should expect to pull off something like this:
.posts {
container-name: posts;
}
@container posts (background-color: #f8a100) {
/* Change styles when `posts` container has an orange background */
.post {
color: #fff;
}
}That’s a pretty dumb example. One thing to note is that the container-type is no longer based on the container’s inline-size but by style. We could delcare that like so:
.posts {
container-name: posts;
container-type: style; /* unnecessary */
}…but all container queries are style queries by default. Well. at least as it stands today. Miriam Suzanne has a nice outline of the possible issues that might pop up with that.
Where might querying a container’s styles come in handy? I don’t know yet! But my mind gos to a few places:
- Custom property values: We’ve seen custom properties used like state indicators, such as the DRY-switching method Ana covered a while back. The value changes, and so do styles.
- Alternate dark mode approach: Instead of basing it all on a body class change that re-assigns custom property values, maybe we can change an entire color palette if, say, the body background changes color.
- More complex query conditions: Like, say, we want to apply styles when the
sizeandstyleconditions for a container are met.
Una also mentioned in the CSS Podcast that container style queries could help prevent some awkward styling situations, like if we happen to have italicized text in an already italicized blockquote:
blockquote {
container-name: quote;
}
@container quote (font-style: italic) {
em, i, q, address {
font-style: normal;
}
}Early Days of Container Style Queries originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Why Do WordPress Themes Have to Be So Hard to Use on the Backend? (Hint: They Don’t!)
Whether you’ve designed websites with only a small handful of WordPress themes or have used dozens of them over the years, we can all agree on one thing: Many WordPress themes that are visually stunning on the frontend of a website end up being ugly as sin and difficult to use on the backend.
Why does it have to be that way?
It doesn’t. If a WordPress theme looks and feels great on the frontend, there’s no reason why its backend doesn’t as well. BeTheme is proof of this.
BeTheme is one of the top 5 best-selling WordPress themes of all time, with more than 260,000 sales and a 4.83-star user rating. In this post, we’re going to show you some of the ways in which this WordPress theme backend is going to make your life easier as a web designer.
Upgrade your workflow with a WordPress theme backend that doesn’t suck
After you install BeTheme, you’re going to notice something is different. Gone is the drab and oftentimes cluttered and unintuitive backend of WordPress. In its place, you’ll find a clean, attractive, and useful theme dashboard and tools.
Don’t worry. WordPress and all of its content management tools are still there. But when you’re inside of BeTheme, you’ll find yourself in a space that is at once visually appealing and so easy to use you’ll wonder why the rest of WordPress isn’t built this way.
If you haven’t been inside of BeTheme before (or even lately), join us as we walk through some of its best and most useful backend features:
1. Dashboard design
Your BeTheme dashboard will appear directly under the main WordPress Dashboard link. So there’s no need to sift through the sidebar trying to figure out where your theme settings are.
It’s not just convenient access that makes the BeTheme dashboard great. Click on BeTheme or the Dashboard link and you’ll discover:
- Navigation bar that takes you to the most commonly used BeTheme tools
- Status and plugin updates
- Step-by-step website creator
- New feature announcements
- Latest pre-built websites
- Theme registration information
- Popular BeTheme integrations
Everything in the dashboard is here for the express purpose of helping you get more out of your WordPress theme. Whether it’s streamlining your website setup or discovering new features to use, the dashboard is there to help.
2. Dark/light mode
The research on dark mode and the benefits associated with it is inconclusive. That said, enough people have shown a preference for dark mode (which is why popular devices and apps offer the option now), so it could demonstrate big benefits on an individual basis.
The most common benefits that users report are reduced eye strain, better sleep, and longer lasting device batteries when using dark mode.
As a web designer, you’re working in front of a computer screen all day. If you find dark mode to be beneficial for any of these reasons, then you should find yourself a WordPress theme backend like BeTheme’s that enables you to toggle on dark mode.
3. Step-by-step website creator
When you first install a WordPress theme, it’s not always clear where you should go next. For instance, you know that your theme comes with demos, but where do you go to find them? Some themes bury their demos or pre-built websites inside their settings panel, so it can take some digging around.
BeTheme removes all the guesswork.
You’ll find the Setup Wizard under BeTheme as well as in the dashboard. Click on it and the step-by-step website creator will help you:
- Name your website.
- Choose your preferred editing mode.
- Select a page builder to work in.
- Pick the perfect pre-built website for your industry/niche.
- Remove existing content and replace it with your new site.
This whole process takes less than 30 seconds to complete — from the moment you click the setup wizard button to the time it takes to load your new site and page builder into WordPress.
4. Pre-built site previews
BeTheme has over 650 pre-built websites, with new ones being added to the collection all the time. You’ll find them under the Websites link in the dashboard or under Pre-built websites under the BeTheme sidebar menu.
As a web designer, you’ll quickly become acquainted with the options that are available — and you may even find favorites you prefer to start with.
That said, you want to make sure you’re always designing websites using the latest and greatest design trends and styles. Because of this, BeTheme places previews of its newest pre-built sites in your dashboard.
Having the newest themes front and center will be useful in a number of ways. For starters, you’ll know when you have new sites to design with. Even if you choose not to use those sites (because you already have one you like, for instance), seeing the latest styles and features will be a good source of inspiration. Either way, this will enable you to utilize the latest design trends in your website designs going forward.
5. Plugin manager
The Plugins area of BeTheme isn’t the same thing as the Plugins area in WordPress. While there is some overlap, the purpose of the BeTheme plugins manager is to give you a place to:
- View your actively installed plugins.
- Update plugins that need it.
- Install and activate recommended plugins for your pre-built website only when you need them.
It’s the last point that’s important to take note of. You won’t see any of these plugins in the WordPress plugins manager until you’ve installed them.
These recommendations come directly from BeTheme and can help you get more out of your theme and pre-built site. On the flipside of that, not installing them can also help you cut back on unnecessary plugins which will allow you to keep website performance high.
6. BeTheme support
WordPress might be the most powerful and popular content management system in the world. However, it’s a mostly community-driven platform when it comes to themes, plugins, and even providing support.
You shouldn’t have to dig through forum after forum on the WordPress.org website to find help or get answers to your questions. You shouldn’t need to leave your WordPress admin if you can help it at all either.
You won’t need to go far to get support for BeTheme.
Manual & Support are available from the BeTheme sidebar as well as the dashboard. From the support center, you’ll have access to self-support options like FAQs and Documentation. You can also submit a ticket for direct assistance.
7. Theme options
Many popular WordPress themes give users the ability to customize the theme settings. With BeTheme, in particular, you can set brand colors, choose custom fonts, establish global layouts, and configure things that are important for the user experience and SEO, like responsiveness, accessibility, and performance.
The one thing that can be annoying about these theme options is that the only way to modify them is from the main WordPress dashboard. So if you happen to be working on a page and realize the global button design hasn’t been configured or you’re dissatisfied with the default sidebar design, you have to save your changes and go to your theme’s backend.
With BeTheme, you don’t have to disrupt your workflow. You can modify your Theme Options right from where you are — be it the BeTheme dashboard or from inside the BeBuilder.
8. White label mode
The last area of the BeTheme WordPress theme backend you should know about is called BeCustom. You won’t find this under the dashboard, but you will find it under BeTheme on the sidebar.
This tool gives you the ability to white label BeTheme in certain areas. Here are some of the things you can do with BeCustom:
- Swap out Be’s branding for your design business’s own.
- Disable features that your client won’t need or that you don’t want them to have access to.
- Create a custom WordPress login and change the look of it, simultaneously making it more user-friendly and secure.
- Customize the “Welcome” message on the dashboard.
White labeling allows you to do a number of things.
First, by adding your own branding, it’ll give you a chance to reinforce your name with clients long after you complete their site. While BeTheme may be a name that designers know and trust, your clients will benefit more from seeing yours in there.
In addition, white labeling helps you make WordPress more user-friendly. If you want your clients to feel confident in owning and managing their websites after handoff, removing features they don’t need and making the WordPress theme backend more attractive will help.
Make your WordPress design projects easier to manage with BeTheme
What doesn’t BeTheme do?
For starters, it’s a multipurpose WP theme with hundreds of pre-built websites.
Secondly, it’s the fastest, most powerful page builder for WordPress, giving users control over every element within the UI.
And now BeTheme has become the best way to manage a web design project within WordPress.
Quick Tip: Clear VS Code Cache for Open Files
If you use VS Code, you might have enabled the setting for re-opening a previously open file next time the app launches. I do. I like that.
But sometimes you really, really don’t want that to happen.
I recently ran into one of those times! I had to reinstall my local copy of this site and, with it, the 3GB+ database that accompanies it. Being a WordPress site and all, I needed to open up the SQL database file to search-and-replace some stuff.
If you’ve ever tried to open a super duper large file in VS Code, then you know you might need to jiggle a few settings that increase the memory limit and all that. The app is super flexible like that. There’s even a nice extension that’ll both increase the memory and perform a search-and-replace on open.
Anyway, that big ol’ database file crashed VS Code several times and I wound up finding another way to go about things. However, VS Code keeps trying to open that file and inevitably crashes even though I nuked the file. And that means I wait for the MacOS beachball of fun to spin around before the app crashes and I can reopen it again for reals.
Well, I finally decided to fix that today and spent a little time searching around. One Stack Overflow thread suggests disabling extensions and increasing the memory limit via the command line. I’m glad that worked for some folks, but I had to keep looking.
Another thread suggests clearing the app’s cache from the command palette.
Nice, but no dice. 🎲
I wound up going with a scorched earth strategy shared by Jie Jenn in a helpful YouTube video. You’ve gotta manually trash the cached files from VS Code. The video walks through it in Windows, but it’s pretty darn similar in MacOS. The VS Code cache is located in your user folder.
Notice that I have the Backups folder highlighted there. Jie removed the files from the CachedData folder, but all that did was trigger a prompt for me to re-install the app. So, I took a risk and deleted what appeared to be a 3GB+ file in Backups. I showed that file the door and VS Code has been happy ever since.
Ask me again in a week and maybe I’ll find out that I really screwed something up. But so far, so good!
Quick Tip: Clear VS Code Cache for Open Files originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Help Shape the Future of CSS-Tricks!
Hey, so it’s been a minute since we announced that CSS-Tricks is now part of the DigitalOcean family. Things are pretty much business as usual and hopefully it feels that way to you, too. Now that we’re getting settled, we’re eager to start poking at the future of this site.
What sort of things are we poking at? Well, that’s where you come in. You see, there’s no shortage of ideas for CSS-Tricks, but we only want to work on things that continue to make CSS-Tricks one of the spots you come to time and again for all things front-end (including actual CSS tricks).
So, we put together a short little survey for you. Nothing crazy, just a few questions to help us vet those ideas and ultimately shape the future of CSS-Tricks.
Thanks so much for your help! And while I have you, thanks for continuing to hang with us. In the seven years I’ve been working here at CSS-Tricks, I know this site wouldn’t even be here today without y’all. Here’s to the future of CSS-Tricks and learning together!
CSS-Tricks Newsletter
Oh, and one more update for all of you who miss the newsletter: it will be back! But we had to drop a ton of you off the list (seriously, like 80% of all subscribers) to be compliant with legal stuff that’s over my head. No worries, though, because you can re-subscribe right down here with your email address.
Help Shape the Future of CSS-Tricks! originally published on CSS-Tricks. You should get the newsletter.
Multi-Value CSS Properties With Optional Custom Property Values
Imagine you have an element with a multi-value CSS property, such as transform: optional custom property values:
.el {
transform: translate(100px) scale(1.5) skew(5deg);
}Now imagine you don’t always want all the transform values to be applied, so some are optional. You might think of CSS optional custom property values:
.el {
/* |-- default ---| |-- optional --| */
transform: translate(100px) var(--transform);
}But surprisingly using optional custom property values like this does not work as intended. If the --transform variable is not defined the whole property will not be applied. I’ve got a little “trick” to fix this and it looks like this:
.el {
transform: translate(100px) var(--transform, );
}Notice the difference? There is a fallback defined in there that is set to an empty value: (, )
That’s the trick, and it’s very useful! Here’s what the specification has to say:
In an exception to the usual comma elision rules, which require commas to be omitted when they’re not separating values, a bare comma, with nothing following it, must be treated as valid in
var(), indicating an empty fallback value.
This is somewhat spiritually related to the The CSS Custom Property Toggle Trick that takes advantage of a custom property having the value of an empty space.
Demo
Like I said, this is useful and works for any multi-value CSS property. The following demo shows it using text-shadow, background, and filter in addition to the transform example we just discussed.
See the Pen CSS var – Fallback To Nothing by Yair Even Or (@vsync) on CodePen.
Some properties that accept multiple values, like text-shadow, require special treatment because they only work with a comma delimiter. In those cases, when the CSS custom property is defined, you (as the code author) know it is only to be used in a situation where a value is already defined where the custom property is used. Then a comma should be inserted directly in the custom property before the first value, like this:
--text-shadow: ,0 0 5px black;This, of course, inhibits the ability to use this variable in places where it’s the only value of some property. That can be solved, though, by creating “layers” of variables for abstraction purposes, i.e. the custom property is pointing to lower level custom properties.
Beware of Sass compiler
While exploring this trick, uncovered a bug in the Sass compiler that strips away the empty value (,) fallback, which goes against the spec. I’ve reported the bug and hope it will be fixed up soon.
As a temporary workaround, a fallback that causes no rendering can be used, such as:
transform: translate(100px) var(--transform, scale(1));Multi-Value CSS Properties With Optional Custom Property Values originally published on CSS-Tricks. You should get the newsletter and become a supporter.
Should CSS Override Default Browser Styles?
CSS overrides can change the default look of almost anything:
- You can use CSS to override what a checkbox or radio button looks like, but if you don’t, the checkbox will look like a default checkbox on your operating system and some would say that’s best for accessibility and usability.
- You can use CSS to override what a select menu looks like, but if you don’t, the select will look like a default select menu on your operating system and some would say that’s best for accessibility and usability.
- You can override what anchor links look like, but some would say they should be blue with underlines because that is the default and it’s best for accessibility and usability.
- You can override what scrollbars look like, but if you don’t, the scrollbars will look (and behave) the way default scrollbars do on your operating system, and some would say that’s best for accessibility and usability.
It just goes on and on…
- You can customize what a button looks like, but…
- You can customize what the cursor looks like, or particular elements on your site, but…
- You can change the text highlighting color, you can change the accent color, heck, soon you’ll be able to customize what spelling and grammer mistakes look like in editable text areas, but…
In my experience, everyone has a different line. Nearly everybody styles their buttons. Nearly everybody styles their links, but some might only customize the hue of blue and leave the underline, drawing the line at more elaborate changes. It’s fairly popular to style form elements like checkboxes, radio buttons, and selects, but some people draw the line before that.
Some people draw a line saying you should never change a default cursor, some push that line back to make the cursor into a pointer for created interactive elements, some push that line so far they are OK with custom images as cursors. Some people draw the line with scrollbars saying they should never be customized, while some people implement elaborate designs.
CSS is a language for changing the design of websites. Every ruleset you write likely changes the defaults of something. The lines are relatively fuzzy, but I’d say there is nothing in CSS that should be outright banned from use — it’s more about the styling choices you make. So when you do choose to style something, it remains usable and accessible. Heck, background-color can be terribly abused making for inaccessible and unusable areas of a site, but nobody raises pitchforks over that.
Should CSS Override Default Browser Styles? originally published on CSS-Tricks
Defensive CSS
Ahmad Shadeed nails it again with “Defensive CSS.” The idea is that you should write CSS to be ready for issues caused by dynamic content.
More items than you thought would be there? No problem, the area can expand or scroll. Title too long? No problem, it either wraps or truncates, and won’t bump into anything weird because margins or gaps are set up. Image come over in an unexpected size? No worries, the layout is designed to make sure the dedicated area is filled with image and will handle the sizing/cropping accordingly.
There is no such thing as being a good CSS developer and not coding defensively. This is what being a CSS developer is, especially when you factor in progressive enhancement concepts and cross-browser/device unknowns.
To Shared Link — Permalink on CSS-Tricks
Defensive CSS originally published on CSS-Tricks
Remember You Are Not the User
One thing people can do to make their websites better is to remember that you are not representative of all your users. Our life experiences and how we interact with the web are not indicative of how everyone interacts with the web.
We must care about accessibility.
Some users rely on assistive technology to navigate web pages.
We must care about multi-language support.
Layouts that make sense to me, as a native English speaker (a left-to-right language) don’t necessarily make sense in Arabic (a right-to-left language) and can’t simply be swapped from a content perspective.
We must care about common/familiar UX paradigms.
What may be obvious to you may not be obvious to other users.
Take the time to research your key user markets and understand how these users expect your website or product to function. Don’t forget accessibility. Don’t forget internationalization. And don’t forget that you are not the representation of all users.
What do you get for using a search input type?
Like this: <input type="search">
- You get an extra-round-y appearance in Safari, which at one time matched the macOS look for search inputs, but not really anymore. I don’t hate the look, except…
- Safari totally ignores the
font-sizeyou set on it, so careful about that. Unless you smash off the round-y look with-webkit-appearance: none—then you can, so probably 92% of all websites do this. - You get a little × icon inside the input (when it has a value) that clears it out. This is probably the best reason to use it, and mercifiully you get to keep it even after resetting the
appearance. - You get the satisfaction of knowing that you’re using the semantically correct input type for the job, assuming you are building a thing that actually searches something.
- You get past search terms with autocomplete. Browsers store those past search terms and offer a menu for autocompleting them. I’m trying to make this a list of things that are unique to search inputs, and I can prove this happens on non-search inputs. But hey, it does make the most sense on search inputs.
- You get the pleasure of adding a role to the parent form (i.e.
<form role="search">) because that helps assistive technology announce it as a search form. - You get to remember to add a proper
<label>to the input. Just using a magnifying glass icon or just aplaceholderalone won’t cut it, even though that’s what a lot of designs call for visually. - You get a super weird
incrementalattribute that sends a debouncedsearchevent to the DOM element itself. I guess that is useful for live search UX. But it’s non-standard and not in Firefox so probably don’t count on it (via Christian Shaefer). - You get to live another day as a front-end developer.
The post What do you get for using a search input type? appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
Other Looks at the Conditional Border Radius Trick
Remember when Ahmad Shadeed wrote about that border-radius “toggle” he found in Facebook’s CSS? It was interesting! I covered it. A few weeks after that surge of linkage, a couple of articles came out digging into it a little deeper.
In “Evaluating Clever CSS Solutions,” Michelle Barker wonders how clever is too clever?
While undoubtedly clever, and super interesting to read about, I side with Robin Rendle in the CSS-Tricks newsletter when he says:
I can’t help but feel that it’s a little too smart.I have to agree here. Tricks like this have their place, and Facebook (which can clearly afford to hire the best of the best CSS developers) might be one of them. But speaking personally, when forced to pick between a trick like this and an ever-so-slightly less optimal but far more readable solution (say, a media query), in 99% of cases I’d plump for the latter.
Michelle is aware that a media query isn’t the same solution here. A non-clever solution would be a container query. I agree as well. I almost never opt for tricky solutions in production, as even if they seem to work, I worry about the long term maintenance and sometimes even the fragility of the solution.
Stefan Judis looked at how we might pull of the same “conditional border-radius” idea only using the upcoming container queries syntax.
/* If the container's width is equal to or greater than
the viewport width, remove the border-radius */
@container (width >= 100vw) {
.conditional-border-radius {
border-radius: 0;
}
}That’s pretty darn clear to me. Stefan also mentions that if we could use the theoretically upcoming @when feature, it could be even clearer:
@when container(width >= 100vw) {
.conditional-border-radius {
border-radius: 0;
}
}
@else {
.conditional-border-radius {
border-radius: 1em;
}
}That is a big maybe, as there is no evidence these brand new specs will overlap like this. I hope they do though. CSS has gotten much more logical and readable over the years and this would keep that train moving.
Oh, and I mentioned this in the last article…
The
9999multiplication means that you’ll never get low-positive numbers. It’s a toggle. You’ll either get8pxor0pxand nothing in between. Try removing that part, resizing the screen, and seeing it sorta morph as the viewport becomes close to the component size
But I regretted not putting a video in there to make the concept clearer, so I’ll rectify that here.
The post Other Looks at the Conditional Border Radius Trick appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
Container Units Should Be Pretty Handy
Container queries are going to solve this long-standing issue in web design where we want to make design choices based on the size of an element (the container) rather than the size of the entire page. So, if a container is 600px wide, perhaps it has a row-like design, but any narrower than that it has a column-like design, and we’ll have that kind of control. That’s much different than transitioning between layouts based on screen size.
We can already size some things based on the size of an element, thanks to the % unit. For example, all these containers are 50% as wide as their parent container.
The % here is 1-to-1 with the property in use, so width is a % of width. Likewise, I could use % for font-size, but it will be a % of the parent container’s font-size. There is nothing that lets me cross properties and set the font-size as a % of a container’s width.
That is, unless we get container units! Here’s the table of units per the draft spec:
| unit | relative to |
|---|---|
qw | 1% of a query container’s width |
qh | 1% of a query container’s height |
qi | 1% of a query container’s inline size |
qb | 1% of a query container’s block size |
qmin | The smaller value of qi or qb |
qmax | The larger value of qi or qb |
With these, I could easily set the font-size to a percentage of the parent container’s width. Or line-height! Or gap! Or margin! Or whatever!
Miriam notes that we can actually play with these units right now in Chrome Canary, as long as the container queries flag is on.
I had a quick play too. I’ll just put a video here as that’ll be easier to see in these super early days.
And some great exploratory work from Scott here as well:
Ahmad Shadeed is also all over this!
Query units can save us effort and time when dealing with things like
Ahmad Shadeed, “CSS Container Query Units”font-size,padding, andmarginwithin a component. Instead of manually increasing the font size, we can use query units instead.
Maybe container queries and container units will drop for real at the same time. 🤷
The post Container Units Should Be Pretty Handy appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
Don’t attach tooltips to document.body
Here’s Atif Afzal on using a <div> that is permanently on the page where tooltips are added/removed and how they perform vastly better than plopping those same tooltips right into the <body>. It’s not really discussed, but the reason you put them that high-up in the DOM is so you can absolutely position them exactly where you need to on the page without having to deal with hidden overflow or relative parents and the like.
To my amazement, just having a separate container without even adding the [CSS]
containproperty fixed the performance. The main problem now, was to explain it. First I thought this might be some internal browser heuristic optimizing theRecalculate Style, but there is no black magic and I discovered the reason.
The trick is to avoid forced recalculations of style:
[…] The tooltip container is not visible in the page, so modifying it doesn’t invalidate the complete page render tree. If the tooltip container would have been visible in the page, then the complete render tree would be invalidated but in this case only an independent subtree was invalidated.
Recalculating Stylefor a small subtree of 3 doesn’t take a lot of time and hence is faster.
Looks like popper.js was used here, so you have to be smart about it. We use toast messages on CodePen, and it’s the only third-party component we use at the moment: react-hot-toast. I checked it, and not only do we tuck the messages in a <div> of our own, but the library itself does that, so I think we’re in the clear.
The post Don’t attach tooltips to document.body appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.
“We had 90% unused CSS because everybody was afraid to touch the old stuff”
Over at the JS Party podcast:
[Kend C. Dodds]: […] ask anybody who’s done regular, old CSS and they’ll tell you that “I don’t know if it’s okay for me to change this, so I’m gonna duplicate it.” And now we’ve got – at PayPal (this is not made up) we had 90% unused CSS on the project I was using, because everybody was afraid to touch the old stuff. So we just duplicated something new and called it something else. And you might just say that we’re bad at CSS, but maybe CSS was bad at us, I don’t know… [laughter]
[Emma Bostain]: Well, that’s why styled-components and CSS-in-JS was so pivotal; it was like “Oh, hey, we can actually encapsulate all of this logic inside the component that it’s touching and don’t have to worry about bleeding code anymore.” It’s so much easier to delete things, and add things, and all of those things.
[Kend C. Dodds]: Yeah, you’re precisely right. That was the problem that those things were made to solve.
Audio clip:
I’ve heard this exact story before several times, usually from large companies. Lots of developers, typical developer turnover… nobody knows what CSS is actually used and what isn’t because that is a very hard problem.
That’s one of the reasons I sometimes like component-based-styling solutions (CSS-in-JS, if you’re nasty). Not because I love complex tooling. Not because I like JavaScript syntax better than CSS. Because of the co-location of styles and componentry. Because nobody is afraid of the styles anymore — they are tightly coupled to what they are styling. It’s not needed on every project, but if you’re building with components anyway (an awfully nice way to architect front-ends that doesn’t require JavaScript), you might as well style this way.
For this reason, I’m excited that “scoped styles” are making a bit of a comeback in standards discussions.
I remember an ancient idea (that maybe even shipped in browsers for a minute?) where you’d just chuck a <style scoped> block right in the HTML and whatever the parent was, the styles were scoped to that parent. That was so cool, I wish we could have that again.
But it seems like the newer stuff (here’s Miriam’s original proposal) has some more clever stuff that that basic concept doesn’t cover — like being able to set a lower-boundary in addition to an upper-boundary, making it possible to scope “donut-shaped” styles in the DOM (a Nicole Sullivan term). Whatever happens, shadow DOM-free scoped styles with zero tooling is huge.
The post “We had 90% unused CSS because everybody was afraid to touch the old stuff” appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.