tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Guy Harris <guy@alum.mit.edu>
Cc: tech@mdocml.bsd.lv, jmc@openbsd.org
Subject: Re: mdoc(7): improve description of .Em and .Sy
Date: Thu, 14 Aug 2014 18:07:14 +0200	[thread overview]
Message-ID: <20140814160714.GE29858@iris.usta.de> (raw)
In-Reply-To: <688F0B4B-25B9-4C50-8746-55AB04734189@alum.mit.edu>

Hi Guy,

Guy Harris wrote on Wed, Aug 13, 2014 at 03:54:55PM -0700:

> On Aug 13, 2014, at 2:22 PM, Ingo Schwarze <schwarze@usta.de> wrote:

>> The central question is whether these macros should be considered
>> as semantic or as physical markup.  While the historic documents
>> may slightly, if inconsistently, favour the semantic standpoint,
>> in our MACRO OVERVIEW i called them "physical", and i'd like to
>> stick with that, for the following reason:  Even if we call them
>> semantic, we have to define such a broad range of semantic
>> meanings that translation into any other modern semantic markup
>> language, in particular HTML, becomes impossible.  In particular,
>> sometimes .Em would have to become <em>, sometimes <i>, .Sy
>> sometimes <strong> and sometimes <b>, but there is no way to
>> automatically decide which is the right one when finding one of
>> these macros in a manual page, so we would have to fall back to
>> physical markup anyway.  Calling the physical also reflects actual
>> usage better and isn't completely inconsistent with historical
>> documentation.

> Well, there's physical, as in "display this in italic characters",

That's exactly what people usually mean when talking about
physical (or presentational or visual) markup, see for example

http://www.math.grin.edu/~rebelsky/Tutorials/Design/EdMedia97/logical-vs-physical.html
http://www.augustana.ab.ca/~mohrj/courses/2000.fall/csc110/lecture_notes/html.html
http://webtips.dan.info/logical.html
http://www.cs.tut.fi/~jKorpela/HTML3.2/4.5.html
...

> and there's physical, as in "present this in some form that
> indicates emphasis"; the latter is "physical" in that it explicitly
> affects presentation [...]

"Affecting but not specifying presentation" is almost the definition
of semantic (or logic or structural) markup, which is the opposite
of physical markup.  So i fear you are confusing the terms here.

> Unfortunately, mdoc, unlike HTML, never had "display this in italic
> characters", and somebody who had a reason to want the text displayed
> in italic characters for reasons *other* than emphasis had to fall back
> on .Em,

Not quite.  When the development of mdoc(7) started in about 1989,
it predated HTML and the web, and people weren't aware at that time
that the distinction of physical and semantic markup is all that
important.  For example Tim Barners-Lee's original WWW proposal
does not mention "formatting" at all:

  http://www.w3.org/History/1989/proposal.html

There is a document about future "HTML directions" as late as 1992 (!)
talking about the possible introduction of <bold> and <italic> tags -
that's what is called <b> and <i> now - mentioning the terms "physical"
and "logical" markup, but not even mentioning that logical markup should
usually be preferred:

  http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Future.html

People were blurry about it at the time, they didn't see that it
matters, you can clearly see that here in the 4.3BSD-Reno text
predating the HTML <bold> discussion by two years:

  Symbolic
  The symbolic request is really a boldface request.  The need for this
  macro has not been established, it is included 'just in case'.
  Usage: .Sy symbol ...
  Example output: something bold

  Emphasis Request
  A portion of text may be stressed or emphasized with the .Em request.
  The font used is commonly italic.
  Usage: .Em argument ...

One is described as physical ("boldface") with a fuzzy reference
to semantics ("symbolic"), the other is described as semantic
("emphasized").  People just didn't care back then.  That
neglect persists in the groff documentation to this day.

> so maybe retroactively redefining .Em to mean "display this in italic
> characters"

We are not retroactively redefining it.  The code always did just
that and the docs always hinted at both the formatting and the
semantics.  It's merely that at the time the documentation was
written, people didn't care about the distinction "<font>, usually
used for <purpose>" and "<purpose>, usually formatted in <font>".
So we are merely clarifying it.

> is the least bad choice (adding .I to mdoc wouldn't help people who
> want to write man pages that will work with older versions of mandoc
> and with the mdoc macros).

I don't see an urgent need to add any macros in this area either.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2014-08-14 16:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 21:22 Ingo Schwarze
2014-08-13 22:54 ` Guy Harris
2014-08-14 16:07   ` Ingo Schwarze [this message]
     [not found] ` <20140814065720.GB7407@harkle.home.gateway>
2014-08-14 15:13   ` Ingo Schwarze
     [not found]     ` <20140814201627.GD7407@harkle.home.gateway>
2014-08-14 22:05       ` Ingo Schwarze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140814160714.GE29858@iris.usta.de \
    --to=schwarze@usta.de \
    --cc=guy@alum.mit.edu \
    --cc=jmc@openbsd.org \
    --cc=tech@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).