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

[Ingo Schwarze <schwarze@usta.de>]

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