Relative times are nice for recent times (e.g. "5 minutes ago" is better than "2025-12-18 13:03"), but they should "decay" into absolute times for anything that isn't fairly recent - like a week or two, perhaps.
It varies by use case. I can think about e.g. an SRS flash card where you next review is in 2 years. I honestly don‘t care if 2 years here means 21 months or 28 months, and I especially don‘t care if the next review is on 21st of February 2028 at 13:52. All I want to know is that the next review is so far in the future it may not actually happen.
That's a fair point. I'm thinking of the use case of formatting a past date on something like a social media post/comment. (For example, a comment on HN - which uses a rather long cutoff for relative dates.)
I don't like just saying "read the article", but this is precisely what the article explains. In short: the rental rates are a condition of the property owner's loan.
Not one of the downvotes, but: as far as I'm aware, there was never any syntax which could be used for HTML transclusion in the browser. There may have been SGML or XML syntaxes proposed for it, but none of them were actually implemented in this context.
You can use entities to create static sites in advance, or by including support in the browser. sgmljs can do both, and simply using shared headers/footers for static site generation from markdown and other SGML partials is explained in [1].
SP/OpenSP and older SGML tools were most certainly available and used to assemble HTML docs from command line apps in the 1990s for complex websites with lots of content such as software documentation. The editor of the HyTime spec with its strong focus on adapting and transforming to multimedia and web was working with a training/education company. W3C's long-term validator service ran off SP.
XSLT was implemented in every browser like 25 years ago and has the ability to include other document templates/fragments client-side. It's exactly the functionality everyone always says is missing.
> With Korean, it looks more jarring, as the input method is apparently very different, and seems to map the keys for unrelated latin letters to Hangul letters?
More or less, yes. Each Hangul character represents a syllable, and is composed of two or more components (jamo) representing individual phonemes (like vowels or consonants) which make up the syllable. The keys on a Korean keyboard are mapped to those jamo.
More specifically, since Korean syllables are of the form CV(C) where C is a consonant and V is a vowel, almost all Hangul keyboard layouts divide the entire keyboard into two or three sections (consonant-vowel or initial-medial-final). The standard KS X 5002 layout is the former, a "bipartite" method (두벌식), while I'm using one of the latter, "tripartite" methods (세벌식).
I don't think you mean "monospaced". Monospaced fonts (where every character cell has the same width, like an old typewriter) are almost never used for normal text in Latin scripts.
And just in case it wasn't clear enough already: one of the first acts of the Confederacy was to draft a provisional constitution which explicitly authorized slavery, and which prohibited either Congress or any state from passing laws to the contrary.
The individual prevented future killings by that individual. Flock didn't prevent anything; at most, they helped find his body.
reply