From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Garreau\, Alexandre" Subject: *markup*, /markup/ and _markup_ true semantics [Was: Re: Ox-html: Replace with and with ] Date: Fri, 26 Oct 2018 07:24:00 +0200 Message-ID: <87a7n1i8lr.fsf_-_@portable.galex-713.eu> References: <87r2gfyj62.fsf@nicolasgoaziou.fr> <87in1rkqlk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFuf6-0003BP-AE for emacs-orgmode@gnu.org; Fri, 26 Oct 2018 01:27:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFubN-00083o-Sa for emacs-orgmode@gnu.org; Fri, 26 Oct 2018 01:24:07 -0400 Received: from portable.galex-713.eu ([2a00:5884:8305::1]:48316) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gFubN-00082z-H6 for emacs-orgmode@gnu.org; Fri, 26 Oct 2018 01:24:05 -0400 In-Reply-To: <87in1rkqlk.fsf@gmail.com> (Tim Cross's message of "Thu, 25 Oct 2018 08:00:07 +1100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Tim Cross Cc: emacs-org list , Kaushal Modi Sorry, just found out that interesting (to me) thread I shouldn=E2=80=99t h= ave let go: On 2018-10-25 at 08:00, Tim Cross wrote: > Kaushal Modi writes: >> [=E2=80=A6] >> - b and i are not deprecated >> - b and strong are both valid but their use depends on the writer's >> context (but Org mode has just one mark for either "*") >> - i and em are both valid but their use depends on the writer's >> context (but Org mode has just one mark for either "/"). >> >> [=E2=80=A6] >>=20 >> From "em" docs[em], in the NOTE section there: >>> The em element isn=E2=80=99t a generic "italics" element. Sometimes, te= xt >>> is intended to stand out from the rest of the paragraph, as if it >>> was in a different mood or voice. For this, the i element is more >>> appropriate. >> >> [=E2=80=A6] >> >> I guess there's no need to change what "*" and "/" do right now in >> ox-html, as there doesn't seem "one right way" to do things here. >> >> And folks strongly wanting to use and for bold and >> italic can customize org-html-text-markup-alist. >> >> HTML experts, please chime in. > > I'll start by stating I'm definitely not an HTML expert. I don=E2=80=99t exactely know what an expert is, at least I=E2=80=99m not a professional, but I have passed some time figuring out various HTML specs semantic meaning. More especially, I=E2=80=99ve a big interest in semantics and typography, a= nd past many time on my now deleted-crecreated-then-lost github account, and mail, to convince people to switch to more semantical markuping (oh, and to use complex CSS selectors rather than classes, and stop using
and at all) and better typography (such as curly quotes, simple quotes inside quotes, and many things specific to french). > The problem with b and i is that they specify how rather than what and > don't always make sense for all possible media types. For example, what > does 'bold' or 'italic' mean for a screen reader? Italic means often pronounced with a different pitch afair. Bold probably means prounced differently too but I don=E2=80=99t know how this is pronounced iirc. I need to recheck with orca and firefox addons (I=E2=80= =99ll do for a next mail). That might be change accross screenreaders so I might have to find some friend having a windows computer with NVDA, JAWS or some other non-free program to either ask or check. I believe the most correct handling for screen readers would be to use the appropriate language from the attribute lang or xml:lang of tag, otherwise slower and slightly higher pitch, and for the exact same higher pitch as caps, without changing speed, plus adding it to an easily reachable =E2=80=9Ckeyword-list=E2=80=9D, just as . Fyi=C2=A0: both italic, bold, and underline, have been invented in typograp= hy as special ways of *purposely* making text harder to read. Both the intent and result is that the reader taking more time to read something in italic, for instance, will memorize it better, and have more free time to think about it, hence increasing the importance of this something. In the following =E2=80=9Cfrom far=E2=80=9D means when you look at the glob= al document and are not focusing reading a particular part of it. It doesn=E2=80=99t m= ean you are at a far distance and you can still read it, like it is for uppercase. Italic is the best way, the most readable, as it=E2=80=99s only seen when reading, near the text, but not =E2=80=9Cfrom far=E2=80=9D and doesn=E2=80= =99t break structure, flowing, or =E2=80=9Ctypographic grey=E2=80=9D (=E2=80=9Cgris typographique= =E2=80=9D, I=E2=80=99m not aware of the english term). It is hence commonly used for emphasis (best usage: if ever it gets long, it gets hard to read, but that reflects the fact original meaning was hard to grasp or hear or say originally), citation of artistical work names (such as books: conventional usage, but still okay, as these are mostly short anyway), and quotations (discouraged usage as they can get long (and thus unreadable) and quote marks cover this, *not* to be used *along* with them, never, as it is terribly redundant and almost no serious professional printer do that). Bold is sometimes harder to read, and sometimes, if not too bold, easier, however it=E2=80=99s really easy to =E2=80=9Cnotice=E2=80=9D its te= xt from looking afar: therefore it=E2=80=99s normally *exclusively* recommanded for text structur= es, whose *role* is to purposely cut in parts the text, that is: *outlines*. However, in an attempt of pseudo-backward compatibility and =E2=80=9Cbut lo= ok everybody was okay since the beginning=E2=80=9D, by the W3C, another usage = for bold than in outlines has been found: keywords. These are *meant* to be seen from far, are usually small (one word), and yet wouldn=E2=80=99t alter= text structure, and might not be candidate for (however most time they should). Underline is to be banned from everywhere, theorically. It is an especially simple and awful way of making text unreadable: it cuts the legs of non-zero-ascent letters (making as hard to read as italic) *and* is easy to lookup from far, yet you can notice the underline without having the word easily and quickly grasped when seen from far, like bold. Iirc it has been invented for typewriters because italic wasn=E2=80= =99t available, for which it is the poorest candidate ever. It is also used in manuscript text, as people actually trying to manually write in italics or bold are nowadays few and others are often unable to do so. Most time I saw it used manuscriptly to anotate and highlight text. Conventions has been developed around this: in typewriter as well as manuscript text, you normally *only* use it for artistic works names (instead of italic), and blue hyperlinks. It is sad it has developed as a such important convention but it is done, clear, and well established. The W3C meaning of =E2=80=9Cadded text=E2=80=9D seems quite somewhat artifi= cial to me, as it is not more conventional to use it for =E2=80=9Cadded changes=E2=80= =9D than any other typographic convention. However it is necessarily *one of these*, as it is commonly used to highlight and anotate text (however the tag is here for that, in HTML). > I do believe we should move away from b/i to strong/em as I think these > are the correct semantic tags to use and are generally what is > preferred. This means they are also likely to already have appropriate > 'styling' in many 'canned' styles and valid consistent interpretations > for different media types.=20 This is unsemantic (and is giving org markup a presentational rather than semantic role, so I strongly oppose this) and could break true accessibility. I=E2=80=99d say ideally what we should have is more markup = to be compatible with HTML, as recently, with XHTML1, 2 and HTML5, it has become one of the richer and most clearly defined markup language available. However as org, comparably to markdown and rst, is trying to achieve some compatibility with classical clear-text markuping, such as in email, and from what semantics I detected, I=E2=80=99d say the following= =C2=A0: =E2=80=93=C2=A0tag =E2=80=9C*=E2=80=9D with , maybe find cases where = =E2=80=9C=E2=80=9D might be appropriate (for keywords, typically): I=E2=80=99d say an interesting experiment woul= d, for some given languages (such as english, to begin) detect if an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D, =E2=80=9Can=E2=80=9D= =E2=80=A6) is part of the markup: then it=E2=80=99s not a keyword (hence ), if it=E2=80=99s *preceding* the markup, then more probably it is a markup (but not necessarily)=C2=A0; =E2=80=94=C2=A0tag =E2=80=9C/=E2=80=9D with , as this match the most = accurate and commonly meaning of =E2=80=9C/=E2=80=9D, =E2=80=9C_=E2=80=9D might be appropriate = as well, but may be redundant (so a safe (potentially usable as buffer-local) custom var would do better). However there are some cases where =E2=80=9C/=E2=80=9D would be= more appropriate as (I=E2=80=99d say the vast majority of occurences are w= ords from foreign languages, other are most often incorrect and abusive usage of =E2=80=9C/=E2=80=9D); =E2=80=94=C2=A0tag =E2=80=9C_=E2=80=9D as either , if correct var is = of the correct value, or , *only* if near =E2=80=9C+=E2=80=9D markup. Otherwise, as org only= use =E2=80=9C[]=E2=80=9D for hyperlinks, I don=E2=80=99t know. Note that, indeed, =E2=80=9C=E2=80=9D has no usage. If it was up t= o me it should be banned. Maybe its most accurate usage would be for upcase urgent emphasis-text: *URGENT: READ THIS NOW OR YOU WILL DIE* (you might use if absolutely wanting to, for upcase emphasis text, or emphasis text containing =E2=80=9Curgent:=E2=80=9D or =E2=80=9Cimportant:= =E2=80=9D, and differently localized versions (format-level linguistic imperialism, bla bla: note for the same very reason this would work as is for french, but me and many people would funnily feel more reassured, respected or whatever if they were blessed by being in a list whose car is "fr")). > I don't think this is something that is urgent, but it is the > direction we should go. The only real reason for sooner rather than > later is that we can probably simplify some of the exporters and > ensure any new exporters are correct and won't need to be change > retrospectively. This has to be a semantics work to be reported on *all* semantic backends. As there are =E2=80=9Caccessibility=E2=80=9D workaround for almo= st all formats (even PDF, which is understandable as it got important and widely used, while normally meant only for printing, hence display, not semantics (but you know, these days, you can put javascript in these=E2=80= =A6)), this may mean =E2=80=9Cevery backend=E2=80=9D.