A Text Renaissance
ribbonfarm.com
ribbonfarm.com
/cue dry-heaving
Twitter's good for simple pieces of news, witty quips, and putdowns. That's about it. You can't actually communicate complex, novel ideas in 280 characters, and you still can't in 2800. The only redeeming feature of Twitter that draws these commentators to it is that all journalists are addicted to it, so your one-liners might get you some fame. People have made careers out of that.
The problem is that with such a small amount of space, you can't tell what's credible and what's not unless you already know who's right... I trust @BullshitQuantum only because I can check a fair number of its calls. How is anybody not trained in quantum mechanics supposed to tell @BullshitQuantum's takes from the hundreds more that actually are bullshit?
Fixed it for you man! Really, the only purpose twitter serves is as the comments section people removed because everyone in the comments section was slinging poo at OP. And they're removing this, the one truly useful thing twatter does, because journalist types are head cases who think larping and carping on twitter is real life.
Twitter's strength is it appears peer to peer, twitters weakness is it isn't at all.
- Roam Research: note taking using bidirectional links: https://www.youtube.com/watch?v=v9s3pusI1JQ
- Substack: monetizing email newsletters
- Static websites: high-performance, low-cost blogs when compared to WordPress
- Threaded Twitter: aggregating and collecting long threaded tweets as writers are using Twitter as a micro-blogging platform
- Ebooks: better than printed books
- "Blogging is Dead, Long Live Blogging"
Ebooks are great. But they are different from paper books. They are like a cousin in the family: different, sure, but better? It's hard to say. Printed books' long-lasting beauty and tactile qualities are just not replicable by ebooks. Ebooks have other advantages, but the reading experience is not comparable.
Yes the ebook reading experience is lightyears ahead of books. Books are really awkward to hold after an hour or so.
Yes it is. The XML spec itself begins with the following sentence:
> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document
XML doesn't have "self-closing tags". If you mean XML empty elements, those have been incorporated into SGML as well in the Annex K amendment to ISO 8879 (aka WebSGML), precisely so that XML could remain a proper subset of SGML. Btw WebSGML was specified by the same people (W3C's "extended review board") as XML, so XML being a subset of SGML is of course no coincidence.
> SGML is as much a "superset" of HTML as the concept "language" is a superset of English
SGML, like XML, is a meta-language in which to define a markup vocabulary such as HTML. All versions of HTML, including W3C HTML 5.2 (the most recent spec) can be parsed using SGML and eg. my DTD for W3C HTML 5.2 ([1], [2]).
> How does Markdown relate to SGML at all?
Using Wiki syntaxes such as markdown isn't exactly a new thing; in fact, SGML (from 1986 or earlier) already has a facility where you can define custom tokens for a given element context that are then replaced by SGML into arbitrary replacement text; in practice, this is used to map custom tokens into tags. For example, the following SGML DTD implements a small markdown fragment (converts markdown asterisk characters into canonical HTML <em> angle-bracket syntax):
<!DOCTYPE p [
<!ELEMENT p - - ANY>
<!ELEMENT em - - (#PCDATA)>
<!ENTITY start-em '<em>'>
<!ENTITY end-em '</em>'>
<!SHORTREF in-p '*' start-em>
<!SHORTREF in-em '*' end-em>
<!USEMAP in-p p>
<!USEMAP in-em em>
]>
<p>The following text:
*this*
will be put into EM
element tags</p>
[1]: http://sgmljs.net/docs/sgml-html-tutorial.html[a]: https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html
For capturing complete markdown-to-HTML conversion? No. Lists and tables (tables are btw GitHub-flavored markdown but not supported by John Gruber's original Markdown.PL) aren't so much a problem as reference links where you need unbounded lookahead. Eg markdown allows links such as "[a link][linktarget]", then have a definition for linktarget such as
[linktarget]: http://blabla.com
"Link title"
anywhere before or after the link use in the document, and requires that the link text "Link title" appears as the value of the title attribute of the anchor tag generated from the link use. That doesn't work with SGML short references which are strictly local transformations.However, SGML has the concept of public declaration text to make markdown-to-HTML transformation appear transparently "as if" it were implemented using short references when actually an integrated hardcoded markdown renderer is used. The following DTD captures this concept and tells an SGML parser (that knows about markdown by the given public identifier) to switch on markdown processing:
<!DOCTYPE html [
<!ELEMENT html O O (head,body)>
<!-- ... -->
<!ENTITY % md_shortref_maps
PUBLIC "+//IDN sgmljs.net//SHORTREF Markdown//EN">
%md_shortref_maps;
]>
...
What this does is that it - virtually - pulls in shortref declarations for markdown into a parameter entity (md_shortref_maps), then references/expands that parameter entity such that it becomes part of the declaration set text. But an SGML parser is free to interpret declarations denoted by the public identifier as purely symbolic, and treat the parameter entity reference as a signal to switch on markdown processing. So this is kindof cheating, but in a way that is conformant with SGML, and retaining its declarative semantics.> Are you saying that an ordinary SGML parser will produce the expected tree for any valid HTML 5 document as specified in the HTML5 spec [...] using your DTD?
In [1] (see "TALK" slides), I've reported on results for parsing w3c-tests.org/html tests:
> sgmlproc [...] restricted to relevant test cases, succeeds in parsing 942 of 966, or 97.31% of the html52lib tests suite
That has to be put into context, though. The test suite normatively referenced by the W3C spec is based on the older html5lib test suite (Python-based parser) and a moving target (the spec doesn't reference a particular commit); frankly, the relation W3C's spec has with html5lib tests isn't sufficiently clear. There's also a (supposedly) more relevant test suite created/maintained as part of W3C's validator.nu effort (a HTML5 parser written in Java which to my knowledge also doesn't align with a particular HTML version, just as WHATWG HTML itself isn't versioned), and which might or might not be maintained. Also, the test suite is written in such a way that tests always produce a result (because that's what HTML5 does - give a consistent meaning to any bytes that could be sent to a browser) using the procedural spec for HTML parsing given in chapter 8, whereas my DTD is based on the normative grammar rules given in chapter 4 of the spec. Finally, I've already reported several flaws in the grammar rules, etc.
Long live plain text!
I notice there are some people who have a habit of writing this way, and I sometimes wonder if there is any audience that appreciates it. Myself, I can't stand it; it is so irritating that I usually give up on understanding the point, just to save myself the pain of the prose.
It works better if you know what you’re getting into and are prepared for a long read with some personality.
Its not written to simply present information, but very opinionated views in colorful language. The author seems to strike a good balance without overdoing it.
There is no visible way to get past that newsletter screen and if I do try to subscribe it actually redirects me through some tracking site that pihole (helpfully) blocks. What an absolutely terrible design and user-hostile experience. Shame on them. They lost one possible user for sure.
The beta and the newsletter are two different things.
The intro is so abstract ("stab at lightly theorizing") it doesn't actually introduce any point at all (what is the main takeaway of this light theory?). Skimming through the article it seems to be all over the place topically. The conclusion appears to be a word salad I can't make heads or tails of.
This is already highly upvoted, but I don't have the slightest idea what its point is and am clearly not the only one.
Can anyone who's read it enlighten us what it's about?
Well, the author does at least admit that: "So it’s going to be a sprawling, messy hot take on the State of Textual Media. Or at least a simmering take, since I’ve been thinking about this stuff for a year on the backburner".
Not that I disagree with you. My immediate reaction, rightly or not, was to remember the review comment 'It is not even wrong' [0].
I guess this post itself would make an exemplary twitter thread.
I don’t see what folks find valuable in his writing. On top of that I find his recommendations to be bad since better alternatives exist but they obviously don’t fit his monetization strategy.
Quite on point given Twitter has recently diminished the utility of thread-viewing within their web application. Now when visiting a tweet URL that is part of a thread, the UI displays only a single tweet, though the title says "Thread." Instead of replies, a "More tweets" section follows. The user must click "See replies" to actually see the thread.
The most egregious aspect of this anti-feature is that the URL doesn't change after requesting to see the replies. There is no way, to my knowledge, to avoid linking people to this frustrating interstitial page. Each visitor must individually navigate themselves past the "More Tweets" feature.
Presumably added as a ham-fisted engagement booster, the new interstitial has materially reduced my own interaction with Twitter threads because it adds friction. It's amusing how often engagement boosting tactics end up achieving the opposite.
... which couldn't be further removed from reality.
Going back into the past, Twitter originated as a side-project without a clear goal or business model. Over the past 15 odd years, it has pivoted several times, depending on how the audience interacted with the service, and what were best decisions towards monetization. No more, no less.
At one point, Twitter was a micro-blogging platform. It didn't even invent micro-blogging. There were many services alike at the time such as identi.ca, FriendFeed, Plurk, Tumblr and so on (https://en.wikipedia.org/wiki/Microblogging).
The main reason why tweets were originally 140 characters long was because they made it relatively easy - for the time - to connect with the service through text messages. Remember: Twitter originated in the era before the iPhone was introduced. They stuck with that limit because that was what set Twitter apart and what made it radically different from other services.
Threaded Twitter entirely hinges on the notion of @ mentions. Which wasn't originally even a feature of the service. It took until 2008 before they added that @replies and only in late 2009 they became @ mentions as we know them now. https://en.wikipedia.org/wiki/Mention_(blogging)#@_(At_sign)
At that point, they didn't even have this vision of "threads". Users simply started to create these "cowpaths" on their own in order to circumvent the 140 character limit by @ mentioning themselves and creating these long reads on the platform.
The primary reason why doing that is appealing... is because that's where the audience is. Because Twitter happened to funnel massive social networks into a centralized solution which gives individuals the immediacy of communication at zero financial cost.
Put differently, if individuals would be able to reach out to a large audience through a decentralized online solution as part of a public commons at zero cost and with the same level of immediacy, there wouldn't be much need for a service like Twitter. Whether or not content is threaded isn't even relevant. That's just the form, and that always follows the function.
Twitter doesn't represent society at large nor does it represent how humanity at large communicates. It's just one of many forms of communication, albeit a very visible one as large amounts of capital have been sunk into this particular private venture.
As such, the prerogative of being part of the crowd using a decentralized, open infrastructure is that one is always free to look for new and different ways to connect, communicate and convince that don't necessarily have to be subjected to the whims of a single private actor. If threads on Twitter work out for you, even when Twitter designs against them, that's fine. If you want to use some other tool, that's valid too.
Even in the age of social media, there are still people running BBS'es.
The feature treadmill makes sense if you're trying to sell a piece of software; but for the most part, a tool that was good enough for building blogs eight years ago is still good enough now.
In the blog, the author mentions a need for using a "premium plan" for publishing his WP blog to protect it from being taken down by large spikes in traffic. That premium plan changed the economics of his blog, and the plan gets more expensive with time making his content less profitable.
One more is all we're asking for.
But alas this piece is a bunch of cheap symbolism.
Op whatever is on your mind, spit it out and stop the bs.
[0] https://dev.lotw.xyz/shell.os ("help" is your friend!)
You're welcome to participate in the community here, but the way to do that is to post/submit on a variety of intellectually interesting topics, including your own stuff occasionally.
Dr Ray Stantz: You never studied.