From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross Subject: Re: *markup*, /markup/ and _markup_ true semantics [Was: Re: Ox-html: Replace with and with ] Date: Mon, 29 Oct 2018 08:19:24 +1100 Message-ID: <87h8h5ixb7.fsf@gmail.com> References: <87r2gfyj62.fsf@nicolasgoaziou.fr> <87in1rkqlk.fsf@gmail.com> <87a7n1i8lr.fsf_-_@portable.galex-713.eu> <87ftwslb19.fsf@gmail.com> <875zxn362y.fsf@portable.galex-713.eu> 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]:59897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGsT8-0004YP-Ar for emacs-orgmode@gnu.org; Sun, 28 Oct 2018 17:19:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGsT5-0003qq-4e for emacs-orgmode@gnu.org; Sun, 28 Oct 2018 17:19:34 -0400 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]:43293) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gGsT4-0003pR-8d for emacs-orgmode@gnu.org; Sun, 28 Oct 2018 17:19:30 -0400 Received: by mail-pf1-x436.google.com with SMTP id h4-v6so2966273pfi.10 for ; Sun, 28 Oct 2018 14:19:29 -0700 (PDT) In-reply-to: <875zxn362y.fsf@portable.galex-713.eu> 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: "Garreau, Alexandre" Cc: emacs-org list , Kaushal Modi On reading your response, we are probably not as far apart as I first thought. However, we have now wondered into discussion which probably isn't appropriate for this list. It is now in the realms of something that would probably be better discussed with a good bottle of red or a nice cold beer! There is lots that is 'broken' with the web and I suspect much of it we will just have to live with and hope whatever the next evolution brings us learns from our mistakes. Tim Garreau, Alexandre writes: > On 2018/10/27 at 07:15, Tim Cross wrote: >> I have either misunderstood most of your position or I simply disagree >> with it - I'm not sure which. > > maybe a mix of both? I hope it=E2=80=99s a misunderstandnment but if it= =E2=80=99s not I > want to understand too so to get to a constructive agreement. > >> - Much of what you argue seems to be based around ideas associated with >> typography. IMO this is where things fall down. Typography is really >> only relevant to 'printing' (either on paper or screen). Markup is not >> just about printing - it is about conveying what the author wanted and > > Indeed. But many people do not abstract what they mean to write and > still (often, poorly) think in terms of =E2=80=9Citalic=E2=80=9D and =E2= =80=9Cbold=E2=80=9D (the org > manual, as you later said, even do so). What I wanted to underline is > that both =E2=80=9Citalic=E2=80=9D and =E2=80=9Cbold=E2=80=9D (and underl= ine too somewhat) are not just > arbitrary display-level caracteristic that had the particularity to > later get a meaning: *first* a *meaning* was wanted, and *then* they > were invented as an imperfect, more or less good, way to translate these > meanings or their intents to display (it=E2=80=99s as imperfect as a bitm= ap or > handwriting of a circle, or a sampled and compressed audio, is to the > bezier curve or equation of a circle which resulted in it, or the > function that produced the audio (such as a LilyPond musical partition > or a resulting MIDI file)). > > I=E2=80=99m willing to extract as much of the original meaning (be it abo= ut > attention, memorization, structuration, etc. (very abstract cognitive > human features are still more common than visual-recognition features)) > so it can be then better applied everywhere, without the burden and > constraints of the original media (display), with a little of history > because I like to rehistoricize things into their material and social > background, so not to see them as a static, ahistoric, uncreated, > uncriticizable, concept. Concepts and tools are made for people to > serve them, not the opposite. > >> how that is best interpreted will depend on the media being used >> (i.e. how the content is 'rendered') and should largely be up to the >> consumer.=20 > > Yes totally, this is why I believe we, at best, should try to give clear > and defined meaning to why do we use *, / and _-tags, rather than just > translating them to the traditional , , and tags, that > were actually just a poor 1-to-1 wrapping to the old , and > tags, which had no meaning, and still have confused, complex and not > backward-compatible meaning. > > And why sometimes it might be better to set up user options, so if > authors disagree with what is meant by their tags, they can change it, > so in the end that gives the correct semantic markup and everybody will > get the same, intended, meaning. > > Also why, ideally, for the web, I wished server-side CSS never existed > and we only used it as a user-customization language (but still most > websites have poor semantic tagging, and complex tags composition have > still no clear defined meaning so it the end it becomes either guessing, > either a request to add yet-another tag to the already complex HTML > spec). > >> - I am a screen reader user. While you are correct that pitch, tone, >> speed and different voices are often used to convey things like 'bold' >> or 'italic', there is no universally accepted rule for this >> interpretation, at least not in the same sense as there is with >> typography. > > I know, that=E2=80=99s why I wanted to check with Orca, NVDA, and maybe J= aws too > if I could. > >> We all know what bold or italic looks like, but there is no >> agreement as to what these should sound like. When you use Jaws, you >> will get a different result from when you use Orca or Emacspeak or >> Window Eyes or .... However, this shouldn't really matter - how >> these are 'rendered' should ideally be under the control of the >> individual consuming the content. When I consume a document, it >> should be my decision as to how the content is presented and for me, >> interpreting 'strong' or 'emphasis' seems to be far clearer than >> 'bold' or 'italic'. > > That=E2=80=99s why I=E2=80=99d like * and / to get better meaning than bo= ld and italic. > For me it is already widely accepted that * is, sometimes, considered as > bold, but more widely used for emphasis. So it should be considered as > such (and, personally, I=E2=80=99ve meant this so that it could begin ren= dering > with italic on display for instance, or whatever is the favorite > emphasis method of the user, it should be configurable). > > / is a way harder problem as it has been used because of its slanted > appearance, to mean italic, so sometimes it=E2=80=99s used for emphasis, > sometimes for other uses of emphasis. Ideally I=E2=80=99d like to be act= ed it=E2=80=99s > not for emphasis (it=E2=80=99s way less used and supported than * for it,= and * > already serves this purpose very well informally), so implementations > derive some other meaning for it, to get richer semantics. > >> - I don't believe there is any strong reason that the markup used by org >> should have any strong reference to HTML in appearance. Org supports >> many different backends, many of which don't have anything to do with >> HTML at all. It is perhaps unfortunate that Org syntax and markdown >> are quite different (though I feel the unfortunate part is that >> markdown didn't follow org more closely as I much prefer Org's syntax >> to most markdown semantics).=20=20 > > I don=E2=80=99t like markdown either, nor ReStructuredText. Why I talked= a lot > about HTML is for two reasons: the discussion was initially about it, > and it is, afaik, the richest and most known semantical markup > language. It is *way* richer than LaTeX, org, md, rst, etc. maybe even > odt and texinfo, but I=E2=80=99m unsure. > > However the * and / exports to texinfo with the same tags as html, that > is respectively strong and emphasis, which I find sad as * is what is > mostly used for emphasis (and too levels are pretty much not needed, why > richer semantics could). ODT seems to use =E2=80=9C=E2=80=9D with = =E2=80=9Cstyle-name=3D"Emphasis"=E2=80=9D: I > heard ODT could be somewhat semantic, but I don=E2=80=99t know if that th= e best > they can do (maybe this =E2=80=9Cstyle-name=E2=80=9D has standard semanti= cs? because to > me styling is for presentation, and tagging for semantics). > > Also a problem of many backends is they=E2=80=99re made for printing or l= ess > semantic: pdf is not made for semantics, although I heard somewhere that > they were trial to make it so (which sounds silly as it is tailored for > printing and supports almost no dynamic modifications, it would be > better to stop using PDFs at all, in, eg, administration). > >> - Probably the number 1 issue I come across when dealing with markup is >> the expectation too many authors have that things will be rendered in >> the browser in a specific way (a particular font, colour, position, >> size, etc). This is a mistake. The big advantage of electronic >> presentation is that for the first time, the consumer can have control >> over the presentation - they can customise it to meet their >> requirements or preferences. > > *Exactely*. Except that then, web become commercial, and businesses > have found it especially good way to control what users saw almost as > fully as in advertisements (so it can bring control, power to them, and > also money, secondarily (if they use non-semantic tags and only
> and in awfully complex sgml soup, then no user is able to control > anything)), just as French minitel would, and they begun first to abuse > display-level tagging, then to abuse CSS and html-style-soup (full of > 80% of
and , and enormous CSSes, yay! what a progress! =E2= =80=A6>< > yet now we have worse: less CSS, less =E2=80=9Cstyle=E2=80=9D, and more = =E2=80=9Cdata-*=E2=80=9D and > non-free surveillance javascript to replace them). > >> The problem with and is that it gives authors an expectation >> their content will be rendered in a specific way. > > Not anymore, since W3C, somewhat breaking backward-compatibility, > decided is for =E2=80=9Ckeywords=E2=80=9D without special emphasis, a= nd not being a > definition (there=E2=80=99s already afaik for that), and is for > =E2=80=9Ddifferently-pronounced phrasing content=E2=80=9D, without emphas= is, such as > text prounced with a tone of disgust, or foreign-language text (so if > you want to embed french words not used enough to be in english > dictionary, and if it=E2=80=99s nor a real quotation (), yo= u should > use du texte en fran=C3=A7aise). > > So I can theorically decide that any word markuped may compose a > local list of easily reachable (for instance with keystrokes) > =E2=80=9Ckeywords=E2=80=9D, like lynx, that b should be displayed normall= y, but in blue, > and that would be a standard-complying www user-agent. > >> Some may argue that the author should be able to control how their >> content is rendered. I think this is misleading because unlike >> printed material, the author has no control over the presentation >> media - they don't know how large the screen is, what the >> capabilities of the screen is, what fonts are installed >> etc. Therefore, tags which focus on meaning i.e. I want this to >> stand out or I want this to be emphasised are clearer than tags >> which say to make this bold or make this italic. > > Yes they can: they can require you server-side connecting from a local > network on computers furnished by the organization of the place (already > saw that), while checking what do you do and how to make you doing it > client-side with proprietary javascript, or even to have a tablet with > retina screen with a such range of screen sizes, on iOS=E2=80=A6 and=E2= =80=A6 btw=E2=80=A6 this > already exists, there=E2=80=99s an app for it: AppStore (GooglePlay too):= they > furnish HTML/CSS UI, controled by proprietary software, only distributed > for their devices, theorically only working on those (at least the apps > are developed, configured, and tested so). And afaik developers don=E2= =80=99t > mind making their software more usable with TalkBack (I don=E2=80=99t eve= n know > if there=E2=80=99s a such thing for iOS). > > The excuse of =E2=80=9Cthe device is not always the same=E2=80=9D is to m= e a weak one: > this can, with special political and commercial restrictions, be > lowered, and then it could be considered a =E2=80=9Creasonable workaround= =E2=80=9D > (while this is not). What should be advertised is it breaks > accessibility, don=E2=80=99t comply standard, will certainly break > forward-compatibility, legally-mandatory interoperability, and, as for > proprietary software, gives power to authors (or, more often but not > always, companies) and deprive users of what they could and should > have. This power is comparable to what power is gained through > advertisements, propaganda. > > >> The debate over , , and is likely to continue for >> some years yet. I do think things are moving towards / >> and nearly everything I read these days recommends these over and >> . > > There are companies (and some individual, or countries) who gain power > by doing so, just as they can do by pushing proprietary software (yet on > a different level), so I don=E2=80=99t believe they will ever stop doing > anything equivalent. Nor advertise they would do so. > > So this is not a debate. Like there is no =E2=80=9Cfree vs proprietary= =E2=80=9D debate, > or =E2=80=9Cclimate change vs this-is-god/a-myth=E2=80=9D debate: the adv= ocate of the > first have arguments and facts, the actors of the second are either > stating their ennemies are idealist, stating their goal are > unrealizable, or they =E2=80=9Cdo so because they have no choice=E2=80=9D= , or =E2=80=9Cdo their > best not harm=E2=80=9D, and then push more and more pervasive and unadver= tised > way of harming, such as DRM and proprietary javascript, or, in our case, > use sometimes and , but allow users to publish content > using and (and colors!!!), and making their whole website a soup > of
and , heavily relying on a gigantic style soup, based on > a site-specific CSS stylesheet, that will be partially generated > server-side, partially heavily =E2=80=9Cimprove=E2=80=9D (that is: depend= upon) > proprietary javascript. > > Btw, this is what Google does. And Google is quite evidently the > biggest feudal lord on the Web. > >> It is pretty well accepted that XHTML was a mistake and HTML5 goes a >> long way to address the issues introduced with XHTML - I think XHTML >> as a standard is pretty much relegated to an evolutionary dead end. > > XHTML was a beautiful standard and was dismissed because all the money > and resources were placed on HTML5, whose main selling point was new > media resources (namely