Is there any reason not to use <EM> for items emphasized with .Em?

Is there any reason not to use <EM> for items emphasized with .Em?

[Guy Harris]

.Em is documented in the groff_mdoc man page as

  Emphasis Macro
    Text may be stressed or emphasized with the `.Em' macro.  The usual font
    for emphasis is italic.

That sounds like the <EM> HTML tag - the HTML 4.01 spec says

	EM:
	Indicates emphasis.

		...

	The presentation of phrase elements depends on the user agent. Generally, visual user agents present EM text in italics and STRONG text in bold font. Speech synthesizer user agents may change the synthesis parameters, such as volume, pitch and rate accordingly.

Is there any reason not to use that tag for text emphasized with .Em?

If not, here's a patch:
 
diff -Nup ../mdocml-1.13.1/example.style.css ./example.style.css
--- ../mdocml-1.13.1/example.style.css	2014-08-10 10:26:46.000000000 -0700
+++ ./example.style.css	2014-08-12 14:04:22.000000000 -0700
@@ -30,7 +30,7 @@ div.mandoc .list		{ } /* All Bl. */
 div.mandoc i			{ } /* Italic: BI, IB, I, (implicit). */
 div.mandoc b			{ } /* Bold: SB, BI, IB, BR, RB, B, (implicit). */
 div.mandoc small		{ } /* Small: SB, SM. */
-div.mandoc .emph		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
+div.mandoc em			{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
 div.mandoc .symb		{ font-style: normal; font-weight: bold; } /* Symbolic: Sy, Ms, Bf -symbolic. */
 div.mandoc .lit			{ font-style: normal; font-weight: normal; font-family: monospace; } /* Literal: Dl, Li, Ql, Bf -literal, Bl -literal, Bl -unfilled. */
 div.mandoc i.addr		{ font-weight: normal; } /* Address (Ad). */
diff -Nup ../mdocml-1.13.1/html.c ./html.c
--- ../mdocml-1.13.1/html.c	2014-08-10 10:26:46.000000000 -0700
+++ ./html.c	2014-08-12 14:04:22.000000000 -0700
@@ -76,6 +76,7 @@ static	const struct htmldata htmltags[TA
 	{"i",		0 }, /* TAG_I */
 	{"code",	0 }, /* TAG_CODE */
 	{"small",	0 }, /* TAG_SMALL */
+	{"em",		0 }, /* TAG_EM */
 };
 
 static	const char	*const htmlattrs[ATTR_MAX] = {
diff -Nup ../mdocml-1.13.1/html.h ./html.h
--- ../mdocml-1.13.1/html.h	2014-08-10 10:26:46.000000000 -0700
+++ ./html.h	2014-08-12 14:04:22.000000000 -0700
@@ -50,6 +50,7 @@ enum	htmltag {
 	TAG_I,
 	TAG_CODE,
 	TAG_SMALL,
+	TAG_EM,
 	TAG_MAX
 };
 
diff -Nup ../mdocml-1.13.1/mdoc_html.c ./mdoc_html.c
--- ../mdocml-1.13.1/mdoc_html.c	2014-08-10 10:26:46.000000000 -0700
+++ ./mdoc_html.c	2014-08-12 15:40:03.000000000 -0700
@@ -1085,10 +1085,7 @@ mdoc_ex_pre(MDOC_ARGS)
 static int
 mdoc_em_pre(MDOC_ARGS)
 {
-	struct htmlpair	tag;
-
-	PAIR_CLASS_INIT(&tag, "emph");
-	print_otag(h, TAG_SPAN, 1, &tag);
+	print_otag(h, TAG_EM, 0, NULL);
 	return(1);
 }
 
@@ -1824,9 +1821,7 @@ mdoc_bf_pre(MDOC_ARGS)
 	else if (MDOC_BODY != n->type)
 		return(1);
 
-	if (FONT_Em == n->norm->Bf.font)
-		PAIR_CLASS_INIT(&tag[0], "emph");
-	else if (FONT_Sy == n->norm->Bf.font)
+	if (FONT_Sy == n->norm->Bf.font)
 		PAIR_CLASS_INIT(&tag[0], "symb");
 	else if (FONT_Li == n->norm->Bf.font)
 		PAIR_CLASS_INIT(&tag[0], "lit");
@@ -1844,6 +1839,10 @@ mdoc_bf_pre(MDOC_ARGS)
 	bufcat_su(h, "margin-left", &su);
 	PAIR_STYLE_INIT(&tag[1], h);
 	print_otag(h, TAG_DIV, 2, tag);
+	if (FONT_Em == n->norm->Bf.font) {
+		/* Tag this with <EM>. */
+		print_otag(h, TAG_EM, 0, NULL);
+	}
 	return(1);
 }
 
diff -Nup ../mdocml-1.13.1/style.css ./style.css
--- ../mdocml-1.13.1/style.css	2014-08-10 10:26:46.000000000 -0700
+++ ./style.css	2014-08-12 14:04:22.000000000 -0700
@@ -34,7 +34,7 @@ td.head-rtitle	{ width: 10%; text-align:
 /* General font modes. */
 
 i		{ } /* Italic: BI, IB, I, (implicit). */
-.emph		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
+em		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
 b		{ } /* Bold: SB, BI, IB, BR, RB, B, (implicit). */
 .symb		{ font-style: normal; font-weight: bold; } /* Symbolic: Sy, Ms, Bf -symbolic. */
 small		{ } /* Small: SB, SM. */


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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Ingo Schwarze]

Hi Anthony and Kristaps,

i think this is an improvement but feel like knowing too little
about HTML to just go ahead and commit.  Can either of you (or
somebody else who feels at home with HTML) provide an OK?

Thanks,
  Ingo


Guy Harris wrote on Tue, Aug 12, 2014 at 03:44:07PM -0700:

> .Em is documented in the groff_mdoc man page as
> 
>   Emphasis Macro
>     Text may be stressed or emphasized with the `.Em' macro.  The usual font
>     for emphasis is italic.
> 
> That sounds like the <EM> HTML tag - the HTML 4.01 spec says
> 
> 	EM:
> 	Indicates emphasis.
> 
> 		...
> 
> 	The presentation of phrase elements depends on the user agent. Generally, visual user agents present EM text in italics and STRONG text in bold font. Speech synthesizer user agents may change the synthesis parameters, such as volume, pitch and rate accordingly.
> 
> Is there any reason not to use that tag for text emphasized with .Em?
> 
> If not, here's a patch:
>  
> diff -Nup ../mdocml-1.13.1/example.style.css ./example.style.css
> --- ../mdocml-1.13.1/example.style.css	2014-08-10 10:26:46.000000000 -0700
> +++ ./example.style.css	2014-08-12 14:04:22.000000000 -0700
> @@ -30,7 +30,7 @@ div.mandoc .list		{ } /* All Bl. */
>  div.mandoc i			{ } /* Italic: BI, IB, I, (implicit). */
>  div.mandoc b			{ } /* Bold: SB, BI, IB, BR, RB, B, (implicit). */
>  div.mandoc small		{ } /* Small: SB, SM. */
> -div.mandoc .emph		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
> +div.mandoc em			{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
>  div.mandoc .symb		{ font-style: normal; font-weight: bold; } /* Symbolic: Sy, Ms, Bf -symbolic. */
>  div.mandoc .lit			{ font-style: normal; font-weight: normal; font-family: monospace; } /* Literal: Dl, Li, Ql, Bf -literal, Bl -literal, Bl -unfilled. */
>  div.mandoc i.addr		{ font-weight: normal; } /* Address (Ad). */
> diff -Nup ../mdocml-1.13.1/html.c ./html.c
> --- ../mdocml-1.13.1/html.c	2014-08-10 10:26:46.000000000 -0700
> +++ ./html.c	2014-08-12 14:04:22.000000000 -0700
> @@ -76,6 +76,7 @@ static	const struct htmldata htmltags[TA
>  	{"i",		0 }, /* TAG_I */
>  	{"code",	0 }, /* TAG_CODE */
>  	{"small",	0 }, /* TAG_SMALL */
> +	{"em",		0 }, /* TAG_EM */
>  };
>  
>  static	const char	*const htmlattrs[ATTR_MAX] = {
> diff -Nup ../mdocml-1.13.1/html.h ./html.h
> --- ../mdocml-1.13.1/html.h	2014-08-10 10:26:46.000000000 -0700
> +++ ./html.h	2014-08-12 14:04:22.000000000 -0700
> @@ -50,6 +50,7 @@ enum	htmltag {
>  	TAG_I,
>  	TAG_CODE,
>  	TAG_SMALL,
> +	TAG_EM,
>  	TAG_MAX
>  };
>  
> diff -Nup ../mdocml-1.13.1/mdoc_html.c ./mdoc_html.c
> --- ../mdocml-1.13.1/mdoc_html.c	2014-08-10 10:26:46.000000000 -0700
> +++ ./mdoc_html.c	2014-08-12 15:40:03.000000000 -0700
> @@ -1085,10 +1085,7 @@ mdoc_ex_pre(MDOC_ARGS)
>  static int
>  mdoc_em_pre(MDOC_ARGS)
>  {
> -	struct htmlpair	tag;
> -
> -	PAIR_CLASS_INIT(&tag, "emph");
> -	print_otag(h, TAG_SPAN, 1, &tag);
> +	print_otag(h, TAG_EM, 0, NULL);
>  	return(1);
>  }
>  
> @@ -1824,9 +1821,7 @@ mdoc_bf_pre(MDOC_ARGS)
>  	else if (MDOC_BODY != n->type)
>  		return(1);
>  
> -	if (FONT_Em == n->norm->Bf.font)
> -		PAIR_CLASS_INIT(&tag[0], "emph");
> -	else if (FONT_Sy == n->norm->Bf.font)
> +	if (FONT_Sy == n->norm->Bf.font)
>  		PAIR_CLASS_INIT(&tag[0], "symb");
>  	else if (FONT_Li == n->norm->Bf.font)
>  		PAIR_CLASS_INIT(&tag[0], "lit");
> @@ -1844,6 +1839,10 @@ mdoc_bf_pre(MDOC_ARGS)
>  	bufcat_su(h, "margin-left", &su);
>  	PAIR_STYLE_INIT(&tag[1], h);
>  	print_otag(h, TAG_DIV, 2, tag);
> +	if (FONT_Em == n->norm->Bf.font) {
> +		/* Tag this with <EM>. */
> +		print_otag(h, TAG_EM, 0, NULL);
> +	}
>  	return(1);
>  }
>  
> diff -Nup ../mdocml-1.13.1/style.css ./style.css
> --- ../mdocml-1.13.1/style.css	2014-08-10 10:26:46.000000000 -0700
> +++ ./style.css	2014-08-12 14:04:22.000000000 -0700
> @@ -34,7 +34,7 @@ td.head-rtitle	{ width: 10%; text-align:
>  /* General font modes. */
>  
>  i		{ } /* Italic: BI, IB, I, (implicit). */
> -.emph		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
> +em		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
>  b		{ } /* Bold: SB, BI, IB, BR, RB, B, (implicit). */
>  .symb		{ font-style: normal; font-weight: bold; } /* Symbolic: Sy, Ms, Bf -symbolic. */
>  small		{ } /* Small: SB, SM. */
> 
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Anthony J. Bentley]

Hi Ingo,

Ingo Schwarze writes:
> i think this is an improvement but feel like knowing too little
> about HTML to just go ahead and commit.  Can either of you (or
> somebody else who feels at home with HTML) provide an OK?

I thought this would be a dead simple decision, but my email draft keeps
getting more and more complicated!

There are three HTML elements that could conceivably make sense here:
<i>, <em>, and <strong>.

mdoc(7):
"Denotes text that should be emphasised.  Note that this is a presentation
term and should not be used for stylistically decorating technical terms.
Depending on the output device, this is usually represented using an
italic font or underlined characters."

Based on this description, <i> would make the most sense. (Essentially,
I read it as being a straight equivalent to man(7)'s I macro.)

http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-i-element

mdoc(7):
Examples:
      .Em Warnings!
      .Em Remarks:

Based on these examples, <strong> would make the most sense.

http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-strong-element

Note that in the HTML world, <strong> is considered to be a semantic
element (unlike <i>). In practice, browsers display <strong> in boldface
but the standard would allow italics here because it is considered a
semantic element.

(As an aside, there are many uses of Sy in OpenBSD manpages like "Note:"
and "Important:". Based on mdoc(7) that seems to be misuse of
presentational macros.)

The third possible element is <em> itself. <em>'s raison d'être is
emphasis, such as most situations where you would use italics in prose
(although one exception would be "raison d'être" itself, which as a
foreign language idiom would be marked up with <i>...).

http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-em-element

Honestly? I think this is just hair-splitting and we should use <em>
for Em. But if we do that, mdoc(7) probably should be revised for clarity.

-- 
Anthony J. Bentley

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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Ingo Schwarze]

Hi,

i think i have made up my mind.  First, what Anthony said here confirms
my impression that <span> is clearly not the right element for .Em, which
was Guy's main point, i think.

Regarding which HTML element to pick, the important aspect to keep in
mind is that .Em, .Sy, and .Li are not semantic, but physical markup.
In other words, they can be used for text that needs markup in some
way when none of the semantic markup macros fit.

In particular,

 - .Em can be used for all text that would usually end up in italic font,
   for example stress emphasis or alternate voice or mood.
 - .Sy can be used for all text that would usually end up in bold face,
   for example importance or highlighting.
 - .Li can be used for all text that would usually end up in fixed width font,
   for example code samples.

Real examples from base system manuals include:

Typical stress emphasis:  -> corresponds to <em>
History substitutions begin with the character
.Ql \&!
and may begin
.Em anywhere
in the input stream (with the proviso that they do
.Em not
nest).

Looks more like alternate quality (technical term):  ->  <i>
The shell begins parsing its input by breaking it into
.Em words .

Obviously, it is not feasible to automatically distinguish both
cases.  But looking at real manuals, my rough guess is that for .Em
we have about

 - 70% of stress emphasis
 - 20% of abuse that should be replaced by other macros
 - 10% of alternate voice, mood, or quality

I didn't count, so the numbers may be somewhat wrong, but the exact
numbers don't really matter.  What matters is that stress emphasis
is the vast majority, and even in the cases of alternate quality,
there is usually some emphasis, too, so <em> isn't that bad either.


Typical importance markup:  ->  corresponds to <strong>
.Sy Note :
.Sy Warning :

Typical examples of highlighting keywords:  ->  <b>
Note that the
.Fl t
flag replaces the function of the old
.Sy dumpdir
program.
.It Sy S
If in the owner permissions, the file is not executable and
set-user-ID mode is set.

Here, my impression is that we have about

 - 80% of importance markup
 -  5% of abuse
 - 15% of keyword highlighting

The reason we don't have more keyword highlighting is that
more specific macros like .Nm .In .Fo .Fn exist.

Here, even though importance markup is clearly in the majority,
keyword highlighting does exist for good reasons, and <strong>
is rather unfortunate for keyword highlighting, so this is a
tougher call than for .Em.  But there seems to be no way out.
Having tons of <b>Warning!</b> all over the place wouldn't be
any better, really.


So i think we should go for the following mappings:

 - .Em                      ->  <em>
 - .Sy                      ->  <strong>
 - .Li Ql .Dl .Bd -literal  ->  <code>

Yes, this is sometimes off, but it's the best fit, i think.

Some specific answers:

Anthony J. Bentley wrote on Tue, Aug 12, 2014 at 08:06:38PM -0600:

> mdoc(7):
> Examples:
>       .Em Warnings!
>       .Em Remarks:

These examples are clearly wrong and should be fixed in the manual.

> (As an aside, there are many uses of Sy in OpenBSD manpages like "Note:"
> and "Important:". Based on mdoc(7) that seems to be misuse of
> presentational macros.)

No, i think that usage is just right.

> Honestly? I think this is just hair-splitting and we should use <em>
> for Em. But if we do that, mdoc(7) probably should be revised for clarity.

Fully agreed.

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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Anthony J. Bentley]

