Think of it as a rounded square with a unique, pleasant shape.
I don't find them pleasant. I find them irritating.
Rounded square makes use of the space it reserves/square-fills. Squircles seem wasteful and confusing. They do not represent any common physical shapes, and waste/discard space they could use. They look like an old CRT.
R1dacted: Investigating Local Censorship in DeepSeek’s R1 Language Model
Quoting from the abstract:
While existing LLMs often implement safeguards to avoid generating harmful or offensive outputs, R1 represents a notable shift—exhibiting censorship-like behavior on politically charged queries. […]
Our findings reveal possible additional censorship integration
likely shaped by design choices during training or alignment,
raising concerns about transparency, bias, and governance in
language model deployment.
When PRs begin with a headline and checklist the GitHub hover-preview becomes useless. When the PR description begins with the summation of the change, it is very useful.
Most of the time I see headlines and check lists in tickets I create or contributions I create PRs for, I feel stifled and like I have to produce something very inefficient or convoluted.
The worst I have seen is when, at work, I had to create bug tickets for a new system in a service desk to a third party, and they had a very excessive, guided, formalized submission form [for dumb users]. More than once, I wrote the exact same thing three times into three separate text boxes that required input. (Something like "describe what is wrong", "describe what happens", "describe how to reproduce".) Something that I could have described well, concise, fully and correctly in one or two sentences or paragraphs became an excessively spread, formalized mess. I'm certainly not your average end user, but man that annoyed me. And the response of "we found this necessary" was certainly not for my kind of users, maybe not even experience with IT personnel.
At work, I'm glad I have a small and close enough team where I can guide colleagues and new team members into good or at least decent practice.
Checklists can be a good thing, if processes can be formalized, can serve as guidance for the developer, and proof of consideration for the reviewer. At the same time, they can feel inappropriate and like noise in other cases.
I've been using horizontal line separators to separate description from test description and aside/scoping/wider context and considerations - maybe I will start adding headlines on those to be more explicit.
I'm a bit confused, because MDN ::after says in the accessibility section:
Using an ::after pseudo-element to add content is discouraged, as it is not reliably accessible to screen readers.
which contradicts the article saying ::after content gets included as per spec. They conclude though with
While it’s good and certainly useful that we can now provide alt text for CSS generated content, I do not recommend using CSS to insert meaningful content into the page.
Not only will some of your screen reader users miss meaningful information when the alt text is not announced by their screen reader (looking at NVDA with Chrome 👀), but there are also other reasons why inserting meaningful content in CSS is not yet recommended…
If you want a teaser what this is about, the /content syntax for screen read representation (to evade misrepresentative emoji translations, for example).
css
::after {
content: " \2197" / "Opens in a New Window" ;
}
They also talk about image alt text and ::afterurl.
I use GitLab diffs in single-file-view mode, TortoiseGit Merge when it exceeds what GitLab can reasonably display (including block indent changes I can ignore in TortoiseGit Merge or moves I can better track), and WinMerge (previously I used KDiff) for manual copy-paste text diffing (like copying blocks from the code change diff to compare similar, categorically similar code, or code moves, etc)
I don't know what you're looking for, and what your "not super simple" is, but baseline browser tech provides various controls, layout mechanisms, styling, interactivity, etc.
Do you have a concrete idea of what and where specifically you hope for gains by using frameworks? Do you plan to hold a lot of state on the client that needs state separated from the DOM and its mechanisms? Do you want a standard library of styled components instead of using the native ones or styling them yourself? Do you want more robust JavaScript? Those are all very different concerns and requirements.
I like the low complexity, low barrier, low requirements of baseline web tech. The native html form controls may arguably look "ugly", but those can be styled, individually or through a style-only CSS lib.
The most future proof web tech is not using frameworks and libraries at all.
Render native HTML controls.
I also assume it's lower barrier than any of the libs and frameworks you could use, which is always a subset of web tech with the addition of their own concepts.
These terms included affirming the statement that we 'do not, and will not during the term of this financial assistance award, operate any programs that advance or promote DEI [diversity, equity, and inclusion], or discriminatory equity ideology in violation of Federal anti-discrimination laws,'
Insane. I can't even fathom adding such a condition. And to a well established org with a positive track record.
Toxic offer. Wouldn't even be able to say that inclusivity is a good thing.
Dependency injection has significant upsides, but the indirection also has significant downsides for direct readability and traceability. Suddenly, you separated definition and call into distanced registration and use, with magic indirection that may or may not use various lifetime behaviors or proxying and wrapping or later replacement on types.
I've tried reading (and fixing) a library that made excessive use of DI, and it was very hard to follow or get into.
I created a Nushell plugin in Rust that merely converts between Nushell and BSON data formats.
It works, but I still have a fundamental lack of understanding of the magic abstract generalized data transformation framework/interface.
I wish there were fewer magic conversions and transformations, and less required knowledge of them and calling or knowing the correct ones. Magic traits leading to magic conversions for magic reasons. Or something.
I prefer round[ed].
I don't find them pleasant. I find them irritating.
Rounded square makes use of the space it reserves/square-fills. Squircles seem wasteful and confusing. They do not represent any common physical shapes, and waste/discard space they could use. They look like an old CRT.