Any article about rebase is incomplete without the mention of `git commit --fixup fb2f677`. When committing you usually already know which commit you’re “fixing” so you specify that.
Then you run `git rebase -i --autosquash origin/main` instead and the commits are already in the right order.
"The concrete description of what is going on here is spread atom-thin across several websites, all of which expect you to know the terminology. Each of these websites provides you with a tiny piece of the puzzle and you are expected to combine it together on your own."
There's a shift though, just the last couple of years. Today all browsers support native modals with the dialog element, accordions with details/summary, everything but Firefox supports popovers (dropdowns, tooltips, menus, etc) in plain HTML.
I'd honestly love to be a beginner again learning modern HTML and CSS today, it's not bad at all.
Looks a bit like tire inserts - basically foam rings you put inside the tire, common on mountain bikes. I just installed that on my bike, which not only protects my rims but also lets me ride home from the trail with a flat tire. https://www.bikeradar.com/advice/buyers-guides/best-tubeless...
I hear you. I think Shadow DOM is very useful for a handful of roots on your page, encapsulating third-party widgets or DOM-heavy components like a nested navigation.
Custom Elements on the other hand are useful for attaching behavior to HTML, sort of like jQuery plugins.
Not at all sold on the frameworks promoting using Shadow DOM for every button or whatnot.
For example, encapsulating a third party widget, cookie banner or your main navigation. That way any CSS added inside the shadow DOM only affects those elements - you can safely write selectors like `h1` or `button` and they’ll only match what’s inside that same shadow root boundary.
Almost all examples of Shadow DOM uses Custom Elements, but that’s not required. I think this conflation harms adoption of Shadow DOM.
As an example of what you can use the Shadow DOM for - it works fine as the node to render a React app/component in. So if you need a couple of React components on a page to not affect each others style, you can do React.createRoot(myShadowRoot) and they’re fully encapsulated.
> Tailwind and CSS in JS libraries that pre-compile to Atomic CSS solve the problems of bloated CSS files full of duplicated rules.
> With Atomic CSS, the growth of CSS is tied to the number of unique styles used, not the amount of features developers are shipping.
> For example, it’s common to reuse certain properties like flex everywhere. Rather than have these duplicated in stylesheets under different class names, we only pay that cost once. This is true for each property/value combination.
This is true in theory and when you stick to the very basic stateless utility classes. Check the CSS of any larger site using Tailwind and search for a CSS rule, you will see things like
and that's not counting media queries, dark mode, etc. In practice, the global CSS file that you load for every single page does grow for every feature you ship, since you use more of Tailwind.
Every user gets their own preferred formatting, and linters and tools could operate on already-parsed trees