Hi Ingo,

I agree with your analysis. However:

Ingo Schwarze writes:
> So i think we should go for the following mappings:
> ...
>  - .Li Ql .Dl .Bd -literal  ->  <code>

This may be the best choice. Some alternatives to consider (if not for
these then maybe for some of the more semantic macros):

<var>: "The var element represents a variable."

<samp>: "The samp element represents sample or quoted output from another
program or computing system."

<kbd>: "The kbd element represents user input (typically keyboard input,
although it may also be used to represent other input, such as voice
commands."

http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-var-element
http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-samp-element
http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-kbd-element

-- 
Anthony J. Bentley

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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Ingo Schwarze]

Hi Anthony,

Anthony J. Bentley wrote on Wed, Aug 13, 2014 at 09:17:55AM -0600:
> Ingo Schwarze writes:

>> So i think we should go for the following mappings:
>> ...
>>  - .Li Ql .Dl .Bd -literal  ->  <code>

> This may be the best choice. Some alternatives to consider (if not for
> these then maybe for some of the more semantic macros):
> 
> <var>: "The var element represents a variable."

That's too specific for the macros mentioned above,
but i added this note to the TODO file:

 - consider whether <var> can be used for Ar Dv Er Ev Fa Va.
   from bentley@  Wed, 13 Aug 2014 09:17:55 -0600

