2 ms·

Attaching style to each glyph is problematic too, since now they can get spread around unintentionally, and we'll need new regexp code, and much else. No, the

Attaching style to each glyph is problematic too, since now they can get spread around unintentionally, and we'll need new regexp code, and much else. No, the semantics of tagging inside Unicode are uniformly bad. I understand that people abuse Unicode already to get some such effects, but it's mostly a novelty, and I would not seriously use any software making use of these tricks. A standard way to mark up style in Unicode would certainly be better than Unicode abuse, but it would still come with a bunch of difficult associated issues -- are they really better than whatever issues you have with XML? and are they better for all of us?? BTW, games with BS (backspace) and overstrike for bold and underscore for underline still work in Unix terminals... That might be the best argument for having some stylistic composing codepoints in Unicode... after all, ASCII was designed in part to be usable with BS for expressing diacritical marks (accents, umlauts, cedilles, ...), making it a variable length internationalized encoding! But still, then less we complicate Unicode, the better.

derefr 8y ago
I think you misread my original post—I don't have any problems with XML, and in a sibling post (https://news.ycombinator.com/item?id=18611384 https://news.ycombinator.com/item?id=18611384), outlined exactly why XHTML is best-suited to this use-case. Meanwhile, I called this Unicode-markup idea a "modest proposal". If you can use XML, by all means, please do use it. If you're designing a document format, and there should be markup in your document, just use XML for your document format and then XHTML for the markup parts. It's what ePub does. (ePub is one of my favourite formats: it's just a slapping-together of a bunch of well-known technologies. It's the "buy rather than build" of document formats.) I do think, though—separately from what your options are as a document-format designer—that there's a point in having a Unicode-level markup standard, and getting the font-rendering engines on board with it. And that point is democratization of styling control: forcing styling into places where the format specifier had no intention, way back whenever they specified the format, to add styling; and where the software stack has maybe ossified since, such that nobody's willing to introduce a new version that specifies a new format with styling (or where such an effort was tried but has long fizzled out.) Want to add styling to email? No, not HTML email, pine(1) ain't ever gonna render that for you. I mean, all email. Email in an app in the GUI; email on the CLI in your terminal emulator. Email even in pine(1), without modifying pine(1), merely updating GTK and Cairo and then restarting gnome-terminal. Unicode markup would work entirely opaquely to the email client's intent to "have styling" or not. At the layer the email client is operating at, it's Just Text™, just like emoji are now Just Text™. As far as I can tell, encoding the styling at the Unicode-codepoint layer, and then parsing it out at the {OS graphics toolkit, terminal emulator} text-rendering layer, is the only way to make that work. Or, for another example. How about we insert some bold text into a TEXT-typed column of a Postgres DB row? Yes, the text is supposed to be bold. No, we can't change the type of the field to XML; that would break everything that currently queries that field. I want to just put bold text in one row, one time. Yes, sure, add an INSERT trigger to ensure that nobody can insert text with any other styles. (But if you're so worried about that, why don't you have that trigger already to ensure that nobody's inserting a newline, huh?) A cute trick: make temp-file filenames not "foo~" but rather "foo"-with-a-strikeout-through-it. Yes, that'd be the file's actual on-disk name. You're saying you want your filesystem to use XML for the filename field? (I mean, these are ridiculous, yes. The only actual use-case is obviously allowing people to use bold on HN.)

derefr 8y ago

I think you misread my original post—I don't have any problems with XML, and in a sibling post (https://news.ycombinator.com/item?id=18611384 https://news.ycombinator.com/item?id=18611384), outlined exactly why XHTML is best-suited to this use-case. Meanwhile, I called this Unicode-markup idea a "modest proposal". If you can use XML, by all means, please do use it. If you're designing a document format, and there should be markup in your document, just use XML for your document format and then XHTML for the markup parts. It's what ePub does. (ePub is one of my favourite formats: it's just a slapping-together of a bunch of well-known technologies. It's the "buy rather than build" of document formats.) I do think, though—separately from what your options are as a document-format designer—that there's a point in having a Unicode-level markup standard, and getting the font-rendering engines on board with it. And that point is democratization of styling control: forcing styling into places where the format specifier had no intention, way back whenever they specified the format, to add styling; and where the software stack has maybe ossified since, such that nobody's willing to introduce a new version that specifies a new format with styling (or where such an effort was tried but has long fizzled out.) Want to add styling to email? No, not HTML email, pine(1) ain't ever gonna render that for you. I mean, all email. Email in an app in the GUI; email on the CLI in your terminal emulator. Email even in pine(1), without modifying pine(1), merely updating GTK and Cairo and then restarting gnome-terminal. Unicode markup would work entirely opaquely to the email client's intent to "have styling" or not. At the layer the email client is operating at, it's Just Text™, just like emoji are now Just Text™. As far as I can tell, encoding the styling at the Unicode-codepoint layer, and then parsing it out at the {OS graphics toolkit, terminal emulator} text-rendering layer, is the only way to make that work. Or, for another example. How about we insert some bold text into a TEXT-typed column of a Postgres DB row? Yes, the text is supposed to be bold. No, we can't change the type of the field to XML; that would break everything that currently queries that field. I want to just put bold text in one row, one time. Yes, sure, add an INSERT trigger to ensure that nobody can insert text with any other styles. (But if you're so worried about that, why don't you have that trigger already to ensure that nobody's inserting a newline, huh?) A cute trick: make temp-file filenames not "foo~" but rather "foo"-with-a-strikeout-through-it. Yes, that'd be the file's actual on-disk name. You're saying you want your filesystem to use XML for the filename field? (I mean, these are ridiculous, yes. The only actual use-case is obviously allowing people to use bold on HN.)