Sibylla Bostoniensis

Canonical link: https://siderea.dreamwidth.org/1819759.html

Over on Mastodon, I had made the comment "CSS will always be hamstrung by HTML's toxic content/appearance paradigm", to which someone else reasonably enough asked me,

What do you mean by "toxic content/appearance paradigm"? Do you think the separation of content from appearance is a bad idea, or that HTML/CSS doesn't do it well, or something else?

I suspect he never expected quite this much answer. I start with a single HTML tag and end with the downfall of civilization.

Not joking.

What follows is my reply, edited and a bit further developed.

---

Several things:

1) To a first approximation, I think the separation of content from appearance is a fine idea.

2) Which is to say, to a second approximation, I think it's terrible: I have an inchoate intuition that content vs appearance is a bad paradigm because it is an attempt to shoehorn a triad into a false dichotomy, and the real correct solution is separation of content vs appearance vs a third thing, maybe "functionality".

3) But that aside, and for the moment CSS aside as well, HTML's separation of content and appearance is catastrophically bad. It is predicated on fundamentally mistaken ideas as to what is content and what is not.

I have one particular favorite hobby horse example of this, which really captures how apparently trivial errors can have far-reaching consequences.

That example is the Ordered List (<ol>).

HTML's Ordered List is not a ordered list. Instead of implementing Ordered List correctly, HTML gave us an dynamic automatically numbered list, instead, and called it an ordered list.

This is self-evidently insane. It is predicated on a fundamental misunderstanding of why human beings assign numbers to things such as list items. The chief reason humans assign ordinal numbers to list items is to be able to refer to those list items by number. Consequently, while it's fine if a document generator auto assigns numbers to list items, as a convenience to the document drafter, once the document is "published", the assignment of number to list items must be stable.

This is because the ordinal numbers of list items in an ordered list are content not presentation.

The W3C spent literal decades dying on the hill that the ordinal numbers of the items in an ordered list are not content, only presentation.

It caved enough to allow the start number attribute, which - get this - it deprecated in HTML4, and then, in HTML5 (officially released in 2014) it un-deprecated, with the note that the numbers assigned list items in an ordered list are, in fact, content not presentation.

It was nice of them to unbend that much, but OL still fundamentally treats the numbers assigned list items as presentation, not content. Which is to say: it is still hot garbage.

Two things remain to me to explain: what OL would look like if it were implemented correctly, and what the consequences were because it was implemented incorrectly.

I want to do the second of those first.

There is one particular type of document in which the correct handling of the ordinal numbers of lists is paramount. A document type in which the ordinal numbers of the lists cannot be arbitrarily assigned by computer, dynamically, and in which the ordinal numbers of the lists are some of the most important content in the document.

I'm referring of course to law.

HTML, famously, was developed to represent scientific research papers, particularly physics papers. It should come as no surprise that it imagines documents to have things like headings and titles, but fails to imagine documents to have things like numbered clauses, the ordinal numbers of which were assigned by, for example, an act of the Congress of the United States of America.

Of course this is not specific to any one body of law - pretty much all law is structured as nested ordered lists where the ordinal numbers are assigned by government body.

It is just as true for every state in the Union, every country, every province, every municipality, every geopolitical subdivision in the world.

HTML, from the first version right up to the present version, is fundamentally inimical to being used for marking up and serving legal codes as web pages. It can be done, of course - but you have to fight the HTML every step of the way. You have no access to any semantic markup for the task, because the only semantic markup for ordered lists is OL, which treats the ordinal numbers of ordered lists as presentation not content.

If you want the presentation of ordered lists - nested indentations, properly hanging leading ordinal numbers, ordinal numbers decorated in a different font style or weight, etc - you get to reconstitute it all by hand, lovingly reinventing the wheel with spans and divs and CSS classes.

With that explained, it becomes extremely obvious with the right solution is for how HTML should handle ordered lists. The HTML should look very similar to that for definition lists (DL):

<ol>
<oln>(b)</oln>
<oli>No employer shall discriminate in any way on the basis of gender in the payment of wages, or pay any person in its employ a salary or wage rate less than the rates paid to its employees of a different gender for comparable work; [...]</oli>
</ol>