> <samp>: "The samp element represents sample or quoted output from another
> program or computing system."
> 
> <kbd>: "The kbd element represents user input (typically keyboard input,
> although it may also be used to represent other input, such as voice
> commands."

There are no macros specific enough for that, the general recommendation
is to use literal mode for such content.

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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Joerg Sonnenberger]

On Tue, Aug 12, 2014 at 03:44:07PM -0700, Guy Harris wrote:
> Is there any reason not to use that tag for text emphasized with .Em?

I like the idea, but I wonder if we should just drop the manual rules.

Joerg
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Ingo Schwarze]

Hi Joerg,

Joerg Sonnenberger wrote on Wed, Aug 13, 2014 at 03:44:39AM +0200:
> On Tue, Aug 12, 2014 at 03:44:07PM -0700, Guy Harris wrote:

>> Is there any reason not to use that tag for text emphasized with .Em?

> I like the idea, but I wonder if we should just drop the manual rules.

You mean, in the stylesheets?

Maybe.

I'll leave that to the general cleanup and unification of the
stylesheets, though.

To reiterate, i'd like to have one stylesheet instead of three.

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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Ingo Schwarze]

Hi,

Kristaps just pointed out that <em> accepts phrasing content only,
while .Bf may contain flow content like Bd Bf Bl D1 Pp Rs.
So my commit is incorrect:

