Reading the original Terms of Use & Privacy Policy linked in the capture gave me a chuckle. It seems someone tried to find + replace div tags with p tags as the documents repeatedly refer to "inpiduals."
For a famous example of find and replace gone wrong, see the case about the creationist Of Pandas and People textbook and cdesign proponentsists:
The term "creationists" was changed to "design proponents", but in one case the beginning and end of the original word "creationists" were accidentally retained, so that "creationists" became "cdesign proponentsists". ... the proof that intelligent design was creationism re-labeled played a significant part in the Kitzmiller trial, and "cdesign proponentsists" has been described as "the missing link between creationism and intelligent design."
OT: in Emacs, you could prevent this from happening by using C-u M-% (replace-word): in that case, only those instances of "div" that are separate words (not parts of other words) will be replaced.
How would you avoid "inpiduals" (and similar mistakes) in other editors?
I believe replacing `<div`\'<p' and `/div`\'/p' are preferred so you can retain any tag properties (class, id, style, etc), but it could still leave behind any tags with superfluous spaces.
In many editors, you can use a regex match for word boundaries on either side of div, like \bdiv\d. Some also have a checkbox for the word matching functionality.
Huh - that’s confusing in the context of this example, but indeed tests fine on my system (nvi).
Since the “word” in question is “<div>”, I thought the \< was just an escape. I looked in various docs and the best I see in Tcl re_syntax(n) is \< and \> are synonyms for [[:<:]] and [[:>:]] respectively, which are constraints matching empty strings at the beginning and end of words, where a word a sequence of word characters... [a-zA-Z0-9_]
Funny to see those websites from back in the days when HTML was still hand made and handcrafted
You might be surprised which giant corporations have given up on all the framework hype and language tribalism and actually allow their web devs to build sites by hand with care.
I'm thinking of one particular multi-billion dollar company, but there are a number of others.
It's poking fun at how there's a new flavour of JavaScript framework seemingly every week: Angular, React, Vue, Mithril, etc. Each one has a killer feature or some new spin on how to write your JavaScript code.
The word "vanilla" is used here as an adjective to describe something that is "lacking distinction: plain, ordinary, or conventional" [0].
As such, the joke is that Vanilla JS is being presented as some amazing new framework, but it isn't anything more than regular JS that you would write. In a sense, it's the anti-JS framework, requiring no additional scripts or dependencies.
If a program generates something, and then a human hand-curates it, that’s maybe hand crafting (the program is being used as a tool by the human artisan.)
But if a program generates something, and then just directly serves the result, it is certainly not hand-crafted.
The distinction comes down to whether the final result is something a human signed off on and took responsibility for, or whether it’s just the result of blind rule-following.
Yes. I don't know why HN likes to pretend they're exceptions to patterns and processes that came about for a number of reasons.
In this specific case, the hand crafted HTML that I've come across in my lifetime is usually absolute garbage. I can normally see how the developer who wrote it thinks they're being clever or nifty, and dare I say it "clean", but it usually falls short and causes more harm than good.
So imagine we as an industry organically build tools to address this. 10 years later it's pretty good, but like 5 major websites still handcraft things because they have complicated user experiences with a broad user base.
We then get dork heads who see this, believe they're part of the exception, despite not having anything remotely close to the userbase or requirements of these websites, refuse to understand why certain things are the way they are, and think they're above these processes and frameworks despite not having invested any real time or effort into the skills necessary to justify not using these frameworks or fabricated HTML.
And the worst part is it's just HTML. And we still get it wrong.
TL;DR Programmers think they're better than they really are. Use the frameworks.
Honestly if you question the overall quality of hand-written HTML (by people who care to hand-write it) with the overall output of tools, I kind of wonder what parallel universe you come from.
I've never yet see anyone argue that the reason tools took over the writing of HTML is because hand-written HTML wasn't good enough.
When HTML was hand written, it was largely awful. Just like anything people make. Bespoke HTML is now usually nice because the people who care to make it are the type of people who care about that sort of thing.
Hand-written HTML may have had the occasional error but when tools (remember FrontPage and Dreamweaver?) started to be used their output was dramatically worse. This was certainly not controversial at the time. Nowadays with templating languages and frontend frameworks (React is operating on the DOM but it is still just HTML elements in the end) there's still a human picking the elements and attributes that are rendered, even if there is a layer of indirection. So I don't really get the argument that hand-written HTML is bad, especially since it's ubiquitous. HTML was designed with hand-authoring in mind.
> I kind of wonder what parallel universe you come from.
The one where I don't value bespoke development just because it's bespoke?
The universe where I have to actually quantify what's good and what isn't?
The worst kind of comments related to this discussion are always the ones that are insufferably offended that they can't out perform decades of experience and knowledge without doing anything.
>I've never yet see anyone argue that the reason tools took over the writing of HTML is because hand-written HTML wasn't good enough.
Check who you're listening to? It's a fairly common argument.
My position is based on decades of actually looking at HTML, writing it, creating a few web authoring tools along the way, and participating tangentially in HTML5 standardization.
I'm not insufferably offended by what you think I can or can't do (I couldn't care less) I just honestly can't fathom, after 20 years of looking at HTML produced by hand and by tools, how anyone could think the tools produce better markup if you're actually talking about inherent quality of the end result. Cheaper and faster, maybe, with a lower learning curve, sure, but better? I don't buy it.
Some programmers confuse XML with semantic HTML. XML is hard to hand write, while semantic HTML is easy and forgiving. CSS on the other hand is more difficult, but its also much more powerful and still easier to hand-write compared to other XML-markups variants (native UI).
Apple.com has a ton of static pages and then a mix of WebObjects apps and some other frameworks. There’s also a WordPress blog or two on there. A few years ago they messed up the Apache config and next.com worked as apple.com for a while.
