Search results

0

How does the semantic html community feel about using the <details> element to “expand” into a form submission confirmation, when submitting “dangerous” operations, instead of a <dialog>? Notably, the thing I’m working on is currently fully JS-optional so far, and I would like to keep it that way.

EDIT: Oh it looks like <button> has command and commandfor, which can open a <dialog> now.

EDIT2: oops, but it's not baseline yet, and won't be for a while. It just released in preview for Safari and Firefox. ~sigh~

0

Okay, it seems classic NPM tokens already stopped working and so it's IMPOSSIBLE for me to release any new versions of my 210 projects/packages until they have implemented a solution which:

1) Doesn't require to manually setup a Trusted Publishing config for *every single package* or
2) They're lifting the arbitrary 50 packages per token limit for their new "granular" tokens (in addition to them already being severely time limited)

The current combined effect of these two restrictions means I cannot do automated multi-package releases from my monorepo, using a tool which handles changelog generation, version bumps and topological sorting of releases.

It's bloody infuriating! NPM has ignored looming security issues for a decade. Now they're rushing some halfbaked no-solution with several glaring issues, all within a few weeks notice and then not even sticking to their timeline. Classic tokens were supposed to stop working in November only...

0

as posts aren't migrated:

Software dev from , . Worked on full stack and / projects for 10+ years, on my free time I use & (hope in the future at work!).

Main hobby project is <codestats.net/>. I also enjoy , , and video games.

Blog: blog.nytsoi.net/ (engine: git.ahlcode.fi/nicd/scriptorium)

Some packages:
hex.pm/users/nicd

Working on a multipart/form-data package.

0

What is it with languages and math? Does a string-injecting system _really_ need full-blown mathematical operator set? I’m looking at multiple templating langs, and they all seem to be far from an optimal state where the emergent behavior appears:

- : No math, relies on and benevolence of /

- Liquor (by @whitequark✧✦Catherine✦✧): Includes math and lots of operators in general, too powerful to be interesting

- : require

- : No arguments to partials, thus no abstraction and data passing

- Server Side Includes: Have everything I need, but are -specific in many ways

Uuuuuuugh. I would’ve gone with either of these for my website and day-to-day programming, but I don’t want to commit to either an explicitly Turing-complete system or non-portable JS-heavy one.

I guess I’m still staying with (1) until the state of templating improves. Or until I write a version for any of these, likely SSI.

0

So am I understanding this correctly that the upcoming NPM authentication and token changes mean our only publishing workflow options henceforth are either switching to OICD Trusted Publishing[1] via GitHub Actions or using granular access tokens. The problem with the former is that I wanted to migrate my projects to Codeberg soon (which isn't supported). The problem with the latter is that granular tokens are unsuitable for publishing packages from a large monorepo, since these tokens are limited to 50 packages only (in addition to time limits)[2].

My thi.ng/umbrella repo contains 210 packages, so in order to publish them (sometimes all of them will need to be updated) I'd have to first generate multiple tokens and then also keep track how many times each token has been used. This adds a lot of extra work and complexity to my monorepo publishing tool (thi.ng/monopub). I understand the need for improved NPM security, but as so often, these changes are just poorly thought through (IMO) and continuously add new workloads and complexity on maintainers...

[1] docs.npmjs.com/trusted-publish
[2] docs.npmjs.com/about-access-to

So to make it all even "better": To use Trusted Publishing, one also has to manually setup a GitHub Actions integration on npmjs.org for every single package individually! This is just mind boggling and infeasible and means I'd have to manually fill in a form 200+ times (for that many packages) before I could even properly test this new publishing workflow.

Other people who're maintaining thousands of packages (e.g. DefinitilyTyped, Fontsource) have chimed in here too: github.com/orgs/community/disc

Let's hope this will be addressed!

0

So am I understanding this correctly that the upcoming NPM authentication and token changes mean our only publishing workflow options henceforth are either switching to OICD Trusted Publishing[1] via GitHub Actions or using granular access tokens. The problem with the former is that I wanted to migrate my projects to Codeberg soon (which isn't supported). The problem with the latter is that granular tokens are unsuitable for publishing packages from a large monorepo, since these tokens are limited to 50 packages only (in addition to time limits)[2].

My thi.ng/umbrella repo contains 210 packages, so in order to publish them (sometimes all of them will need to be updated) I'd have to first generate multiple tokens and then also keep track how many times each token has been used. This adds a lot of extra work and complexity to my monorepo publishing tool (thi.ng/monopub). I understand the need for improved NPM security, but as so often, these changes are just poorly thought through (IMO) and continuously add new workloads and complexity on maintainers...

[1] docs.npmjs.com/trusted-publish
[2] docs.npmjs.com/about-access-to

0
0
0

Hey , I want to connect to more people here.

I am a engineer who has experience with , , , , some , C & C++. I also love research and have a paper published in . Currently, I am using for improving the safety on the roads. I've worked as full-stack engineer in the past.

I find this platform and people here awesome. I've had amazing interactions and want to grow them.

0
0
0
0

For those who wanted to see the code behind my CSS-only magical sticky auto-expanding sidebar nav in action, I've put together a little CodePen for you! I've narrowed down the relevant code to just what's needed to get this to work, with some very minimal JavaScript to improve the accessibility of it! I've even left you a little challenge in there for you, let me see how you accomplish it!

codepen.io/Snugug/pen/VYezVKr
mas.to/@snugug/115259058092836

0

I feel that " is purely terrible and should be obliterated from the planet because modern is enough" crowd often miss the role it plays in dictating the weight of importance for new features that flow into native and .

Its right there in chapter four of "HTML5 for Web Designers" (Jeremy Keith)

Developers hack together a solution with and eventually browser vendors go "oh snap, yeah, maybe we *could* just have CSS for popular thing" and out it comes.

You can't have amazing CSS without browser vendors understanding what is important for developers. Its a lovely, beautiful feedback loop.

Screen cap of HTML5 for web designers - with the text highlighted: This is a recurring trend. If a pattern is popular enough, it will almost certainly evolve from requiring a scripted solution to something more declarative. That’s why CSS3 introduces even more animation capabilities that previously required JavaScript.
0

I remain unsatisfied with most Django setups, including my own, that try to incorporate a reasonable JavaScript build pipeline. The JS build is inevitably a separate build step and a local dev server for hot reloading. Sure, deployment is fairly straightforward: compile JS, then collectstatic. It's the development story that suffers for its complexity imo.

I paired Django with AlpineJS for webauthn.io and in general it's fine to make updates to. But I just crested 575 lines of AlpineJS in a single HTML component and it's left me with a sense of dread about ongoing maintainability as I gradually add "just one more feature".

I miss my components-based, TypeScript-checked dev flow when I work with Django. Maybe it's time to look to vanilla Web Components to break some of this up, but then that won't get me the static type checking of TypeScript.

Anyone got any stories of how they wire up at least a TypeScript JS codebase for light front end interactivity, while still leveraging Django views for SSR?

0

»HTML’s Best Kept Secret — The <output> Tag:
Every developer knows <input>. It’s the workhorse of the web. But <output>? Most have never touched it. Some don’t even know it exists. […]«
— by @denodell

You never stop learning and you can't know everything about as a WebDev. Nice to see how you can use the HTML interface actiev.

🧑‍💻 denodell.com/blog/html-best-ke

0
0
0
0
0
0

Exciting news for developers! We've just landed a major milestone for Fedify 2.0—the now runs natively on .js and , not just (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).

This change means a more natural development experience regardless of your runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!

2
0
0
0
0