ischwarze@isnote $ cd /usr/src/regress/usr.bin/mandoc/mdoc/Bf/ 
ischwarze@isnote $ mandoc -Thtml nest.in | validate            
*** Errors: ***
Error at line 30, character 73:  element "DIV" not allowed here; possible
        cause is an inline element containing a block-level element
Error at line 33, character 67:  element "DIV" not allowed here; possible
        cause is an inline element containing a block-level element

Ouch.

If <em> were a perfect match for .Em, and <strong> for .Sy, and
<code> for .Li, i'd tend to let mdoc_bf_pre() explicitly iterate
its children instead of relying on the loop in print_mdoc_node(),
close <em> before block children and reopen it afterwards, even
though that's a bit more complicated than what we have now.

But there is a second, slight problem:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em
exlicitly says:

  Usage Note: Typically this element is displayed in italic type.
  However, it should not be used simply to apply italic styling;
  use the CSS styling for that purpose.

Which is exactly what Kristaps' code did before my commit - and note
that i just argued myself, in my last mail, that .Em is physical,
not semantic markup, so this advice does indeed seem to apply.

Now we might revert the .Bf part only, maybe even only in those
cases where there actually *are* block children.  But that would
make .Bf output differ from .Em output, or even from other .Bf
output.  That doesn't seem nice, really, and it doesn't solve the
second problem.

