@1:10:20

With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]

NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.

@48:20

I should actually add that the PDF specification only specifies the file format and very few what we call process requirements on software, so a lot of those sort of experiential things are actually not defined in the PDF spec.

See also:

Alas, many things really must be experienced to be understood. We didn’t have much of an experience to deliver to them though — after all, the whole point of all this evangelizing was to get people to give us money to pay for developing the software in the first place! [...] When people ask me about my life’s ambitions, I often joke that my goal is to become independently wealthy so that I can afford to get some work done. Mainly that’s about being able to do things without having to explain them first, so that the finished product can be the explanation. I think this will be a major labor saving improvement.

From http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/

The metadata for this collection are not so great. Have a look here, instead: https://archive.org/details/pub_whole-earth

High fidelity scans are available at the Internet Archive: https://archive.org/details/sim_whole-earth_spring-1987_54/page/n3/mode/1up

This quote is introduced without a clear antecedent. What is it a reference to?

@55:10

Sri: [...] you can think about the possibility that we're actually going to do this with structured data but then properly incentivizing people in order to actually moderate and curate the set of facts about the world—

Will: Yeah, so I was gonna mention that, and I'm glad we're on the same wavelength here. What are the economic incentives that would help encourage the adding of correct, factual data to this knowledge graph and dissuade, I guess, spammers? [...]

Sri: Yeah, I think that there needs to be some compelling reason for people to want to add data to the knowledge graph. [...] I think that, "Can we get a knowledge graph that is expansive—as expansive as Wikipedia—that, you know, says all kinds of facts about the entire world?" Yeah, maybe[...]

Will: There are parts of the Web where people do that without financial incentives. I mean people list like every episode of, I dunno, Game of Thrones and annotate every time that people get killed or [...] all sorts of stuff. Fandom is like [a] huge thing and they just put out these... or like the—if you ever played Minecraft and looked at the Minecraft wiki, it's just so (chuckles) so detailed. Like, "Who spends all their time...?" [...]

Sri: The idea of fandom actually is very relevant here, because [...] I have so far been thinking about the idea that the incentives have to be backed by some type of economic value—

Will: Yeah, for a certain class of things [...] There are some things that are very well-tuned to economic incentives and the other stuff is well-tuned to fandom, right?

Video available here: https://www.youtube.com/watch?v=bjn5jSemPws

For checking which posts are new/updated, this is always the case. The only thing the HTTP cache-related headers can tell is that the feed itself has/hasn't changed.

Huh?

Bluh? This is exactly what looking for link[rel=alternate] is for—these "patterns" listed are arbitrary URLs...

Crazy! This underscores how badly Mastodon—and ActivityPub, generally—need to be revved to enable network participation from low-cost (essentially free) static* sites.

* quasi-static, really—in the way that RSS-enabled blogs are generally considered static sites

⬑ what khinsen calls software collapse

• limit capabilities it depends on (POLA)
• target the World Wide Wruntime (i.e. the browser), which is the only reliable platform that exists and can be expected to exist in the future

⬑ "The Code Rot Problem"

This page has a neat effect, first apparent with this example, where a blur effect is used on most of the text in the code block, except for lines 11–13 which are shown in sharp focus. (You can mouse over the code block to eliminate the blur effect.)

.torchlight.has-focus-lines .line:not(.line-focus) {
        transition: filter 0.35s, opacity 0.35s;
        filter: blur(.095rem);
        opacity: .65;
}

Each line is dumped into a div and the line-focus class set on those which are supposed to be unblurred.

(For ordinary code blocks without any blur/focus effect, the has-focus-class line is simply not used.)

This doesn't need to happen, and wouldn't happen if people treated blog posts for what they are—artifacts—instead of conceptualizing them as live systems.

That's not good.

The phrase "optional dependency" is an oxymoron.

The answer is ZIP and wget/curl and forgetting about sharing dependencies. Disk space is way cheaper than the time spent (often in frustration) trying to get something to work.

Not angling towards that sort of future is a lot like people from the punch card and paper tape era not allowing the computers do the stuff that computers do better than humans when it became cheap enough to let computers do it.

Good response overall, but with respect to this remark, I have been in different but not dissimilar situations where something like this does happen.