It is no longer the job of the browser to assign numbers to list items, but to style them with a sensible default for such things, unless the an alternative style is provided by either the document preparer or the end user.

But the fact that HTML's Ordered Lists are but misnamed dynamic auto-numbered lists is only one problem with them; there's another problem following from the insane decision to consider the ordinal item numbers of Ordered Lists "presentation" instead of "content".

In the browser, copy and paste does not work on what HTML relegates to "presentation".

You can only copy and paste the content of a webpage.

So one of the functional consequences of HTML treating the ordinal numbers of ordered lists as presentation not content is that the user can't cut and paste them from the browser window.

When a user tries to copy and paste from an ordered list in an HTML page, the ordinal numbers assigned by the OL tag are not included – the numbers are left behind. What the user winds up pasting into the target document is the copied list items – without their numbers!

It seems self-evidently wild to me that any characters in a text document, such as an HTML document, would ever be considered "presentation", and not content, since they're, you know, characters in a text document signifying information. It is a massive violation of user expectations. But that is exactly what the W3C did with Ordered Lists.

In this way, OL tag renders anything marked up with it effectively not copy-and-pastable. You can use copy and paste on it, it just leaves out the citations. So if you were some sort of student or scholar trying to study the law, or if you are trying to write an article about it, your attempts to quote from HTML document in which laws been marked up with OL tag will be largely thwarted: you'll have to go in and manually reassign all of the item numbers, which in turn invites the perennial data hygiene problems of manual data entry.

There is another problem, too. There is no way to have the OL tag skip a number. You can't really use the OL tag to mark up any ordered list in which the items skip a number or multiple numbers. That, it turns out, is important.

One reason it's important, is that in real life sometimes the original legal document just skipped numbers for some reason. This happens in legal codes. Sometimes somebody made a mistake enumerating the laws – and now it is what it is. Sometimes they skip numbers to leave them available for future use. Sometimes there used to be a law there but that clause was repealed. But regardless of how it got that way, if you want to accurately represent those texts in HTML, you need to be able to skip ordinal values when marking them up.

The other reason has to do with quoting passages from the law. As someone who writes about the intersections of healthcare and the law, this comes up for me all the damn time. I often am writing documents where I want to quote some passages from legislation, and the issue is, when you're quoting legal code, you often do not want to quote all of it – just the parts that are relevant to what you're discussing.

Here's a beautiful real-world example. From my post of 2015 Dec 20, "HIPAA and Private Pay":

(a)
(1) Standard: Right of an individual to request restriction of uses and disclosures.

(i) A covered entity must permit an individual to request that the covered entity restrict:

(A) Uses or disclosures of protected health information about the individual to carry out treatment, payment, or health care operations; and
(B) Disclosures permitted under§ 164.510(b).

(ii) Except as provided in paragraph (a)(1)(vi) of this section, a covered entity is not required to agree to a restriction.

[...iii: if you do agree, you have to keep your promise, except in emergencies...]

(vi) A covered entity must agree to the request of an individual to restrict disclosure of protected health information about the individual to a health plan if:

(A) The disclosure is for the purpose of carrying out payment or health care operations and is not otherwise required by law; and
(B) The protected health information pertains solely to a health care item or service for which the individual, or person other than the health plan on behalf of the individual, has paid the covered entity in full.

Notice how right in the middle, I elide sections a.1.iii through a.1.v, because they're not pertinent to what I'm writing about. I formatted this – you're welcome to use View Source to see yourself – by means of the creative deployment of non-semantic DIV tags with STYLE attributes. It is simply not possible to mark up something like this using OL tag, despite it being an ordered list.