So i tend to just revert the whole commit outright, solving both
problems completely and also avoiding code complication, and go
hide under a rock for the rest of the day.

Any thoughts?
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Guy Harris]

On Aug 13, 2014, at 10:20 AM, Ingo Schwarze <schwarze@usta.de> wrote:

> But there is a second, slight problem:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em
> exlicitly says:
> 
>  Usage Note: Typically this element is displayed in italic type.
>  However, it should not be used simply to apply italic styling;
>  use the CSS styling for that purpose.
> 
> Which is exactly what Kristaps' code did before my commit - and note
> that i just argued myself, in my last mail, that .Em is physical,
> not semantic markup, so this advice does indeed seem to apply.

It's physical, in that it says how the text it covers should be presented, rather than what it means, but it's not italics; the man page for the mdoc macro package says

     Text may be stressed or emphasized with the `.Em' macro.  The usual font
     for emphasis is italic.

which sounds like the description of <em> on the mozilla.org site:

	The HTML <em> element (or HTML Emphasis Element) marks text that has stress emphasis. The <em> element can be nested, with each level of nesting indicating a greater degree of emphasis.

	Usage Note: Typically this element is displayed in italic type. However, it should not be used simply to apply italic styling; use the CSS styling for that purpose.

If somebody's using .Em to make something italic for reasons other than stress emphasis, that's presumably because mdoc doesn't offer a macro that does what they really want.  If they explicitly want something displayed in italics, they can use ".ft I" and ".ft"/".ft R", or "\fI" and "\fR"/"\f"; those presumably map to <i> and </i>.

So the second problem doesn't bother me; I suspect we're stuck with impedance mismatches such as that when we're going from mdoc (which isn't a language that describes only low-level rendering) to HTML (which also isn't a language that describes only low-level rendering).

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

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Kristaps Dzonsons]

Hi folks,

I think this conversation is getting a little away with us.  Let's 
please, please keep it simple::

  .Em             <span class="em">
  .Bf -emphasis   <div class="em">
  .Sy             <span class="sy">
  .Bf -symbolic   <div class="sy">
  .Li             <span class="li">
  .Bf -literal    <div class="literal">

Then in CSS,

  .em { font-style: italic; }
  .sy { font-weight: bold; }
  .li { font-family: monospace; }
  div.em, div.sy, div.li { display: inline; }

This should really be stuck in the "default" CSS as I've provided in the 
HTML5 document.  This way, we get consistent use of italics (or whatever 
the CSS override wants) without being tied to <i> (etc.) and it's 
consistent for both the .Bf and .Em versions.

I understand it won't be "semantic", but we already lost that game with 
the ".Bf" versions of the same.  Let's keep semantics where it's 
completely unambiguous, and these messages suggest the contrary!

Best,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: Is there any reason not to use <EM> for items emphasized with .Em?

[Ingo Schwarze]

Hi Kristaps,

Kristaps Dzonsons wrote on Thu, Aug 14, 2014 at 01:24:49AM +0200:

> I think this conversation is getting a little away with us.
> Let's please, please keep it simple::

Makes sense, so i simply reverted my broken commit.

>  .Em             <span class="em">
>  .Bf -emphasis   <div class="em">
>  .Sy             <span class="sy">
>  .Bf -symbolic   <div class="sy">
>  .Li             <span class="li">
>  .Bf -literal    <div class="literal">
> 
> Then in CSS,
> 
>  .em { font-style: italic; }
>  .sy { font-weight: bold; }
>  .li { font-family: monospace; }
>  div.em, div.sy, div.li { display: inline; }

Looks reasonable, even a bit simpler than what we have now.
Go ahead if you want to do that.

> This should really be stuck in the "default" CSS as I've provided in
> the HTML5 document.  This way, we get consistent use of italics (or
> whatever the CSS override wants) without being tied to <i> (etc.)
> and it's consistent for both the .Bf and .Em versions.

Indeed, that's probably a case needing an in-document CSS fallback
because without it and without an external style sheet, it won't
be italic at all.  I think a small amount of in-document CSS fallback
is still better than sticking font-*: display: foo into each and
every element.

> I understand it won't be "semantic", but we already lost that game
> with the ".Bf" versions of the same.  Let's keep semantics where
> it's completely unambiguous, and these messages suggest the
> contrary!

Indeed; regarding the manual, i just argued that we should stop
calling .Em and .Sy semantic at all.

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

Is there any reason not to use <EM> for items emphasized with .Em?

[Guy Harris]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

.Em is documented in the groff_mdoc man page as

   Emphasis Macro
     Text may be stressed or emphasized with the `.Em' macro.  The usual font
     for emphasis is italic.

