But can't they just use an xpath expression to test the computed text content of a node, like `/path/to/ad/div[contains(., 'sponsored')]`? In that expression, there could be any number of nested elements inside the terminal `<div>` and it wouldn't matter. (And you'd probably have to use a regex test to account for tricky white space.)
I see this is part of the Triptych project, an attempt to, among other things, bring more verbs into HTML forms. As I've said before one of my long-time dreams is to have HTML forms support methods other than GET and POST.
Clicking on forms is how humans interact with HTTP, and for some strange reason the web has evolved to omit many very important words us humans must use to communicate. While a machine is allowed to say `DELETE /widgets/123`, a human is forced to say `POST /widgets/123/delete` or `POST /widgets/123?_method=DELETE`.
This is not only semantically incorrect, but also results in idempotency and caching issues, and, perhaps worst of all, forces developers to maintain two separate APIs: nice, well-formed REST endpoints for machines, and separate kludgy endpoints for humans, who were granted a stunted language.
REST doesn't care about the content of your URI path / query as long as it is unique to the resource and POST's semantics are so flexible you can perform any action with it:
> The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
SE Editor-in-Chief here. We selected the William Cullen Bryant translation because we felt that, of the public domain translations, it was the one most accessible to modern readers. We also host his translation of the Iliad.
Pope's is certainly very beautiful, but also very literary and written in a style of English that can be difficult for the average modern reader. I think that determination is well reflected in this survey. Maybe we'll do it too one day (our current collections policy declines alternate translations) - it's certainly deserving.
That’s a common trope I see in “old” books (most recently for me in _Old Mortality_) that I can’t recall ever seeing in modern ones - deliberately obscured words intended to convey a notion of realism without naming an actual place or person. I guess it’s the 555 phone number of old books.
Supporting more than GET/POST in HTML forms has been my dream for decades. There's a WHATWG proposal to do just that if you want to add your voice: https://github.com/whatwg/html/pull/11347
I'm not convinced of the benefit of allowing PUT/PATCH/DELETE in forms. But QUERY sounds more useful, and its lack of side-effects (plus the lack of legacy code using it) would avoid the need for CORS preflight requests.
Because if HTTP is the language of the web, then HTML forms are how humans speak that language to computers. Right now we humans can only speak GET and POST.
In other words, right now if a human wants to DELETE a widget, the human has click on an HTML form to `POST /widgets/123/delete` - i.e. use an incorrect verb on an incorrect URL/object - or use some other workaround like smuggling a special `_method=DELETE` variable. This is unnatural and semantically incorrect, resulting in ugly hacks that break HTTP-level expectations like idempotency; and it also requires additional app-level logic to process.
Meanwhile a machine is allowed to simply `DELETE /widgets/123` because their interface to HTTP is not clicking on HTML forms.
We humans could converse with websites in semantically correct HTTP, have clean URLs in which both REST APIs and human-facing URLs are identical without hacks, and require no extra app/framework logic, if HTML forms simply allowed all (human-relevant) HTTP verbs.
Things like that are why it's completely unreasonable to expect websites to work without first party Javascript. Utterly basic and mundane functionality is gated behind Javascript.
Building the mundane in the absence of JavaScript isn't some small thing you can build. It's going to require you to rebuild your entire site around the idea. Things like a searchable dropdown will now turn a single page form into a horrifying multi page mess where you get sent to a page for just the dropdown and the search box and selectable options, which then send you back to the original form. That is going to require you to store a lot of the form data on the server to keep track of what you entered across pages rather than let the browser do its thing.
The noscript crowd should have lobbied for a better HTML instead of rallying against JavaScript.
It is almost a use case in itself: to make an form in pure HTML to allow user to update/delete a resource on the server, without violating the HTTP semantics with routes like `POST /items/:id/delete`.
Home folder litter is one of my top pet peeves in computing. In fact it's the only reason why I refuse to use snaps on Ubuntu. I don't even care about whatever technical stuff everyone argues about - but snaps create a permanent `~/snap/` directory and Ubuntu devs don't care. There's been a bug report on Launchpad for over a decade[1] and it's the second highest voted bug in Ubuntu history, but no, Ubuntu devs think littering the home folder with highly visible system-level machinery is totally unavoidable.
It's like putting your car's engine in the passenger seat - rude, intolerable, and plain stupid. What if Grandma was browsing her home folder and deleted `~/snap/` because she has no idea what it is?
I want to add an addendum to this. There's just so much bad naming everywhere. So often I'll be looking for configs and can't find them because the name of the configs folder isn't remotely the same as that of the program. How is anyone supposed to know? `~/.config/TrollTech.conf`? Are you really telling me you don't expect people to be confused? The only nice thing I can say is that at least it is put in `~/.config` and not `~/.` There's plenty of things with more menacing looking names too.
Hell, it isn't even computers. I bought a monitor from Samsung recently and it showed up in my bank as Hanwha Vision. You google it and you find a wiki page for the company, and read
> Hanwha Vision (Korean: 한화비전), founded as Samsung Techwin, is a video surveillance company.
or you look at the parent company, which was originally Korea Explosives. Seriously, if fucking In N Out can show up as "IN N OUT <LOCATION>" they can just show up as "Samsung" or something else actually meaningful.
I know there's 2 problems in computer science but there's a huge difference between not having a good name and having a misleading name. And don't get me started on emails. People wonder why there's so much fraud, but I'm just impressed there isn't more. The normal way things work makes it hard to distinguish things from fraud. We've just created a world where the signal is impossible to distinguish from the noise because we decided it was a good idea to obfuscate the signal...
This is why Linux needs a sensible, universal way to hide files that doesn't involve bloody renaming them (since that will just cause the original one to be re-created! What is that!?). Many file managers respect the .hidden file, which is a start! But it's not enough, shells and `ls` don't care. It's one of those many strange failures that make Linux on the desktop still painful to use.
On topic of hidden files: wherefrom is the pattern of treating configuration files as hidden? I'm referring to the pattern of `.configfile` -- I mean, for code projects, a local config file is a first-level construct. This leads to hidden files being not being a viable construct, as there is no longer any consensus on what should be hidden.
I don't know the answer to this, but I have to wonder if, for source files specifiically, .git is the culprit here... It's not part of your project, it's part of your repo. Which maybe makes sense if people ever divorced their source code from the repo but that's not a thing anymore. Others probably just copied it.
The gem in this post is Pure, which I haven't heard of until now. I also have my prompt show the git status, and for large repos `git status` can take 10+ seconds to load and cache.
I had no idea that you could do that asynchronously, and then have ZSH update the already printed prompt with the status later! That blows my mind!
If you like that, you should check out my project https://beachcomber.sh . Its about time I take it from dogfooding to beta users if you want to give it a go.
SE editor in chief here. What you describe is incorrect. The only thing we do is very light sound-alike spelling modernization, like "to-night" -> "tonight". We do not do things like change from en-GB to en-US, replace old words with different modern words, or change text for "American readers", whatever that means. I have no idea where you got that impression.
I personally worked on the Forsyte saga. If you think something was done in error, please let us know and we'll be happy to fix it.
This article is rediscovering the same phenomenon that happened when the steam-powered machinery was invented, leading to the Luddite movement.
Machinery at the dawn of the industrial revolution was supposed to be a time-saving miracle that freed capitalists from having to deal with workers, and also freed workers from backbreaking labor, letting them spend their hours in the pursuit of leisure.
Of course, the opposite happened. Machinery meant workers could produce more output in the same amount of time, so they didn't work less, they worked at least the same and eventually even more to keep up with competition and the demands of consumers. It took decades of unrest and bloody conflict to give us the 8-hour workday.
This article is rediscovering that same history, but for a different class. AI is to white-collar knowledge workers what steam-powered machinery was to the rough-handed working class of the 1800s. It promises capitalists freedom from having to deal with highly-paid knowledge workers, and it promises highly-paid knowledge workers freedom from their labor so they can spend their time in the pursuit of leisure.
I've always told people, Kindles are ereaders seeming designed by people who hate books.
The renderer is atrocious and is holding back the entire industry, much like IE6's crappy renderer and monopoly on users held the entire web back a decade. Browsers (and thus ebooks, which are just HTML/CSS) can now do pretty decent typography, but Amazon inexplicably refuses to get on board with epub.
Their file formats are equally garbage. Mobi, a format that has hardly changed since circa the year 2005, was still in active use until just recently. Their other proprietary formats are confusing in feature set and are opaque to create. The official tool to create Amazon ebooks only runs on Windows![1]
Kindles still can't natively read epubs, but since they accept epubs via email, their customers get confused and email me about it. (Epubs sent via email are quietly convert to Amazon's propriety format, meaning all bets are off on the result. Good luck, publisher!)
I always tell people, buy literally any other ereader.
[1] Calibre can also create them but it's reverse-engineering and not the official implementation.
