I think you would be pleasantly surprised by the direction web dev is moving if you gave it a chance.
For example, I suspect that you think one of the ways the web has gotten shittier is because sites are too bloated and JavaScript frameworks are too heavy and slow.
One of the key takeaways is that, across almost all frameworks and stacks, web dev is moving back to doing as much work on the server-side as possible, while retaining the minimum necessary interactivity via Islands of Interactivity with much lighter JavaScript than what was pushed for the last decade.
1996 was the beginning of the chaos. We went from a document that the user's browser parsed and styled to a free-for-all of website designs glued together on construction paper. Accessibility took a step back. You now needed a graphical desktop to view the web. Page content was no longer machine readable and became less portable. Now in a world of dynamic page content generated by javascript you need a v8 browser in crawlers just to index page content.
My career has followed some of that journey, and I also have come back to using Alpine, HTMX, and a server side rendering for SPA-like apps. Some pages are just almost all HTML, and just use HTMX to switch the client content without a page load.
The article is very interesting but the fake cursors are infuriating and make it nearly impossible to focus on the content. It's a clever joke but without a way to disable it, the author is just sabotaging his own content.
How does one make this edit permanent? I've been looking to delete the sidebar on fandom, but an adblocker like uBO is not enough, since I need to edit the backgrounds margin. I don't know anything about webdev, and would be grateful for help.
Well, making such a change permanent on a foreign webpage, that's not really something you do in webdev, but I happen to know anyways.
What you want is usually referred to as a "user style" and you can achieve that with e.g. the Stylus extension.
You can create a new style and then paste this into it:
Ah, absolutely no toes stepped on. I've never used Fandom myself, this was just what I could whip up real quick.
If you happen to use Fandom more often, maybe you'd like to publish this in Stylus? Even if it's just as a personal backup.
I mainly didn't do it, because without me using Fandom, the user style could be broken by tomorrow.
P.S.: I think, the first body > .main-container {-block can be removed, as you set the same style in the nested block underneath...
Does individual users send activities directly? I thought only users of your instance and remote federated instances send traffic to your instance, so this change would only affect data coming through from the larger instances?
Also, what’s happening with the original request while they remain in queue? Say for example if large-instance.com is sending 11 updates to your instance; while your back end server is processing the first 10, what’s happening with the 11th? Does it get put on hold while your back end churn, or does it get a 200 OK response, despite the request may be failed at a later date? Neither of which seems ideal — if the instance get put in a queue waiting for a response while you churn, or worst yet, if your backend fails and your buffer is waiting X seconds to time out each request, you’re going to hurt the global federation by holding up a spot in their out going federation queue; if the instance is sent with a 200 OK and your backend eventually fails, you’d lose data as the other instance wouldn’t know they’d need to retry.
A HTTP 200 response is sent immediately. There is a small risk of data loss but only during the time when rate limiting is happening. Most instances behave well and only send activities at a sensible rate but when things go wrong we need to avoid the bad effects caused by those that are mis-configured or under attack.
It's not a perfect solution. But the alternative - fail to accept some activities, causing them to retry later and us to slowly fall more and more behind - is worse.
Thanks for the clarification! I’m inclined to agree here, small risk of data loss but failing to receive updates all together during peak burst is probably much worse.
Yes! Can't believe it's 2024 and websites are still not accessible. Even the biggest companies are the worst at this... and don't even get me started on their mobile sites 🙄
Web accessibility isn't just about compliance; it's about creating digital experiences that empower and include every user, regardless of their abilities.
I get that it's hard to come up with a good example of using <base>, but I wouldn't show a user-hostile example before ... cutting the element from Chapter 1 entirely. The only time I've ever used <base> was when I had to deploy multiple versions of a multi-page static site to a subdirectory for its staging environment, but to the public root for the production environment. Even then, the solution wasn't, "use <base>," it was, "sort shit out later with nginx."
Step 2: confuse the use case of anchors and buttons.
I understand that it's just an example but it's never just an example. Use appropriate landmarks or break your snippets down to the point where it's obvious that what you're pointing out isn't the whole thing. You don't need <body> or <ul> or <li>, just split the snippet in two, like this:
Don't do that. I mean, don't really do any of this example, but really don't do this last part. Adding class="native" is as cumbersome as adding target="_blank", while also being more brittle. [I edited out a considerable amount of swearing here.] I think this is just a symptom of a bad example gone way too far.
If the client insists on opening all external links in new tabs, get it in writing and then do this:
<base target="_blank" />
let external_links = document.querySelectorAll('a[href^="http"]');
external_links.forEach((external_link) => {
external_link.setAttribute('target', '_blank');
});
You can use querySelectorAll with a prefix attribute selector like 'a[href^="http"]' instead of a typical class selector. This lets you grab all the anchors with hrefs that start with "http" without adding extra syntax where it doesn't really belong. Once you've got your external links, iterate through that NodeList with forEach and tack on target="_blank" using setAttribute. That way, you're not re-implementing default behavior, you're only mildly annoying users with HCI devices, and if JS gets blocked all your links suddenly behave predictably.
Even this is bad! Just don't! It's so easy to not!
Other notes
You should probably start by explaining what an element is, then what an attribute is, then what a value is. Vocabulary is extremely important.
When referencing elements, include the chevrons in the inline style. <meta> vs meta. If they have to guess, they'll guess wrong. Suffix with "element" to really beat them over the head with it.
When referencing attributes, try to keep their values attached. class="foreign". If you can't, suffix it with "attribute."
When referencing values, keep those quotes! "false".
If it's a book about HTML, don't use JS. At all. Every time you reach for JS, stop. Like if you are about to write a self-invoking function to go and find invalid values of the rel attribute, for example, maybe don't.
Thank you for the great feedback! This is one of the benefits of undertaking a project such as this in the open. I hear you with the <base> element. I was in two minds whether I should even include it. I am thinking now that I should, but introduce it merely for completeness and recommend not using it. I wonder if it will ever be deprecated.
Learning HTML syntax is the simple part. The tedious part is learning which tags already exist, and which tags goes in which other tag (and which attributes they may (not) contain).
For that, always, ALWAYS go to the official HTML spec: WHATWG HTML.
HTML has not been maintained by WC3 (though they still do maintain CSS) and has been a "living standard" since HTML5 (2009-ish, IIRC).
I've read through the entire spec (using TTS, because only reading is boring) and learned a TON, because writing React straight out of the gate, without learning the HTML fundamentals first is a HUUUUGE pain.
2 years into web dev (with 20 years of other software dev experience) and I’m rolling my eyes with all this. OK, sure. And I’m exhausted in myself at reaching for frameworks (I’m working on being better) but the fetish around avoiding JavaScript is silly. CSS is amazing, learning how to use selectors better is definitely on my list, but that is not an interview question of any substance.
I agree - it's like a fun code-golf challenge in that you end up with awful, write-only code but you may well end up with a deeper understanding after solving it. It's for circumstances almost opposite to an interview.
The proposed solutions don't even work - for example the tan is only meant to display once per letter.
The actual question does at least ask when it's JS suitable and when isn't it - for example it's irritating to have to wait for a page to init just to be able to access a drop-down menu (hint: use active in CSS instead of a JS toggle).
I live in Canada and I've never seen "1.000,00". Canada (at least the anglophone part that I live in) follows the usual "1,000.00" format. Why is this library using commas as decimal separators?
This is very interesting. I agree that some of the formatting puzzled me as well. I would assume this follows some standard even when the use of said standard is uncommon. I have for example not seen 1.000,00 € used, but I thought that perhaps if you live in Germany, France, or another EU country then it is common.
Web Development
Active