It’s inappropriate for data. It’s basically text layout and controls, no matter how many DIVs you put.

JSON (which has its own problems) would be a more appropriate format.

This could be partially fixed by promoting "data" to be a new general HTML word:

<DATA type=application/foobar encoding=base64> .... </>

which could include application/json, application/epub+zip, application/pdf, whatever. If the browser knew how to handle it natively, great; if it knows how to invoke a helper for that, good; if nothing else a link appears to save it as an individual file.

If you give a DATA entity a name tag, you can use it inside the same page anywhere a suitable use occurs:

<DATA name=parrot.jpg type=image/jpeg encoding=base64> ... </DATA>

<IMG SRC=#parrot.jpg>

Best if you make all the attributes of the original tag follow along, so:

<DATA name=#parrot.jpg alt="Parrot Rights Now!">...</>

Why would you embed an image file, instead of just link to it? That’s not the problem at all.

The problem is just simply knowing that “1935” is a number, and a date. Microformats somewhat address this, but it has limited uptake.

But relying on people to tag stuff correctly, isn’t going to work. Just look at the mess that META tags are, especially those outside of share card population. I’m not talking about reading the spec. I’m talking about seeing how they’re actually used. People can’t even get “tags” right, let alone “author” or “date”

Very true. We feel like this is an area where better tools can help. I hesitate to use the term "AI" because I don't think artificial intelligence is real. But I do believe that tools can be designed to act more intelligently, including identifying the source and context of our writing without us explicitly having to take a hand in it.

Not just an image file. A spreadsheet. A database extract. A genealogical record.

The tagging problem is constant across all formats.

Type theory.

> It’s basically text layout and controls, no matter how many DIVs you put.

Except...it's not. Current HTML is mostly (entirely, in principle, but there are a couple holdout tags where that is strained) semantic rather than presentational, and there's very little layout-related in it (except insofar as all tags have overridable default presentation, and some of that is layout-related.)

“In principle” is meaningless. Even the semantic tags that do exist are ineffective, as they aren’t used in practice (see TIME), completely ill defined (see CITE), or correspond to common use cases.

In practice — and that’s all that really matters — what you get are a mass of DIVs and SPANs where if there is any semantic information, it exists in the open vocabulary of CSS style classes.

https://www.w3.org/TR/html52/textlevel-semantics.html#elemen...

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ci...

It was not meant for data - it is a presentation tool. It is the result of consuming data, not the data itself. For that purpose it's not ugly and it fits its purpose. No idea why my comment was downvoted...

Some people seem to think downvoting is for everything you don't agree with. Well, I don't agree with that, lol!

You are right, but HTML is a descendant of SGML which IBM invented specifically to make sure that data and formatting were represented separately. It was both a representation and presentation tool. Unfortunately, SGML hatched XML for data representation and HTML for presentation and never the twain shall meet.

While Mimix will ship with an HTML-based user interface, the underlying structure of data in Mimix is not HMTL (or XML) but MSL, the Mimix Stream Language, a domain-specific language designed to describe writing. Owing to the open source nature of our product, we expect that the community will write new MSL engines with different interfaces and this is one of the most exciting aspects of the work.