<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">16 dec. 2020 kl. 06:49 skrev Asmus Freytag via Unicode <<a href="mailto:unicode@unicode.org" class="">unicode@unicode.org</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">On 12/15/2020 8:19 PM, David Starner
via Unicode wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAMZ=zj6hBhzAgvd7Qx2ZUtAXCRNEdf-RpHxcNL6j1Bzdw+85Nw@mail.gmail.com" class="">
<pre class="moz-quote-pre" wrap="">On Tue, Dec 15, 2020 at 4:47 PM Sławomir Osipiuk via Unicode
<a class="moz-txt-link-rfc2396E" href="mailto:unicode@unicode.org"><unicode@unicode.org></a> wrote:
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">"Implementations of Unicode that already make use of out-of-band
mechanisms for language [or format] tagging or “heavy-weight” in-band
mechanisms such as XML or HTML will continue to do exactly what they
are doing and will ignore the tag characters completely. They may even
prohibit their use to prevent conflicts with the equivalent markup."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">So every single thing that interfaces with HTML now has to handle
Unicode italics on any plain text input, or silently dump them into
the stream, and the web browser may have to handle them or not.
</pre>
</blockquote>
^^^That.</div></div></blockquote><div><br class=""></div>Let me paraphrase:</div><div><br class=""></div><div>”So every single thing that interfaces with HTML now has to handle RTF italics on any plain text input,</div><div>or silently dump them into the stream, and the web browser may have to handle them or not.”</div><div><br class=""></div><div>You would not use that as an argument to say that RTF (which I picked just because it is well-known)</div><div>should be wiped from the face of Earth? I would think not… (You may want to wipe RTF from the face</div><div>of the Earth, I don’t know, but you would not use that argument even if you do want that.)</div><div><br class=""></div><div>Even if, in these threads, the term ”plain text formatting” is used (or worse ”Unicode formatting”), that</div><div>is a bit misleading (of course). I don’t think these proposals should be applied to text data of the ”type”</div><div>’tex/plain” (or as a filename suffix, ”.txt”), nor such things as filenames themselves, and of course not to</div><div>”text/html”/”.html”, nor to ”application/pdf”/”.pdf”, nor to ”application/rtf”/”.rtf”, etc. One should be using (a)</div><div>new file type(s), POSSIBLY (if one can agree on a single one) even apply it to ”text/plain”/”.txt” (but not</div><div>to HTML, RTF, etc., and not (I would say) to filenames or similar, such markup should not even be</div><div>permitted in filenames and similar; note: ”should...”, not ”are...").</div><div><br class=""></div><div>The point being that the markup would be default-ignorable, and thus normally ”invisible” when not</div><div>interpreted, even in a ”plain” text file. Granted, the ECMA-48 approach (if not mapping to TAG</div><div>characters) would need a bit of ”extending” the default-ignorability property to certain follow-on</div><div>characters (that normally are printable) after ESC and CSI (terminal emulators do that all the time,</div><div>and have done so for decades, so it is nothing revolutionary). That is, that the markup does not ”hijack”</div><div>normal printable characters for its markup syntax; if ECMA-48 had been done today I think it would use</div><div>default-ignorable characters through-out the ESC- and CSI-sequences, not just for the lead character.</div><div>(Plus, I think that no use of out-of-band stylesheets is also a point. Plus that some argue for excessive</div><div>”bare-boned-ness”; but I don’t agree with that.)</div><div><br class=""></div><div>That is my take on this issue at least.</div><div><br class="">----<br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">hardcoding </p><p class="">
visual appearance is really the least helpful, because that
totally<br class="">
undercuts the the ability for style sheets to address
presentation.<br class="">
</p>
</div></div></blockquote></div>Yes, but… Re. ECMA-48 (which we touched on in this thread), there the styling is really<div class="">”hardcoded”, and there are no style sheets. For ECMA-48 (which is still very much in use,</div><div class="">and extensions are being implemented). I don’t think it would be a good idea to introduce</div><div class="">any (separate) style sheets of any kind. It is not at all geared for that, and re-gearing it for</div><div class="">that would not be a good idea to do (IMHO). Similarly for any ”plain text” (”low level”, really)</div><div class="">formatting proposal other than ECMA-48. But for HTML and similar, fine; stylesheets are great!<div class=""><br class=""></div><div class="">/Kent Karlsson</div></div><div class=""><br class=""></div></body></html>