That sounds like the <EM> HTML tag - the HTML 4.01 spec says

	EM:
	Indicates emphasis.

		...

	The presentation of phrase elements depends on the user agent. Generally, visual user agents present EM text in italics and STRONG text in bold font. Speech synthesizer user agents may change the synthesis parameters, such as volume, pitch and rate accordingly.

Is there any reason not to use that tag for text emphasized with .Em?

If not, see the attached patch.

(BTW, is there anonymous CVS access to the source repository?  I got the top-of-trunk source with a pile of curl calls from the cvsweb site, but that's kind of a pain.)


[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 2733 bytes --]

--- example.style.css.dist	2012-12-18 19:40:25.000000000 -0800
+++ example.style.css	2012-12-20 16:25:33.000000000 -0800
@@ -30,7 +30,7 @@
 div.mandoc i			{ } /* Italic: BI, IB, I, (implicit). */
 div.mandoc b			{ } /* Bold: SB, BI, IB, BR, RB, B, (implicit). */
 div.mandoc small		{ } /* Small: SB, SM. */
-div.mandoc .emph		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
+div.mandoc em			{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
 div.mandoc .symb		{ font-style: normal; font-weight: bold; } /* Symbolic: Sy, Ms, Bf -symbolic. */
 div.mandoc .lit			{ font-style: normal; font-weight: normal; font-family: monospace; } /* Literal: Dl, Li, Ql, Bf -literal, Bl -literal, Bl -unfilled. */
 div.mandoc i.addr		{ font-weight: normal; } /* Address (Ad). */
--- html.c.dist	2012-12-18 19:40:27.000000000 -0800
+++ html.c	2012-12-20 14:40:51.000000000 -0800
@@ -75,6 +75,7 @@
 	{"i",		0 }, /* TAG_I */
 	{"code",	0 }, /* TAG_CODE */
 	{"small",	0 }, /* TAG_SMALL */
+	{"em",		0 }, /* TAG_EM */
 };
 
 static	const char	*const htmlattrs[ATTR_MAX] = {
--- html.h.dist	2012-12-18 19:40:27.000000000 -0800
+++ html.h	2012-12-20 14:41:05.000000000 -0800
@@ -50,6 +50,7 @@
 	TAG_I,
 	TAG_CODE,
 	TAG_SMALL,
+	TAG_EM,
 	TAG_MAX
 };
 
--- mdoc_html.c.dist	2012-12-18 19:40:51.000000000 -0800
+++ mdoc_html.c	2012-12-20 16:26:52.000000000 -0800
@@ -1112,10 +1112,7 @@
 static int
 mdoc_em_pre(MDOC_ARGS)
 {
-	struct htmlpair	tag;
-
-	PAIR_CLASS_INIT(&tag, "emph");
-	print_otag(h, TAG_SPAN, 1, &tag);
+	print_otag(h, TAG_EM, 0, NULL);
 	return(1);
 }
 
@@ -1892,9 +1889,7 @@
 	else if (MDOC_BODY != n->type)
 		return(1);
 
-	if (FONT_Em == n->norm->Bf.font) 
-		PAIR_CLASS_INIT(&tag[0], "emph");
-	else if (FONT_Sy == n->norm->Bf.font) 
+	if (FONT_Sy == n->norm->Bf.font) 
 		PAIR_CLASS_INIT(&tag[0], "symb");
 	else if (FONT_Li == n->norm->Bf.font) 
 		PAIR_CLASS_INIT(&tag[0], "lit");
@@ -1912,6 +1907,10 @@
 	bufcat_su(h, "margin-left", &su);
 	PAIR_STYLE_INIT(&tag[1], h);
 	print_otag(h, TAG_DIV, 2, tag);
+	if (FONT_Em == n->norm->Bf.font) {
+		/* Tag this with <EM>. */
+		print_otag(h, TAG_EM, 0, NULL);
+	}
 	return(1);
 }
 
--- style.css.dist	2012-12-18 19:41:01.000000000 -0800
+++ style.css	2012-12-20 16:24:17.000000000 -0800
@@ -34,7 +34,7 @@
 /* General font modes. */
 
 i		{ } /* Italic: BI, IB, I, (implicit). */
-.emph		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
+em		{ font-style: italic; font-weight: normal; } /* Emphasis: Em, Bl -emphasis. */
 b		{ } /* Bold: SB, BI, IB, BR, RB, B, (implicit). */
 .symb		{ font-style: normal; font-weight: bold; } /* Symbolic: Sy, Ms, Bf -symbolic. */
 small		{ } /* Small: SB, SM. */