DEV Community: Yair Even Or

Faded Box Backdrop Blur

Yair Even Or — Wed, 04 Oct 2023 14:29:44 +0000

Imagine box-shadow but for a blur effect, where the backdrop of an element is blurred around the that element, gradually going from blurry to crisp.

Such an effect can increase the focus on the element which drops the blur, by creating more contrast between it and its backdrop, especially if they happen to be in similar color shades.

There is no native way of doing with the CSS beside combining a few tricks together to simulate such an effect

Steps to create the effect

Create an HTML element within the the one which harbors the effect. Best to use a pseudo-element for such a thing, so not to involve any markup changes.
Position the pseudo-element so it occupies the whole area of its parent plus some extra, so the blur “spills” outside the area of the container and will be visible, since the container should not be blurred
Give that element backdrop-filter: blur(...)
Apply -webkit-mask & mask on the element, with a specific value with multiple gradients
Apply -webkit-mask-composite: source-in (for non-standard Chrome support) and mask-composite: intersect (for non-chromium browsers) to the masked pseudo-element, to marge the pixels of the gradients in such a way that they don’t add to each-other but simply merge to their average, so only areas where both gradients apply to are visible, and this is crucial having the mask fade-out blur backdrop-filter in a somewhat realistic way.

The Mask’s Gradients:

Two gradients, one vertical and the other horizontal, both go from transparent, to a color, and back to transparent. The colored region should be prominent - occupy most of the area.

linear-gradient(to top, transparent 0%, black 25% 75%, transparent 100%),
linear-gradient(to left, transparent 0%, black 18% 82%, transparent 100%)

`-webkit-mask-composite: source-in` / `intersect` Applied:

As mentioned in step 5:

Combining Everything:

Note that in the above Codepen example I am using a mask with these percentage values:

linear-gradient(to top, transparent 0%, red 25% 75%, transparent 100%),
linear-gradient(to left, transparent 0%, red 18% 82%, transparent 100%);

Wherever the fill color is irrelevant (like in this case), I tend to use "red" as it's the shortest color name. Another thing to note are the percentages 25% 75% & 18% 82%. These roughly correspond the aspect ratio of the popup box, which gives a more “balanced” look to the blur effect between the horizontal sides and vertical sides.

CSS Debugging Disappearing Elements

Yair Even Or — Sat, 30 Jul 2022 21:38:00 +0000

I'm going to share with you a trick so cool you'll be shocked ⚡️

But first, here's a little intro for those who have no idea what the subject of this post is for:

Some elements appear on the screen only when the user interacts with another element.

For example, a suggestions box appears when the user types text, or a dropdown is rendered when a menu item is hovered.

(Like the dropdown items of this MUI component)

Sometimes those dynamically appearing elements don't exist in the DOM until they are needed - for example, appearing when another element is being interacted with.

How can they be inspected? Since clicking the inspect button will cause those dynamically-added elements to disappear.

1. Timeout trick

Most developers are familiar with this trick, but for those who aren't - to "freeze" the DOM, execute a debugger command (within devtools console) inside a setTimeout with enough duration which lets you run around, do whatever you need to do, in order to show the evasive thing you wish to inspect:

setTimeout(() => { debugger; }, 3000)

While this is handy, it can be annoying to constantly run this command when you are constantly debugging some random CSS weirdness.

2. F8 in Devtools `Sources` panel

Hitting F8 while the Sources panel is open will freeze the DOM also and go into debugger mode.

3. Hotkeys automated debugger:

The above trick can be automated using a dedicated keyboard shortcuts (Chrome browser).

Install the shortkeys extension
Click on the extension icon and chose "options":
Configure it as follows:
Click "Save shortcuts" button (bottom-right)

Now, go to any page, make sure devtools is opened, and hit CTRL+SPACEBAR keys, while your inspection target element is visible.

4. Emulate a focused page with devtools:

Open Devtools
Hit Command + shift + P (OSX) or CTRL + shift + P (Windows)
Type focused
Select Emulate a focused page

Now interacting with devtools will not lose focus from the element which was focused.

Optional CSS transform with CSS variables

Yair Even Or — Mon, 10 Jan 2022 17:58:56 +0000

Assuming you have a component which has a default transform property value(s) and can also have additional ones, which are optional, then logically it should be written as so:

.component {
             |-- default ---| |-- optional --|
  transform: translate(100px) var(--transform);
}

But...It does not work as intended if the --transform variable is not defined.

I am unsure why, but it can be easily fixed using this trick:

.component {
  transform: translate(100px) var(--transform, );
}

Did you notice? There is a fallback defined to nothing: (, )

W3 Spec:

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.

Demo:

https://jsbin.com/vejusaj/edit?html,css,output

🚀 Automate NPM package publish & GIT versioning

Yair Even Or — Wed, 20 Jan 2021 18:29:22 +0000

Save time, improve your build process by streamlining releases.

Intro

Assuming a scenario for a typical package (which yourself is the sole author of), such as some sort of web component, CSS library, etc. which is intended to be used in a client and has some sort of a build process.

As mentioned above, this article is not meant for multi-developers codebase which are actively working on branches, because we don't want to tag anything when pushing, and certainly not publishing, since doing that is reserved for a dedicated pipeline (devops).

For the sake of example, this article presents a portion of code used in one of my packages - knobs, which is a pretty small project which uses Rollup to bundle the JS & SCSS.

📜 NPM scripts - basics

This topic has been addressed a lot and this article assumes basic knowledge of working with NPM custom scripts and with lifecycle ones, such as start, test, version, prepublishOnly and so on.

😥 What can go wrong without automatic release flow:

Since the project requires a build process, without automating the release flow as much as possible, unwanted outcome might occur:

Accidentally deleted imported distribution file
Forgetting to build before releasing
Forgetting to tag the version
Using wrong git tag (mismatch with version in package.json
Not sure of the order of which things should be done before publish: should tag before committing or after?
Forgetting to push the tags

🦺 Wanted: Something which guarantees nothing of above happens.

`package.json` before the change:

{
  "scripts": {
    "start": "rollup -c rollup.config.dev.js -w",
    "build:prod": "npm run clean && npm run bundle:prod",
    "bundle:prod": "rollup -c rollup.config.prod.js",
    "clean": "rm -rf knobs.min.js",
    "test": "echo \"No test specified\"",
  }
}

Pretty standard bunch of scripts, nothing interesting to talk about.

In order to publish the package, a non-automated release flow example would require to first run npm build:prod, which will run the cleanup script and then the bundling script, which runs without the watch command, because watching is unnecessary just before deploying since there is no code change. Then commit, and add a git tag and push with the tag, everything, and then publish the code. (or publish and then push).

Lets improve by adding a few scripts:

There are many ways to automate the above workflow (or half-automate), but I would like to talk about a specific tool which I find very helpful:

https://github.com/sindresorhus/np

np is best installed globally: npm i -g np
headr is a great package for automating header comment in the dist files, which includes information from the package.json file itself, such as version, author name, repository url, etc. install it also if you wish.
pkg-ok is another script which ensures no (important) file is missing, I advise using it.

`package.json` after the change 🤟:

{
  "scripts": {
    "start": "rollup -c rollup.config.dev.js -w",
    "build:prod": "npm run clean && npm run bundle:prod",
    "bundle:prod": "rollup -c rollup.config.prod.js",
    "clean": "rm -rf knobs.min.js",
    "test": "echo \"No test specified\"",

    "header": "headr knobs.min.js -o=knobs.min.js --version --homepage",
    "version": "npm run build:prod && npm run header && git add .",
    "prepublishOnly": "pkg-ok"
  }
}

And the command used to publish & push is:

np --yolo

🧐 Note that I am using the --yolo flag because I want to skip tests (I don't have tests) and not clean the node_modules and reinstall everything which can take long minutes.

np package also allows writing a pre-defined configuration within package.json itself, using the np property.

version (npm scripts property) is a lifecycle script hook which runs exactly at the appropriate time to build the code, output the bundle and add a header comment (to any file) with the just-bumped version number.

prepublishOnly (npm scripts property) lifecycle hook is a good place to check no file is missing before proceeding, using pkg-ok.

🏃‍♂️ Running the above command (np --yolo) will present a GUI:
(screenshot from np repo)

If all goes well, the package will be published and a new browser tab/window will open the project's GIT repository URL, for you to approve & publish a new tagged release in the repo.