E.g. person notices that every time they enter a room (kitchen, let's say) everything looks just like it did the last time they saw it, and they aren't ever interrupted e.g. by my trying to use the space at the same time that they are. They then (incorrectly) conclude that it looks that way because I just never use that space (and it's okay for them to make a mess, or not worry about being mindful of how much time they're using the space for)—rather than registering the thought, "Gee, he really picks up after himself and tries to stay out of the way—a real life example of 'you won't even notice I'm here'. Maybe I should be that considerate."

@35:19

"This is how the working classes are robbed. Although their incomes are the lowest, they're compelled to buy the most expensive articles[...] the lowest priced articles. Everybody knows that good clothes, boots, or furniture are really the cheapest in the end, although they cost more money at first; but the working classes can seldom or never afford to buy good things. They have to buy cheap rubbish which is dear at any price."

@31:25 Robert Noonan's story.

Type-B procrastination accounts for a lot of the junk I see on people's GitHub timelines—and that type of social network-backed gamified gratification is why I've adopted a stance where I impose a huge entry fee on any workflow that routes itself through GitHub's servers.

Every time Bill Maher goes off on a tear about how American society should venerate old people the same way it happens in other countries, I can't help but think, "What 20 year old was Bill trying to fuck this week that led to these hurt feelings?" I'm picking up hints of that here, too.

Is this Paul's way of getting out of responsibilities? "No, I don't need to do that. See? I wrote a piece about it!"

@55:39

I would feel a little bit sad, but at the same time, this is a pattern I've seen happen over and over again. And especially with these big ideas about computing and self-expression and things like that [...] people start with these huge, huge ideas, but I think that they are so different--the diff is so much between where society is now and what some of these people are thinking about--that the most that can be absorbed at one time is like one unit--one meme--from that whole big vision. So, we're just gonna take like one small step at a time, and [...] you kind of just have to accept that, you know, that's success.

Garner, Bryan A. "Celebrating Plain English in Michigan." ABA Journal 107.5 (2021): 36. Business Insights: Global. Web. 7 Oct. 2022. URL http://bi.gale.com.atxlibrary.idm.oclc.org/global/article/GALE|A690034782/c13f1855872f0a231a7139cf729c45b6?u=txshrpub100020

Document Number: GALE|A690034782

This does not bode well for the scope of the project.

Stupid comment. HEB is a South and Central Texas thing.

What about GCC? https://minnie.tuhs.org/pipermail/tuhs/2020-May/021225.html

Boy, this was hard to read. I've noticed a lot of Substack pieces that I've come across are written like this—tenuous, self-contradictory, and written in this voice. Very weird.

NB: the requirement wasn't actually "parsing JSON in C"; it's that for the JSON parsing the machine ultimately executes the same (or similar) instructions that it does when the JSON parsing is written in C and that C is compiled with GCC.

Lame. Esp. since GitHub Pages is a thing.

Current revision of README: https://github.com/t-mart/kill-sticky/blob/124a31434fba1d083c9bede8977643b90ad6e75b/README.md

We're creating a bookmarklet, so our code needs to be minified and URL encoded.

Run the following the project root directory:

$ docker build . -t kill-sticky && docker run --rm -it -v $(pwd):/kill-sticky kill-sticky

Disclaimer: I don't give two shits about the topic that is the subject of this post. However...

It would be feasible to get around this by 1. Separating your existing mobile app cleanly between client and content 2. Converting your client into a general purpose Web browser... that Tumblr (let's say) happens to work really, really well with

(This concludes this special bonus episode of Nathan For You.)

More seriously...

Frankly, we need a lot more opinionated, intelligent user agents that are thoughtfully designed act on the content in a way that fits the user's desires—rather than trying to conform to what other Web browsers feel like today.

It looks like gotostage.com keeps the Wayback Machine from getting a copy as a consequence of two things:

The server sends no real hypertext—it's all part of a JS bundle that builds the (scan) content in-place.

What the server does send is an invisible link to https://www.gotostage.com/honeypot, which the Wayback Machine's crawler will follow. Presumably, this flags it as a bot.

Video link (1:20:04) points to https://cdn.recordingassets.logmeininc.com/1270644358637705220/1204201970482829316/fb820e62-67ca-43c9-bab0-6c765ab5acaf/recording/3230979087624514052/transcode/3230979087624514052.mp4?Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdXJjZSI6Imh0dHBzOi8vY2RuLnJlY29yZGluZ2Fzc2V0cy5sb2dtZWluaW5jLmNvbS8xMjcwNjQ0MzU4NjM3NzA1MjIwLzEyMDQyMDE5NzA0ODI4MjkzMTYvZmI4MjBlNjItNjdjYS00M2M5LWJhYjAtNmM3NjVhYjVhY2FmLyoiLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE2NjQ1NjIwMTJ9LCJJcEFkZHJlc3MiOnsiQVdTOlNvdXJjZUlwIjoiMC4wLjAuMC8wIn19fV19&Signature=Cj~BpP90aY6KOiBMeafsYwxPY-UB20vWeNSUqalooCRMOmnmByIZlXVLF-5dG-4J3CfkugZsLA28c6EWd5~QGH9nrpgZRzpn8I2mq7arfUpGER~FSXn-Tbuaqjyw9ObyY06QNNgszdxtSgKjeMA0mswKAZmq2RP4tgJf0ctKwlW8ASEVhfh-dceb-WcedEBaZSeqOyaaTK40wcY2n2EpBKpAKBwnFgST4LTOOmDB60UMvwMhL7dnjzzZTe8fesQgVV52LwOQkPt5A3CNUttt1wnHMiBdoe-M38Z8qCzY~WcyEcirzz0cnneXFpnE~GI4znPyzlHhfAAx7Dj8ud6m~g__&Key-Pair-Id=APKAI2Z3PWL3BWDDZ5IA&response-content-disposition=attachment

(The Wayback Machine has a copy.)

Redirects to https://gato-docs.its.txst.edu/jcr:cd5d535d-4892-4bd5-aa23-009f192d65b8/Civil%20Procedure%20%e2%80%93%20Tricky%20Issues%202020%20Handout%20Update%20.pdf (as of this writing).

Try https://web.archive.org/web/20111102182554/http://adamspitz.com:80/avocado#post-14

Presaging version control systems.

Typo in the tag here; "transculsion" should be "transclusion".

Well, the whole point of the Web was that everything would be given a (world-wide) identifier. Your current list of bookmarks has an identifier, but it's a local one. Once you have a world-wide identifier, it's only short jump to making it resolvable so that your bookmarks list has a URL, and browsing your bookmarks would be as simple as visiting that list.

Or read it here: https://archive.org/details/weavingweb00timb/page/n9/mode/2up

Pssh. 9-780062-515872 isn't the ISBN (which is 006251587X). It's the EAN-13.

No way. HTML is way better suited for it!

The fact that this book is an SPA—instead of just, you know, a bunch of web pages—is very annoying.

Totally screws up my ability to middle click the "links" in the TOC.

It also messes up the browser scroll position when clicking back/forward.

You're looking for https://www.science.org/doi/10.1126/science.98.2557.580.b, probably.

(This DOI, i.e. 10.1126/science.98.2557.580-a, is linked to from https://pubmed.ncbi.nlm.nih.gov/17835862/).

This is a massive failure of infrastructure (and education/"professionalism"—by and large, most people whose careers are in operating or maintaining Web infrastructure don't haven't been inculcated into or adopted the sort of "code of ethics" that sees this as a failure).

The thing might just be for something like the Internet Archive to get into training or selling professional services for handling companies' "Web presence, done the right way". (This is def. take some organizational restructuring, however.) I'd like to see, for example, IA-certified partner organizations that uphold the principles described here and the original vision for the Web, and professional associations that work hard at making sure the status quo improves a lot over what's common today (and doesn't slide back).

Hmm. I'm skeptical of the certainty with which this is said.

Given a series of trials the claim here is that if you took a blockbuster and released it for "free" (supported by ads) on YouTube) then the ad revenue even when multiplied by the greater number of viewers would not only not surpass ticket sales from the subset of the same viewers who'd be willing to pay for tickets, but that it wouldn't even be able to cover the production budget. That's both a strong claim and a claim that I'm not sure is correct. For comparison, Netflix (and even ad-supported streaming services, albeit ones with lower budgets) seem to do pretty well with just a fraction of the <$10-per-viewer take that makes up monthly revenue.

dubious

principle of least (literal) power

The notion of "productive consumption" has, for some people, an almost irresistible appeal.

There's a presumption here (and in the linked article) that those people want to talk to you—that they're just quietly suffering their desire to have some interaction with you, if only it were the case that you'd allow it. This is way more condescending than the thing that the article seeks to correct.

Thankses simply do not belong in a bug report. It's an almost surefire indicator that there's something wrong culturally and that your bugtracker isn't so much being used for bug reports as it is filled with support requests.

In other words, no to the rotten cultural expectations that are by far what you're most likely to encounter on GitHub. I promise—things really were so much better before it came along to try to be Facebook-for-software-development.

I think the default assumption that this is what's going on is a huge part of the problem. I see a similar thing happen on GitHub constantly, where project maintainers try to "upperhand" contributors, because they see the contribution as something deliberately undertaken to benefit the person who is e.g. submitting a bug report. This is a massive shift away from the spirit of the mid-to-late 2000–2010 era characterized by initiatives like Wikipedia (and wikis generally) and essays by Shirky on the adhocracy around the new digital commons.

Directly related to a question I posed a few years ago about who should really be funding open source. My conclusion: professional developers who are are most directly involved with how the source is put to work—and who benefit from this (in the form of increased stature, high salaries and bonuses, etc., in comparison to the case where the FOSS solution hadn't been available). This runs counter to the popular narrative that frames the employer as a "leech" and silent on the social and moral obligations of the employee who successfully captured value for personal gain.

It's like this: the company has some goal (or "roadmap") that involves moving forward from point A to point B. The company really only cares about arriving at the desired destination B. They negotiate with a developer, possibly one who has already signed an employment contract, but someone who is made aware of the task at hand nonetheless. The developer agrees to do the work meant to advance the company towards its goals, which potentially involves doing everything manually—that is, handling all the work themselves. They notice, though, that there is some open source software that exists and that can be used as a shortcut, which means they won't have to do all the work. So they use that shortcut, and in the end their company is happy with them, and they're rewarded as agreed (not necessarily at the end, but rewarded nonetheless with e.g. regular paychecks, but also possibly receiving a bonus), and they advance in their career. Who's extracted value from the work of the open source creator/maintainer here? Is it really just the company?

McQuaid seems to agree with my view, going by the way he (later) identifies both Bob and TechCorp as benefitting from Reem's work; cf https://hypothes.is/a/MBN0aDnuEe2aF8s2kWTPrg

See above.

You can check at uspto.gov. (The search engine is terrible, by the way.)

See below

visible-web-page looks to have been published and/or written on 2022 June 26.

I emailed Omar a few weeks earlier (on 2022 June 7) with with a link to plain.txt.htm, i.e., an assembler (for Wirth's RISC machine/.rsc object format) written as a text file that happens to also allow you to run it if you're viewing the text file in your browser.

(The context of the email was that I'd read an @rsnous tweet(?) that "stuff for humans should be the default context, and the highly constrained stuff parsed by the computer should be an exceptional mod within that", and I recognized this as the same principle that Raskin had espoused across two pieces in ACM Queue: The Woes of IDEs and Comments Are More Important Than Code. Spurred by Omar's comments on Twitter, I sent him a link to the latter article and plain.txt.htm, and then (the next day) the former article, since I'd forgotten to include it in the original email.)

JS engines are good from a technical perspective. The problem with JS is the Node/NPM culture.

Again: mostly enabled by the fact that he was young.

Another key ingredient. Society is participatory.

This is not to be discounted. Mentoring is a big deal generally, but a lot of what made this possible likely came from the novelty of dealing with a child. If you replace Kevin with, say, a 25 year old who is no more or less capable or committed, what changes is others' behavior in their interactions.

This design constraint is exactly what people are so bothered about 30 years later. Generality! Portability! That's why you don't get to exercise full control of the sort that your "native" stack would give you. It's also why the Web has not only endured, but has attained a level of ubiquity that is not matched by any other "platform".

• https://foldoc.org/Compound+Document+Architecture
• https://en.wikipedia.org/wiki/Open_Document_Architecture
• https://www.osti.gov/servlets/purl/5671048
• http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/vms/vax_document/AA-PB6KA-TE_DEC_ODA_Compound_Document_Architecture_Gateway_Users_Guide_199104.pdf
• VMS Compound Document Architecture Manual, Digital Equipment Corporation, Maynard, MA., December 1988

This touches on the subtle, underrated brilliance of Wikipedia's (mostly) flat namespace.

Intertwingularity is inescapable.

Thirty years on, we're still losing stuff. (You could even argue that the Web—as it has been put in practice, at least—has exacerbated the problem.)

Lots of the problems that Hypothesis runs into (incl. those described here in this post!) could be attributed to this. They could probably be neatly described in a volume titled "The Perils of Self-Publishing", in a section dedicated to the consequences of non-uniform practices.

Here's the Anno pitch deck: https://docdrop.org/pdf/Hypothesis_deck_22Aug-4b7ys.pdf/

Taken from Maciej Cegłowski https://idlewords.com/talks/website_obesity.htm.

common misapprehension; only command procedures are commands (not "everything")

helena-lang.org should host a demo in the form of a copy of the "meat" of the project that can run directly in the browser from the open web (ideally launched via a single button here on the homepage) without having to install an extension (or at least anything more complicated than a bookmarklet)

This highlights a problem with the Web: the fusion of document identifiers and the channel through which the (or "an") information/service provider makes it available.

Suppose stakeholder S wants to mirror a document D (published in an HTML-based format) originally distributed by authority A. This will probably involve having to touch D in order to rewrite links to point at S's copies of auxiliary resources instead of A's originals. Simply copying the representation's bytestream is not sufficient.

"[... temporarily]"

Wrong. Here, I'll show you:

Forget about AGI for a moment. Instead, pretend we're talking about pecan pie. Most people probably can't answer the question, "What would I recognize as a pecan pie?" (or a sandwich). And yet thousands of people are able to make (and thousands more people are able to enjoy) pecan pie all the time—probably every day.

This RFC lacks any acknowledgement of the text/uri-list media type.

Also: just don't take photos/videos and reduce your social media "footprint" generally.

Privacy-respecting alternatives don't address the issue raised earlier with the comparison to the celebrity iCloud leaks. Because, to reiterate, privacy and security are different things.

See: Surveillance Camera Man * https://boingboing.net/2012/11/02/surveillance-camera-man-wants.html * https://www.youtube.com/watch?v=X9sVqKFkjiY

Someone is going to need to eventually explain their convoluted reasons for labeling this a downside.

Sure, strictly speaking, a bigger source tree is bad, but delegating to package.json and npm install doesn't actually change anything here. It's the same amount of code whether you eagerly fetch all of it at the same time or whether you resort to late fetching.

Almost none of the hypothetical benefits apply to the way development is handled in practice. There was one arguably nice benefit, but it was a benefit for the application author's repo host (not the application author), and the argument in favor of it evaporated when GitHub acquired NPM, Inc.

No, those are orthogonal. Whether you obtain the code for your dependency* at the same time you clone your repo or whether you get it by binding by name and then late-fetching it after the clone finishes, neither approach has any irreversible, distinct consequences re bugs/fixes.

* and it still is a dependency, even when it's "vendored"...

Additionally, as more time passes, it will become less and less of a problem.

It's a little bit of a misapprehension/mistake to describe this as translation into JS.

It only occurred to me reading this now, and musing about the code size and relative performance of simple programs written first in a to-be-compiled-to-JS language and then in JS, that the folks associated with these pushes are taking the sufficiently smart compiler position. Connected to superinferiority?

This is probably too ambitious, impractical. For most cases, it would suffice to make sure that the tools used to produce "traditional" release packages can run in the browser. (I.e., the release itself need not be able to run in the browser—though it doesn't hurt if it can.)

"secure" is used in this context to mean, roughly, "work with adversarial input"

I also found https://github.com/sbarman/Ringer

Some other things:

• If I visit https://www.zylstra.org/blog/ and content from e.g. this blog post https://www.zylstra.org/blog/2022/09/10-thoughts-after-100-annotations-in-hypothes-is/ has been inlined, Hypothesis doesn't know how to deal with this—it doesn't know that the annotations that apply to the latter can also be layered onto the inlined content at /blog/. This is a minor quibble insofar as you can measure it on terms of mere convenience. Less minor, however, is that if a user attaches their annotations to /blog/, then it will eventually be orphaned (as more posts are written and the now-current ones get bumped off the page), and will never appear in the correct place on the actual post.

• When people annotate Wikipedia there's a high likelihood that the annotation will become orphaned as the content changes, even though the version that was actually annotated will usually be available from the article history.

This was Peter's motivation to create annotations.lindylearn.io.

Public ones, at least.

What kind of premium services?

Traveler:

You want https://www.w3.org/DesignIssues/LinkedData.html

Traveler:

You want https://www.w3.org/DesignIssues/Webize.html

This reminds me of "I did write some code in Java once, but the code was in C and Lisp (I simply happened to be in Java at the time ;-)".

This link is a 404. Why did Roy start doing this?

Example of when "proprietary" is not an antonym of "open source".

Another approach, inspired by the <label> element, would be to encode these selectors as separate <link> elements in the head. You could write your links as normal, and then add these <link rel="selector" for="foo" href="XXX[...]X" /> to your document (where foo is the ID of the <a> element, and the href value is selector).

Neat.

The answer is: linking party pays. I.e., after 30-ish years of the Web put into practice, what has emerged is that it is the linking party's responsibility to ensure:

• that the material remains available (by keeping a copy around, or arranging for the same thing by delegating to a third-party), and
• there is some reliable way to establish provenance (which can be handled in tandem with delegation to same third-party, as with availability)

These are only necessary if these two (availability and reputable provenance) are actually desirable properties. But in the event that one or the other or both is desired, the rule is that linking party pays.

This is the only realistic one—and the only way to reconcile the vast pre-Web corpus that is ostensibly meant to be ingested to occupy a first-class status on the Web.

It still ~requires some amount of versioning (though not necessarily with the cooperation of the publisher, from whom it would be prudent to assume harbors a mildly adversarial outlook; cf Wayback Machine, Perma.cc, etc).

It's almost like a pick two/impossible trinity.

You can either have: - a resource that stays up-to-date (e.g. by a convenient URL that always points to the most recent revision, i.e. documents are mutable) - links that don't break

You can't have both.

If you choose the latter, your document can never change--not even to say the current version is out of date. This also means using unique ("versioned", you could say) URLs--one for every revision, with it only* being possible for later revisions to point to earlier ones, almost like a Git-like DAG.

If you choose the former, you're gonna be breaking your links (and those of others, too).

* The workaround would be to include in rev A (which predates rev B) a URL to a non-existent resource, and you preregister your commitment to deposit a document (rev B) there. Not possible in systems which rely on content hashes, but imminently doable under the norms of the way URLs get minted. (Still doesn't fix the problem of have a clean and up-to-date URL like /pricing or /about/team, though.)

I don't understand this.

Presaging lightweight wikilinks? (Or at least WikiWords?)

The page https://www.w3.org/DesignIssues/Multiuser.html#3 links here (to #GenericLinking).

Since this page currently returns 404, try https://www.w3.org/History/19921103-hypertext/hypertext/Products/Microcosm/Microcosm.html.

Why it's pointless to insist that links should have been bidirectional: it's unenforceable.

Try * http://www.html-tidy.org/ * https://github.com/htacg/tidy-html5

Obnoxious.

As someone recently pointed out on HN, it's very common nowadays to encounter the no-one-knows-else-what-they're-doing-here refrain as cover—I don't have to feel insecure about not understanding this because not only am I not alone, nobody else understands it either.

Secondly, if your code is hard to understand regarding its use of this, then your code his hard to understand. this isn't super easy, but it's also not hard. Your code (or the code you're being made to wade into) probably just sucks. The this confusion is making you confront it, though, instead of letting it otherwise fly under the radar.* So fix it and stop going in for the low-effort, this-centric clapter.

* Not claiming here that this is unique; there are allowed to be other things that work as the same sort of indicator.

And by the way, if you ever do do anything good with it, it'll just become a cesspool of people posting Donald Trump memes and complaining about what movie didn't have the right people in it on Twitter. That's what your inventions will be used for, right? Not advancing humankind and producing some kind of good future for everybody.

... says the guy who has dedicated his life to video games.

Previously: https://hypothes.is/a/tCHXEvj-Eey1N3dRiP4I4Q

Nice property. It would be nice if HTML Tidy could do the same.

This is the earliest known reference to HTML's class attribute that I've found in a public document so far: 1995 May 6 in draft spec 02 (i.e. the third revision) of the HTML 2.0 spec.

This postdate's Håkon W Lie's original CSS proposal (from 1994 and which doesn't mention classes) and predates the first CSS draft specification (dated to 1995 May 31 in one place and which mention's HTML's ability to subclass in order to "increase the granularity of vcontrol" [sic]).

The "subclassing" word choice here is interesting. It matches the model eventually suggested in HTML 3.x, but at the time of this draft, HTML was in a draft specification stage (third revision — "02") for HTML 2.0

I'm interested in the discussion that led to this.

You sure about that, Dan-from-25-years-ago?

You're looking for this, I think: https://www.w3.org/People/Connolly/9703-web-apps-essay.html

If you manage to find a copy of this (or already have one) please let me know!

It's always funny/interesting to read these not-quite-projections about overhyped tech from a far enough vantage point, but this sounds a little like what I've advocated for in the past, which is resurrecting Google Gears.