Not sure about this one. I understand the need and the idea behind it is well-intentioned, but I can easily see denouncelists turn into a weapon against wrongthinkers. Said something double-plus-ungood on Twitter? Denounced. Accepted contribution from someone on a prominent denouncelist? Denouced. Not that it was not possible to create such lists before, but it was all informal.
The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. Here is my idea:
- The owner of a repo can close a PR either neutrally (e.g. an earnest but misguided effort was made), positively (a valuable contribution was made) or negatively (worthless slop)
- Depending on how the PR was closed the reputation rises or drops
- Reputation can only be raised or lowered when interacting with another repo
The last point should prevent brigading, I have to make contact with someone before he can judge me, and he can only judge me once per interaction. People could still farm reputation by making lots of quality PRs, but that's actually a good thing. The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PRs, but people can already do that sort of thing. Maybe the reputation should not be a total sum, but per project? Anyway, the idea is for there to be some negative consequences for people opening junk PRs.
> The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs.
GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem.
To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away.
Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.
I mean, "everyone already has an account" is already a very good reason. That doesn't mean "I automatically accept contributions from everyone", it might be "I want to make the process of contribution as easy as possible for the people I want as contributors".
Hatching a reputation-based scheme around a "Contributor Management System" and getting "the people you want as contributors" to go along with it is easier than getting them to fill in a 1/username 2/password 3/confirm-password form? Choosing to believe that is pure motivated reasoning.
> GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem.
The community might be a problem, but that doesn't mean it's a big enough problem to move off completely. Whitelisting a few people might be a good enough solution.
GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"
I know this is a joke, but pretending for a moment that it isn’t: this would immediately result in the rep system being gamed the same way it is on eBay: scam sellers can purchase feedback on cheap or self-shipping auctions and then pivot into defrauding people on high-dollar sales before being banned, rinse, and repeat.
Let's also see the differences: On github you can always see the interactions. On ebay, once a sale has been made, you have no idea what happens next. On Github you always have all the artifacts of where the reputation comes from.
On auctions, you do not have to provide a payment method to bid. So once you won an auction you still have to pay the agreed price. Only after the buyer paid, does the seller get the shipment address. Depending on the buyer this can take longer or shorter (or won't happen at all).
I don't know how it is where where you live, but here there are two possibilities I can think of:
- When I buy an item I still have to click a "check out" link to enter my address and actually pay for the item. I could take days after buying the item to click that link.
- Some sellers might not accept PayPal, instead after I check out I get the sellers bank information and have to manually wire the money. I could take days after checking out to actually perform the money transfer.
I think merged PRs should be automatically upvoted (if it was bad, why did you merge it?) and closed unmerged PRs should not be able to get upvoted (if it was good, why did you not merge it?).
Intrinsically good, but in conflict with some larger, out of band concern that the contributor could have no way to know about? Upvote to take the sting out of rejection, along with a note along the lines of "Well done, and we would merge is it weren't for our commitment to support xxx systems which are not compatible with yyy. Perhaps refactor as a plugin?"
Also, upvotes and merge decisions may well come from different people, who happen to disagree. This is in fact healthy sometimes.
>The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PR
Ya, I'm just wondering how this system avoids a 51% attack. Simply put there are a fixed number of human contributers, but effectively an infinite number of bot contributers.
> Given the borrowing of ideas, why then do modern Christians, including evangelicals, dismiss other cultures so aggressively?
That's really just an American thing. Americans have this concept of "manifest destiny" in their culture is the final one and it is their duty to spread it to the rest of the world. The American settlers have colonized the entire continent, but the spirit of Manifest Destiny still persists, just embodied in different forms.
For example, among evangelicals there is this paranoia of anything that might be considered pagan. Some will go even so far as to consider Christmas pagan. Meanwhile in the rest of the world it's perfectly accepted that Christianity has taken some local practices and re-dedicated them to Christ. This is not a concession to pagans to make Christianity more palatable for them (pagans are not stupid, they know it's a different religion). I can recommend the YouTube Channel "Jonathan Pageau", he used to talk a lot about this sort of stuff in his older videos.
Not only that, but there are both non western Christian traditional (middle eastern, Ethiopian, Indian) and these are both accepted in the major churches (e.g. the Syro-Malabar rite within the Catholic church) and encouraged (its called inculturation).
> For example, among evangelicals there is this paranoia of anything that might be considered pagan.
Many Christians also see much of value in aspects of paganism. its pretty mainstream - for example CS Lewis argues that God can reveal himself to pagans too (there is quite a bit about this in The Pilgrims Regress).
> It's in OnePlus's interest to make their phones less appealing for theft,
I don't believe for a second that this benefits phone owners in any way. A thief is not going to sit there and do research on your phone model before he steals it. He's going to steal whatever he can and then figure out what to do with it.
Which is why I mentioned that carriers or Google might have that as a requirement for partnering with them. iPhones are rarely stolen these days because there's no resale market for them (to the detriment of third party repairs). It behooves large market players, like Google or carriers, to create the same perception for Android phones.
Thieves don't do that research to specific models. Manufacturers don't like it if their competitors' models are easy to hawk on grey markets because that means their phones get stolen, too.
It actually seems to work pretty well for iPhones.
Thieves these days seem to really be struggling to even use them for parts, since these are also largely Apple DRMed, and are often resorting to threatening the previous owner to remove the activation lock remotely.
Of course theft often isn't preceded by a diligent cost-benefit analysis, but once there's a critical mass of unusable – even for parts – stolen phones, I believe it can make a difference.
Yes thieves do, research on which phones to steal. Just not online more in personal talking with their network of lawbreakers. In short a thief is going to have a fence, and that person is going to know all about what phones can and cannot be resold.
"Hey, you know that thing no one understands how it works and has no guarantee of not going off the rails? Let's give it unrestricted access over everything!" Statements dreamed up by the utterly deranged.
I can see the value of agentic AI, but only if it has been fenced in, can only delegate actions to deterministic mechanisms, and if ever destructive decision has to be confirmed. A good example I once read about was an AI to parse customer requests: if it detects a request that the user is entitle to (e.g. cancel subscription) it will send a message like "Our AI thinks you want to cancel your subscription, is this correct?" and only after confirmation by the user will the action be carried out. To be reliable the AI itself must not determine whether the user is entitled to cancelling, it may only guess the the user's intention and then pass a message to a non-AI deterministic service. This way users don't have to wait until a human gets around to reading the message.
There is still the problem of human psychology though. If you have an AI that's 90% accurate and you have a human confirm each decision, the human's mind will start drifting off and treat 90% as if it's 100%.
Right, user-confirmed "translation" is the responsible way to put LLMs into general computing flows, as opposed to stuffing them in everything willy-nilly like informational asbestos mad-lib machines powered by hope an investor speculation.
Another example might be taking a layperson's description "articles about Foo but not about Bar published in the last two months" and using to suggest (formal, deterministic) search-parameters which the can view and hopefully understand before approving.
Granted, that becomes way trickier if the translated suggestion can be "evil" somehow, such as proposing SQL and the dataset has been poisoned so that it "recommends" something that destroys data or changes a password hash... But even that isn't nearly the same degree of malpractice as making it YOLO everything.
Serious question: why would you ever want to not close tags? It saves a couple of key strokes, but we have snippets in our editors, so the amount of typing is the same. Closed tags allow editors like Vim or automated tools to handle the source code easier; e.g. I can type `dit` in Vim to delete the contents of a tag, something that's only possible because the tag's content is clearly delimited. It makes parsing HTML easier because there are fewer syntax rules.
I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have. HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML. Even though I don't have to, I strive to adhere to the stricter rules of closing all tags, closing self-closing tags and only using lower-case tag names.
> I never understood why the more strict rules of XML for HTML never took off
Internet Explorer failing to support XHTML at all (which also forced everyone to serve XHTML with the HTML media type and avoid incompatible syntaxes like self-closing <script />), Firefox at first failing to support progressive rendering of XHTML, a dearth of tooling to emit well-formed XHTML (remember, those were the days of PHP emitting markup by string concatenation) and the resulting fear of pages entirely failing to render (the so-called Yellow Screen of Death), and a side helping of the WHATWG cartel^W organization declaring XHTML "obsolete". It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax.
I think most of those are actually no longer relevant, so I still kind of hope that XHTML could have a resurgence, and that the tag-soup syntax could be finally discarded. It's long overdue.
What I never understood was why, for HTML specifically, syntax errors are such a fundamental unsolvable problem that it's essential that browsers accept bad content.
Meanwhile, in any other formal language (including JS and CSS!), the standard assumption is that syntax errors are fatal, the responsibility for fixing lies with the page author, but also that fixing those errors is not a difficult problem.
HTML is a markup language to format text, not a programming or data serialization language so end users have always preferred to see imperfectly coded or incompletely loaded web pages imperfectly rendered over receiving a failure message, particularly on 90s dialup. Same applies to most other markup languages.
The web owes its success to having low barriers to entry and very quickly became a mixture of pages hand coded by people who weren't programmers, content produced by CMS systems which included stuff the content author didn't directly control and weren't necessarily reliable at putting tags into the right place, and third party widgets activated by pasting in whatever code the third party had given you. And browsers became really good at attempting to rendering erroneous and ambiguous markup (and for that matter were usually out of date or plain bad at rigidly implementing standards)
There was a movement to serve XHTML as XML via the application/xhtml+xml MIME type but it never took off because browsers didn't do anything with it except loading a user-hostile error page if a closing tag was missed (or refusing to load it at all in the case of IE6 and older browsers), and if you wanted to do clever transformation of your source data, there were ways to achieve that other than formatting the markup sent to the browser as a subset of XML
Your premise is not correct because you're not aware that other data formats also have parsers that accept malformed content. Examples:
- pdf files: many files with errors can be read by Adobe Acrobat. And code PDF libraries for developers often replicate this behavior so they too can also open the same invalid pdf files.
- zip files. 7-Zip and WinRAR can open some malformed zip files that don't follow the official PKZIP specification. E.g. 7-Zip has extra defensive code that looks for a bad 2-byte sequence that shouldn't be there and skips over it.
- csv files. MS Excel can read some malformed csv files.
- SMTP email headers: Mozilla Thunderbird, MS Outlook, etc can parse fields that don't exactly comply with RFC 822 -- make some guesses -- and then successfully display the email content to the user
The common theme to the above, including HTML... the Raw Content is more important than a perfectly standards-compliant file format. That's why parsers across various domains make best efforts to load the file even when it's not 100% free of syntax errors.
>Meanwhile, in any other formal language (including JS and CSS!), the standard assumption is that syntax errors are fatal,
Error: CSS: background-color: none is not a background-color value. From line 276, column 212; to line 276, column 215
Error: CSS: padding: 8x is not a padding value.
Job hunters in the real world want to see the jobs because the goal is to get a paycheck. Therefor, a web browser that didn't show the webpage just because the author mistakenly wrote CSS "none" instead "transparent" and "8x" instead of "8px" -- would be user hostile software.
> csv files. MS Excel can read some malformed csv files.
At work we have to parse CSV files which often have mixed encoding (Latin-1 with UTF-8 in random fields on random rows), occasionally have partial lines (remainder of line just missing) and other interesting errors.
We also have to parse fixed-width flat files where fields occasionally aren't fixed-width after all, with no discernible pattern. Customer can't fix the broken proprietary system that spits this out so we have to deal with it.
And of course, XML files with encoding mismatch (because that header is just a fixed string that bears no meaning on the rest of the content, right?) or even mixed encoding. That's just par for the course.
It's mostly historical. Browsers accepted invalid HTML for 10 years, there's a lot of content authored with that assumption that's never going to be updated, so now we're stuck with it.
We could be more strict for new content, but why bother if you have to include the legacy parser anyway. And the HTML5 algorithm brings us most of the benefits (deterministic parsing) of a stricter syntax while still allowing the looseness.
> never going to be updated, so now we're stuck with it.
Try going to any 1998 web page in a modern browser... It's generally so broken so as to be unusable.
As well as every page telling me to install flash, most links are dead, most scripts don't run properly (vbscript!?), tls versions now incompatible, etc.
We shouldn't put much effort into backwards compatibility if it doesn't work in practice. The best bet to open a 1998 web page is to install IE6 in a VM, and everything works wonderfully.
The vast majority of pages from 1998 work fine today. VBscript was always a tiny minority of scripting. And link rot is an undeniable problem but that’s not an issue with the page itself.
You’re unlikely to find a 1998-era Web page still running a 1998-era SSL stack. SSL was expensive (computationally and CA-cartel-ically), so basically banks and online shopping would have used SSL back then.
Syntax errors are not fatal in CSS. CSS has detailed rules for how to handle and recover from syntax errors, usually by skipping the invalid token. This is what allows introducing new syntax in a backwards-compatible manner.
> What I never understood was why, for HTML specifically, syntax errors are such a fundamental unsolvable problem that it's essential that browsers accept bad content.
Because HTML is a content language, and at any given time the main purpose of the main engines using it will be to access a large array of content that is older than the newest revision of the language, and anything that creates significant incompatibilities or forces completely rewrites of large bodies of work to incorporate new features in a standard is simply not going to be implemented as specified by the major implementers (it will either not be implemented at all, or will be modified), because it is hostile what the implementations are used for.
Because HTML is designed to be written by everyone, not just “engineers” and we’d rather be able to read what they have to say even if they get it wrong.
It's more that it's exceedingly easy to generate bad X(H)ML strings especially back when you had PHP concatenating strings as you went. Most HTML on the web is live/dynamic so there's no developer to catch syntax errors and "make build" again.
I was there, Gandalf. I was there 30 years ago. I was there when the strength of men failed.
Netscape started this. NCSA was in favor of XML style rules over SGML, but Netscape embraced SGML leniency fully and several tools of that era generated web pages that only rendered properly in Netscape. So people voted with their feet and went to the panderers. If I had a dollar for every time someone told me, “well it works in Netscape” I’d be retired by now.
> It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax.
Well, this is not entirely true: XML namespaces enabled attaching arbitrary data to XHTML elements in a much more elegant, orthogonal way than the half-assed solution HTML5 ended up with (the data-* attribute set), and embedding other XML applications like XForms, SVG and MathML (though I am not sure how widely supported this was at the time; some of this was backported into HTML5 anyway, in a way that later led to CVEs). But this is rather niche.
Emitting correct XHTML was not that hard. The biggest problem was that browsers supported plugins that could corrupt whole page. If you created XHTML webpage you had to handle bug reports caused by poorly written plugins.
Why did markdown become popular when we already have html? Because markdown is much easier to write by hand in a simple text editor.
Original SGML was actually closer to markdown. It had various options to shorten and simplify the syntax, making it easy to write and edit by hand, while still having an unambiguous structure.
The verbose and explicit structure of xhtml makes it easier to process by tools, but more tedious for humans.
Personally I think Markdown got _really_ popular not because it is easier to write but because it is easier to read.
It’s kind of a huge deal that I can give a Markdown file of plain text content to somebody non-technical and they aren’t overwhelmed by it in raw form.
People had already ditched writing HTML for years before Markdown came out.
People were just using other markup languages like rST.
Other attempts had already proven HTML to be a bad language for rough documentation. Someone then just needed to write a spec that was easy to implement and Markdown was that.
Imho the real strength of markdown is it forces people to stick to classes instead of styling. "I want to write in red comic Sans" " I don't care, you can't".
And markdown tables are harder to write than HTML tables. However, they are generally easier to read. Unless multi line cell.
I've been closing my tags for 30 years and I assume that I will for the rest of my days. I like that it validates as XML. Historically I used XSLT a LOT.
User input data is always to be treated as suspect when it reaches the server and needs to be scanned and sanitised (if necessary) before accepting it for processing. Markdown makes this a lot easier to do and this is why it became popular.
A lot of HTML tags never have a body, so it makes no sense to close them. XML has self-closing tag syntax but it wasn't always handled well by browsers.
A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends. Closing li also creates the opportunity for nonsensical content inside of a list but not in any list item. Of course all of these corner cases are now well specified because people did close their tags sometimes.
> A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends
While this is true I’ve never liked it.
<p>blah<p>blah2</p>
Implies a closing </p> in the middle. But
<p>blah<span>blah2</p>
Does not. Obviously with the knowledge of the difference between what span and p represent I understand why but in terms of pure markup it’s always left a bad taste in my mouth. I’ll always close tags whenever relevant even if it’s not necessary.
This interpretation of the p element implies that it contains a paragraph. But HTML is first and foremost a document format, and one could just as logically conclude that the p element simply starts a new paragraph. Under the latter interpretation, </p> would never exist any more than </hr> or </img>.
In practice, modern HTML splits the difference with rigorous and well defined but not necessarily intuitive semantics.
I was going to respond that HTML was the original syntax and XML the usurper, but a comment in another thread casts some doubt on that version of events: https://news.ycombinator.com/item?id=46576844
> I never understood why the more strict rules of XML for HTML never took off.
Because of the vast quantity of legacy HTML content, largely.
> HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML.
WHATWG and its living standard that W3C took various versions of and made changes to and called it HTML 5, 5.1, etc., to pretend that they were still relevant in HTML, before finally giving up on that entirely, was a direct result of the failure of XHTML and the idea of a clear cut between legacy HTML and the future of HTML. It was a direct reaction against the “clear cut” approach based on experience, not an opportunity to repeat its mistakes. (Instead of a clear break, HTML incorporated the “more strict rules of XML” via the XML serialization for HTML; for the applications where that approach offers value, it is available and supported and has an object model 100% compatible with the more common form, and they are maintained together rather than competing.)
EPUB 3.x spec uses “XHTML” to refer to the XML serialization of HTML in the current WHATWG HTML living standard, not the separate historical standard from HTML known as XHTML.
The obsolete EPUB 2.x (and earlier, I believe) specs actually used XHTML (XHTML 1.1 in EPUB 2.x), though.
Yes, that is an important point. I guess I was focused mainly on the browser. Which is not the typical way to consume epubs. But you are right that ePubs are essentially packaged XHTML.
Because I want my hand-written HTML to look more like markdown-style languages. If I close those tags it adds visual noise and makes the text harder to read.
Besides, at this point technologies like tree-sitter make editor integration a moot point: once tree-sitter knows how to parse it, the editor does too.
For the same reason css still works if you make a typo and javascript super dynamic: its a friendly interface.
Html, css and js got used so much because you could mess around and still get something to work. While other languages that people use to write “serious” applications just screamed at you for not being smart enough to know how to allocate memory correctly.
Html and css is not a competitor to C. Its more like an alternative to file formats like txt or rtf. Meant to be written by hand in a text editor to get styled pages. So easy and forgiving your mom could do it! (And did, just like everyone else in the myspace days)
I built a testing framework, and I wanted it to generate HTML reports during testing with not post-processing report compilation step. I wanted the html in real-time so if a test was cut short for any reason from killing the job to power failure, you'd have a readable html report showing where things stopped.
I could do this by just appending divs as rows without closing any of the parent divs, body or html tags.
So the more general answer, anytime you want to continuously stream html and not want to wait until the end of the document to begin rendering.
I would argue the stricter rules did take off, most people always close <p>, it's pretty common to see <img/> over <img>—especially from people who write a lot of React.
But.
The future of HTML will forever contain content that was first handtyped in Notepad++ in 2001 or created in Wordpress in 2008. It's the right move for the browser to stay forgiving, even if you have rules in your personal styleguide.
> I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have.
XHTML came out at a time when Internet Explorer, the most popular browser, was essentially frozen apart from security fixes because Microsoft knew that if the web took off as a viable application platform it would threaten Windows' dominance. XHTML 1.1 Transitional was essentially HTML 4.01 except that if it wasn't also valid XML, the spec required the browser to display a yellow "parsing error" page rather than display the content. This meant that any "working" XHTML site might not display because the page author didn't test in your browser. It also meant that any XHTML site might break at any time because a content writer used a noncompliant browser like IE 6 to write an article, or because the developers missed an edge case that causes invalid syntax.
XHTML 2.0 was a far more radical design. Because IE 6 was frozen, XHTML 2.0 was written with the expectation that no current web browser would implement it, and instead was a ground-up redesign of the web written "the right way" that would eventually entirely replace all existing web browsers. For example, forms were gone, frames were gone, and all presentational elements like <b> and <i> were gone in favor of semantic elements like <strong> and <samp> that made it possible for a page to be reasoned about automatically by a program. This required different processing from existing HTML and XHTML documents, but there was no way to differentiate between "old" and "new" documents, meaning no thought was given to adding XHTML 2.0 support to browsers that supported existing web technologies. Even by the mid-2000s, asking everyone to restart the web from scratch was obviously unrealistic compared to incrementally improving it. See here for a good overview of XHTML 2.0's failure from a web browser implementor's perspective: https://dbaron.org/log/20090707-ex-html
Imagine if you were authoring and/or editing prose directly in html, as opposed to using some CMS. You're using your writing brain, not your coding brain. You don't want to think about code.
It's still a little annoying to put <p> before each paragraph, but not by that much. By contrast, once you start adding closing tags, you're much closer to computer code.
I'm not sure if that makes sense but it's the way I think about it.
In the case of <br/> and <img/> browsers will never use the content inside of the tag, so using a closing tag doesn't make sense. The slash makes it much clearer though, so missing it out is silly.
"Self-closing tags" are not a thing in HTML5. From the HTML standard:
> On void elements, [the trailing slash] does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
It was mainly added to HTML5 to make it easier to convert XHTML pages to HTML5. IMO using the trailing slash in new pages is a mistake. It makes it appear as though the slash is what closes the element when in reality it does nothing and the element is self-closing because it's part of a hardcoded set of void elements. See here for more information: https://github.com/validator/validator/wiki/Markup-%C2%BB-Vo...
It's not a mistake if you want to be able to use XML tools on your HTML. It's basically no effort to make HTML also be valid XML so you'd might as well get the additional tooling compatibility and simplicity for free. For the same reason, it's courteous toward others.
Self-closing tags do nothing in HTML though. They are ignored. And in some cases, adding them
obfuscates how browser’s will actually interpret the markup, or introduce subtle differences between HTML and JSX, for example.
How does the slash make it clearer? It's totally inert, so if you try to do the same thing with a non-void tag the results will not be what you expect!
It indicates that the content that follows is not inside of the tag without the reader needing to remember how HTML works. Tags should have either a self-closing slash, or a closing tag.
The third way of a bare tag is where the confusion comes from.
It doesn't indicate that, though. If you write <div />, for example, the content that follows is inside of the tag. So the reader still needs to remember how HTML works, because the slash does nothing.
Contrary to <img /> or <br />, <div /> is necessarily a mistake or intentionally misleading. The unfamiliar reader should not stumble upon <div /> too often. <div /> is a bug. It's a bit like using misleading indentation in C-like programming languages. Yeah, it can happen, and is a source of bugs, but if the page is well written, the regularity of having everything closed, even if it's decorative for the spec, can help the unfamiliar reader who doesn't have all the parsing rules in mind.
Now, we can discuss whether we should optimize for the unfamiliar reader, and whether the illusion of actual meaning the trailing slash in HTML5 can be harmful.
I would note that exactly like trailing slashes, indentation doesn't mean anything for the parser in C-like languages and can be written misleadingly, yet we do systematically use it, even when no unfamiliar reader is expected.
At this point, writing a slash or not and closing all the tags is a coding style discussion.
Now, maybe someone writing almost-XHTML (closing all tags, putting trailing slashes, quoting all the attributes) should go all the way and write actual XHTML with the actual XHTML content type and benefit from the strict parser catching potential errors that can backfire and that nobody would have noticed with the HTML 5 parser.
Because browsers close some tags automatically. And if your closing tag is wrong, it'll generate empty element instead of being ignored. Without even emitting warning in developer console. So by closing tags you're risking introducing very subtle DOM bugs.
If you want to close tags, make sure that your building or testing pipeline ensures strict validation of produced HTML.
I have seen babies with pierced ears and studs. Even when there is no religious pressure some people are just so sick in their head, they will have their babies put through mutilation just because they think it looks "cute". Those people deserve to have railroad spikes driven through their skin.
I would advocate for banning all non-necessary body modification on small children. And before anyone tells me "it's better to do it when they are small, then they won't remember it": no remembering the source of a trauma makes is even worse. That's like saying date rape drugs are no big deal because the victim can't remember it.
> 7 deaths in 20 years out of who knows how many hundreds of thousands if anything is a testament to how safe the procedure is.
That's still seven deaths too many for a surgery (without anesthetics!) which has no medical necessity. Tonsillectomy is also a very safe procedure, yet we don't just do them willy-nilly because any form of surgery carries its own risk, no matter how small.
I really hope that functional programming and property-based testing [1][2] get taken seriously by real engineers who understand that it is important to know and understand what the program is doing. Something LLMs by their very nature cannot do.
I was writing a React application at work based on React Flow[3] and I was mucking about with state management libraries (because that's what the React Flow manual recommends). Maybe it was a skill issue on my part, but I had a hard time with the Zustand library. Then I read up on reducers in React and everything was perfectly clear. A reducer is just a pure function, it takes an existing state and an action and returns the new state. That's simple, I can wrap my brain around that. Plus, I know how to test a pure function, there is nothing to mock, stub or wrap. States and actions are just plain JavaScript objects, there is no history, no side effects, no executable code.
And this is where property-based testing comes in: if history does not matter it means I can randomly generate any valid state and any valid action, then apply the reducer function and verify that the resulting state has all the required properties. Only a formal proof would give me more certainty.
I fully understand people who want to use LLMs to write tests for them. Writing test cases is boring and tedious. There are many edge cases a human might miss. But relying on a guessing machine and praying it does not write nonsense is just plain irresponsible for someone who calls himself an engineer. People rely on the quality of our software for their work and personal safety. Property-based testing frees us from the tedium and will generate many more tests and we could write by hand, but it does so in a predictable manner that can be fully reasoned about.
I agree with the core point: the more pure and deterministic a system is, the easier it is to reason about and test. Reducers + property-based testing push correctness into design, not brittle test cases.
One nuance though: property-based testing shines when the domain is already well-modeled. A lot of real QA pain comes where purity breaks down—distributed systems, async flows, partial failures, UI↔backend boundaries. At that point, the hard part isn’t generating tests, it’s reconstructing context.
On LLMs: I don’t think they should be trusted as correctness oracles either. Their real value isn’t guessing answers, but helping surface assumptions, generate counter-examples, and expose gaps in our mental model.
So the future of QA isn’t humans vs LLMs. It’s better system design + explicit invariants + tools that help engineers doubt their own certainty faster. Most serious bugs come from being sure we understood the system when we didn’t.
> People being allowed to part ways and not having to stick with their partner until death is one of the great achievements of feminism.
And it has been one of the greatest mistakes humanity has ever made. If there is a good reason, sure, you cannot be expected to live with someone who has been cruel or irresponsible towards you. But no-fault divorce just because you got bored? Fuck off, you made a commitment at the time. Relationships do take work, always have and always will. Especially when there are children a no-fault divorce is pure selfishness.
With that said, we only know one side of this story, so I'm not going to argue for either side in this particular case. I'm talking in general here.
I live in one - New Zealand is a modern western society.
Making marriage the norm would not fix any of the issues I see in my own society, and marriage causes other problems.
Many people I know (including solo mums) that I know would love to find someone worthwhile marrying... However they haven't (or can't) find someone worthwhile, so it is better to remain single than get married into a dangerous relationship.
I suspect you are mistaking cause and effect. Marriage isn't a cause, it is an outcome.
That's just not how humans work. Love can fade. People change. It's the natural course of things. Sometimes there is just no one at fault for love being lost and no way to prevent that. We just gave up the illusion that love in marriage is always forever.
love is not an emotion , love is willing sacrifice , breaking a lifelong commitment because of faded emotions is pathetic and has nothing to do with your feminism argument
The problem here is the usage of "no-fault". It can be interpreted differently by everyone.
Does fault only include cheating? Can the fault be on the same one who initiated the divorce? What if the fault is simply someone has changed so much that they're no longer compatible with person they fell in love with before? The fault could be on oneself without any inkling of infidelity.
Til death do us part has been ironically dead for decades now since people have been divorcing at high rates for long enough that it doesn't really mean much anymore, and that's okay. Things change.
>The problem here is the usage of "no-fault". It can be interpreted differently by everyone.
No, it's a legal term. From wikipedia:
>No-fault divorce is the dissolution of a marriage that does not require a showing of wrongdoing by either party.[1][2] Laws providing for no-fault divorce allow a family court to grant a divorce in response to a petition by either party of the marriage without requiring the petitioner to provide evidence that the defendant has committed a breach of the marital contract.
It quite literally means that people can request divorce for any reason.
The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. Here is my idea:
- The owner of a repo can close a PR either neutrally (e.g. an earnest but misguided effort was made), positively (a valuable contribution was made) or negatively (worthless slop)
- Depending on how the PR was closed the reputation rises or drops
- Reputation can only be raised or lowered when interacting with another repo
The last point should prevent brigading, I have to make contact with someone before he can judge me, and he can only judge me once per interaction. People could still farm reputation by making lots of quality PRs, but that's actually a good thing. The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PRs, but people can already do that sort of thing. Maybe the reputation should not be a total sum, but per project? Anyway, the idea is for there to be some negative consequences for people opening junk PRs.
reply