CSS built-in nesting is awkward, static variables can be useful actually, and what's the point of dropping a consistent API with good DX if we're still transforming our stylesheets anyways?
Chaining together interoperable PostCSS modules to accomplish half of what Sass can do is nearly impossible.
@baumannzone This has to do with how floating point numbers are stored (essentially, they’re fractions, not decimals). This occurs in most programming languages, not just JS. Look up “floating point rounding error”
After reading this, checked my existing styling as processed through autoprefixer, found the vendor prefixes that had been added, and manually added them to my styling — so it now doesn’t require any additional tools for cross-browser compatibility.
@simevidas it's a demo to illustrate the input, you can easily add any text inside the label as a label. It's irrelevant to the demo so I didn't do it.
@css Not having a label is not the problem. The problem is using a <label> element without including a label. That’s confusing. The purpose of the <label> element is to include a label. There is no other reason why this element exists, so if you don’t have a label in the demo, don’t use <label>. Just remove it. Use a <span> if you need a wrapper element.
Latest version of #HTML standard includes a warning that advises against using the #XML syntax (formerly known as #XHTML), stating that it's "essentially unmaintained"🧐 :
Andreas Rossberg kicking off Wasm Research Day right. We've basically had no spec bugs because Wasm from the very get-go was designed to be formally verified e2e. #Wasm#WasmResearchDay
Is there a clickable, 2-level, responsive #hamburger#menu with minimal javascript, simple design, header and #navigation only, separate, free to use, #webdev up to date, modern browser.
Weekend discovery. An intermediate step in the RAG process is document chunking. Determining the appropriate chunk size can become a trial & error game. James Briggs does a great job of explaining how to use Semantic Chunking to get better results.
Probably my most prejudiced #CSS hack. Judge if you want, but this one line saves me from an insane amount of alignment issues and overly complicated calc()s.
@bingocaller I've been using it since essentially forever, too.
This is interesting because I've never seen anyone mention it in conversation around CSS… at the very least I'm glad I'm not the only one thinking that this makes things behave way more sensibly.
I'm only just finding my way in the land of #htmx, but it feels like "trigger a request from any #HTML element" is a trap. I want progressive enhancement, which still requires a functional non-Javascript page before adding the nice things htmx offers. I didn't realise how rusty I am with regard to designing a presentation layer for all this in the backend.
@_chrismay
Yeah I've been looking at that. Reading the HX-Request header to determine whether to give a full-page response or just a snippet is what I do, and it quickly made it clear that navigating my site structure needs more up-front attention. Which is pretty much in line with #HATEOAS I think.
I don't understand why CSS is so verbose sometimes. Why couldn't I just do: color: --brand-red;
???
Why do I need to surround every use of it with var(...)? Wasn't the double-dash prefix was specifically chosen to not clash with any existing or future properties?
It's always so frustrating writing CSS. Especially compared to all the structure, abstractions, and terseness that programming languages offer.
@css@peterreeves Exactly. A key consideration for every new CSS syntax is the performance involved in parsing and tokenizing the language.
It’s not simply about “is ‘left: 3 * 10px’ unambiguous?” It’s about “Can the parser know what token the ‘3’ is before it reads the ‘*’ or the ‘10px’. And without calc(), no, it cannot.
An ambiguous syntax leads to lookbacks, which absolutely destroys parser performance
@css@peterreeves I guarantee the w3c tried to find a way to do this without var(). If you really want to dive through old GitHub issues, it’s probably there (though this one might date back to the older mailing list).
I recall seeing discussion about using $ like Sass, but then deciding that would conflict with existing Sass code, so eventually they settled on the current approach.
I really like that it can be as simple or as complex as you want it to be.
I'm not quite sold on it for hosting blogs (yet), but I've migrated a few of my smaller projects for which I've used a simple node app (mainly to take advantage of templating).
Huge improvement in memory consumption! For example, https://simplepagebuilder.app went from 67.89MB down to just 6.07MB.
I was kinda hoping calc-size() could resolve intrinsic sizes inside math functions but it doesn't seem to (at least in Chrome Canary). Not sure if that's a bug or if Friday afternoon isn't the best time to try to understand draft #CSS specs 🤯
The way it works: in the first argument is the intrinsic value you want to use, and in the second is the calculation that you intend to do with it, where a special size keyword becomes available as the “variable”.
