Re: [O] *markup*, /markup/ and _markup_ true semantics [Was: Re: Ox-html: Replace <b> with <strong> and <i> with <em>]

[Garreau\, Alexandre]

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’s a misunderstandnment but if it’s 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 “italic” and “bold” (the org
manual, as you later said, even do so).  What I wanted to underline is
that both “italic” and “bold” (and underline 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’s as imperfect as a bitmap 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’m willing to extract as much of the original meaning (be it about
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. 

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 <em>, <strong>, and <ins> tags, that
were actually just a poor 1-to-1 wrapping to the old <i>, <b> and <u>
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’s why I wanted to check with Orca, NVDA, and maybe Jaws 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’s why I’d like * and / to get better meaning than bold 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’ve meant this so that it could begin rendering
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’s used for emphasis,
sometimes for other uses of emphasis.  Ideally I’d like to be acted it’s
not for emphasis (it’s 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).  

I don’t 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’m 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 “<span>” with 
“style-name="Emphasis"”: I
heard ODT could be somewhat semantic, but I don’t know if that the best
they can do (maybe this “style-name” has standard semantics? because to
me styling is for presentation, and tagging for semantics).

Also a problem of many backends is they’re made for printing or less
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 <div>
and <span> 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 <div> and <span>, and enormous CSSes, yay! what a progress!  …><
yet now we have worse: less CSS, less “style”, and more “data-*” and
non-free surveillance javascript to replace them).

>   The problem with <b> and <i> 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 <b> is for “keywords” without special emphasis, and not being a
definition (there’s already <dfn> afaik for that), and <i> is for
”differently-pronounced phrasing content”, without emphasis, 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’s nor a real quotation (<q lang="fr>), you should
use <i lang="fr">du texte en française</i>).

So I can theorically decide that any word markuped <b> may compose a
local list of easily reachable (for instance with keystrokes)
“keywords”, like lynx, that b should be displayed normally, 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… and… btw… this
already exists, there’s 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’t
mind making their software more usable with TalkBack (I don’t even know
if there’s a such thing for iOS).

The excuse of “the device is not always the same” is to me a weak one:
this can, with special political and commercial restrictions, be
lowered, and then it could be considered a “reasonable workaround”
(while this is not).  What should be advertised is it breaks
accessibility, don’t 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 <i>, <b>, <strong> and <em> is likely to continue for
> some years yet.  I do think things are moving towards <strong>/<em>
> and nearly everything I read these days recommends these over <i> and
> <b>.

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’t believe they will ever stop doing
anything equivalent.  Nor advertise they would do so.

So this is not a debate.  Like there is no “free vs proprietary” debate,
or “climate change vs this-is-god/a-myth” debate: the advocate 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 “do so because they have no choice”, or “do their
best not harm”, and then push more and more pervasive and unadvertised
way of harming, such as DRM and proprietary javascript, or, in our case,
use sometimes <em> and <strong>, but allow users to publish content
using <b> and <i> (and colors!!!), and making their whole website a soup
of <div> and <span>, heavily relying on a gigantic style soup, based on
a site-specific CSS stylesheet, that will be partially generated
server-side, partially heavily “improve” (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 <audio> and <video>) and new sensors/multimedia
API for javascript.  So that hopefully killed flash, java, and almost
silverlight (which had its niche anyway), and replaced it with
proprietary obfusced javascript and DRM.  The only evolution is we have
free softwares to execute it, hence we may have better time
reverse-engineering and hacking it.

XHTML was a dead end not because evolution, but because, from what I
heard, it was pretty much, as XML compared to SGML, something promoted
by academics, IA/semiology (study of semantics) researchers and
universities (the same who made XPath, RDF, XML Schemas, DTD, SPARQL,
SQL predecessors, logical languages, etc.), so to make the whole thing
more extensible, modular, and factorized.  For instance, the fact of
embedding MathML (semantic markuping for maths language), instead of
using images (TeX-generated, of course) to display formulas, come from
XHTML, and doing that in HTML5 is called “XHTML5”.  Same for SVG.  Same
for XLinks (more powerful than HTML hyperlinking facilities, more near
to what was originally meant for first-browser HTML links (dual-end
links, multi-links, etc.), hence more semantic, and currently, as a
small subset, used in SVG and ODT to mark link.

XHTML was a great step toward semantics actually, and its death is
extremely sad, even for semantics.

But, nowadays, though they’re member as well, just as Mozilla, we know
now W3C is ran by Netflix, BBC, and other displayfull DRM companies.  So
HTML5 won over XHTML, because XML, pure logics, and semiology (what made
“semantic” stuff possible at all) do not interest these companies.
Codec-supports and DRM do.

> I do agree <div> is over used. In particular, HTML5 has a number of
> new tags which should be used to convey document structure which would
> be a better choice than <div> with different 'class' attributes.

XHTML2 had those, too (not all yet), before to be killed by HTML5.
Also, not only new elements, but combinations of those, can be used to
replace “style”.  For instance, “article article” CSS selector refers to
what HTML specs call a “comment” (and “article > footer:first-child” is
what we call in mail a “header”: it contains secondary metadata).  But
currently, everywhere in the web, comments do not always use the
“article” tag, or always are outside the commented article tag, and use
a special non-standard css style to mark them.

Note this is a non-standard, opaque and almost proprietary format: it’s
not patented, it’s not copyrighted, but its implementation (either CSS
or proprietary javascript) most of time is.  It’s not binary, it is
based on a cleartext format, but obfuscated, and unlike what cleartext
advocated have said, way more impossible to reverse-engineer than a
single binary format: easily guessable, of course, but just like a
binary format is difficult and take time to make, a text-format is easy
and quick to make, so there are *millions* of them, at least one per
website, and nobody will ever be able to reverse engineer that (unlike
binary formats which are fewer).

> However, we will continue to see a lot of div tags, even when authors
> begin to use newer tags - at least it is a lot better than the early
> days when everything was stuck inside tables!

Ah the old days… now they’ve got css-level tables.  But they still need
a div tag soup for it, instead of advanced selectors, so they keep
complexifying the (X)HTML, and making it bloated and unreadable.

Instead, in XML, we had DSSSL (inspired from scheme) and XSLT
(turing-complete, purely functional, XML syntax) to transform it in
display level things: you *never* need to change the XHTML, only your
stylesheet will get more complex as your display becomes more complex,
and you can do *anything* with your initial, semantics tags.

But now XHTML is dead, this kind of powerfulness is to reserve for
LaTeX3, lisp, and such.

> Backends which generate HTML should be generating HTML5 compliant
> output if for no other reason than it is clearer and easier than
> XHTML.

XHTML allows embedding content and using more semantic markup.  For
instance it could allow using MathML for math equations (a lot used in
org, though through AMSLaTeX syntax), instead of, in org-mode export,
currently used MathJAX, relying on javascript and display-level CSS.

> As to the OP's original question regarding changing <b> and <i> in HTML
> backends - while I would vote for strong/em over b/i, I don't think
> there is any real need to do this, certainly not in the short term. As
> was pointed out b/i has not been deprecated, so it is still valid. There
> is no suggestion to change Org's own internal markup (ironically
> referred to as bold and italic!), so overall, the status quo seems fine.

I believe we should begin making it semantic, as for
forward-compatibility, and it is always better to break backward-compat,
or introduce new specs the sooner as possible, because as the
implementation gets more widely used, the burden to change it
incompatibly increases as well.