(As a side note, the original from which I'm quoting, the Cornell Law School Legal Information Institute website, uses styled P tags with a different style for each depth of indentation, and SPAN tags that are apparently dynamically generated by the application layer, aeb them having unique names that match the value of the ordinal number, to style the list numbers separately from the list entry.)

Of course, these problems with OL are not only an issue for representing the law in HTML; there are many other sorts of similar documents that run into exactly the same problem.

I first ran into this problem trying to mark up some office policy documents to put in the office wiki. In addition to being a problem for the law itself, another type of document with numbered clauses are legal decisions - those documents created by judges to record their judgments. It shows up in the numbering of scripture of holy texts, and in the academic documents concerning the analysis or history of literature such as poetry with numbered lines or passages.

It turns out there's a lot of things in the world where people number things in lists and feel very strongly that those numbers should be stable. Things people might very much want to put into HTML and put up on websites. Things, arguably, of enormous public value.

So when I say that HTML has a catastrophically bad notion of what is content and what is presentation, I believe I get to. I don't think that's overstatement at all. HTML by this one apparently trivial failure introduced enormous impedance into the publishing on the web of documents of some of the utmost public value. It turned the web publishing of documents dependent on a structure of nested ordered lists, such as legal codes, into something expensive, tedious, and time-consuming. It made it such that the HTML markup of legal codes and other similarly structured documents was something only the wealthiest of governments and organizations could afford.

To this day, law, policy, and similar documents are published in PDF format. Because it is relatively easy and straightforward to typeset nested ordered lists in a word processor. And to maintain it in word processor.

And I propose this has consequences. I propose it has consequences to democracy how available to the public are their laws, their policies, their judicial decisions, their holy texts, and even their academic papers about literature.

The W3C spent decades insisting in utter folly that they were right in their conception of how ordered lists work, in the face of the whole world, and in doing so they frustrated the transparency on which democracy rests.

And not just transparency: by this one apparently trivial failure of a single HTML tag's specification, the W3C made it difficult – and for those not quite adept at HTML, frankly impossible – to quote from or to discuss documents that are organized in structures of nested ordered lists, such as legal codes, in any of the places of modern discourse: in blog posts, in discussion forums, on wikis, in news articles on news websites, in scholarly journals published online – in all the places where HTML is used, or any mark-up system that has to compile down to HTML, such as Markdown or BBCode or Wikicode.

That, too, I propose has consequences. I propose it has consequences to democracy how able the public are to cite and to discuss their laws and bills, their policies, judicial decisions, their holy texts, and, yes, even their academic papers about literature.

Am I blaming the rise of fascism and the downfall of Western civilization on the W3C's pig-headed and flawed implementation of the OL tag in HTML?

A little, yes.

I mean, "with friends like these, who needs enemies?"

HTML did science well and law poorly. Today, we have a vibrant and fierce movement to liberate scientific research from paywalled journals, but nobody much cares how much access the public has to the documents that literally rule their lives.

I don't think that's coincidence.

So that's the OL tag. Unsurprisingly, given how profoundly misguided and wrong the W3C was on that, the rest of HTML is shot through with similar mistakes as to what constitutes content versus what constitutes presentation.

---

Subsequently posting that, conversation ensued that revealed I needed to be more clear about the following point: the problem is when the browser is entrusted with auto-enumerating list items. If you want to implement auto-enumerating for list items in the IDE or a CMS's edit window, as a convenience function to the person who is drafting the document, just long as it can be overridden and/or turned off that's fine. It's the idea of encoding auto-enumeration – at the expense of non-auto enumerated ordered lists – in HTML that's world-threatening. By the time the HTML is squirted out to the browser along a beam of HTTP, the numbers of ordered list items need to be carved in stone. If you want ordered list items to be auto enumerated by the browser, that's what JavaScript is for, and if the W3C adopted my proposed semantic mark up above, it wouldn't even be hard to implement because it would be properly semantic.

As someone noted, all of this gestures toward the utility of something like user macros in HTML. That's the topic for another day – or maybe two topics – but, yes. I think there's a missing abstraction layer in the web technologies stack. There was very brief time in history when that was how Netscape, at least, envisioned how JavaScript would be used with HTML, aeb HTML entity variables, which IIRC they dropped support for somewhere around Netscape 3.0. But adding user empowering convenience functions to HTML needs to come after the saving democracy through the fixing of its semantics.

---

This post brought to you by the 161 readers who funded my writing it – thank you all so much! You can see who they are at my Patreon page. If you're not one of them, and would be willing to chip in so I can write more things like this, please do so there.

Please leave comments on the Comment Catcher comment, instead of the main body of the post – unless you are commenting to get a copy of the post sent to you in email through the notification system, then go ahead and comment on it directly. Thanks!