help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: "Anthony J. Bentley" <anthony@cathet.us>
Cc: discuss@mdocml.bsd.lv
Subject: Re: HTML5
Date: Sun, 10 Aug 2014 17:17:25 +0200	[thread overview]
Message-ID: <20140810151725.GC325@iris.usta.de> (raw)
In-Reply-To: <8860.1407645228@cathet.us>


please take all i say in this thread with a grain of salt,
i'm not specialized in this area and may be wrong.
Hope you will figure it out and correct me.

Anthony J. Bentley wrote on Sat, Aug 09, 2014 at 10:33:48PM -0600:
> Kristaps Dzonsons writes:

>> Most everybody supports HTML5 these days.  Do we really need to knock 
>> around with XHTML and HTML-4.01?  Does anybody have a pressing need to 
>> use one or the other?

> I actively use HTML 4.01. I don't have a real objection against emitting
> a HTML5 doctype, but I do think that it's a good idea for HTML output of
> mandoc to validate against both HTML 4.01 and HTML5.

Why not?  What downside do you see?

> And if we do that, is there any point to switching doctypes?

Yes, one minor and one major.

The minor is less doctype/content-type clutter.
The major is to get MathML for eqn.

That also explains why i think validating against both 5 and 4.01
(for non-eqn content) does have some merit.  Again, if that is
possible, but as far as i understand, it is.

>> The enclosed ten-minute patch adds HTML5 support and makes it the 
>> default for both modes.  It also adds a default CSS style (if one isn't 
>> passed on the command line) identical to OpenBSD's man.cgi CSS.  I don't 
>> like this--I think online manpages should take more advantage of 
>> online-ness--but I'm just putting up the bikeshed so it's ready to 
>> paint.

> IMO, the status quo makes more sense here. We already separate content
> and presentation by only making use of external stylesheets. Since the
> output of mandoc -Thtml is something people are likely to try to parse,
> we shouldn't emit CSS in the default case. If people do ask for CSS,
> emitting a link tag instead of embedding it is the right thing to do.

That makes sense to me; i guess the only exception is cases where
CSS is the only way to make stuff render at all, like for the
header and footer tables, as mentioned by Kristaps.

> I did talk to Ingo recently about man.cgi stylesheets. The stylesheet
> visible on mdocml.bsd.lv is a lot more representative of mandoc's
> abilities and I would like to push to remove the pseudo-man.cgi style
> completely...

That's fine with me.  I don't worry about style changes to the OpenBSD
online man pages.  The style used should be friendly on the eye and
make the semantic markup stand out well, at least as well as for
terminal output, that's all that matters from my perspective.

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

  reply	other threads:[~2014-08-10 15:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-09 23:33 HTML5 Kristaps Dzonsons
2014-08-10  2:23 ` HTML5 Ingo Schwarze
2014-08-10 11:39   ` HTML5 Kristaps Dzonsons
2014-08-10 16:12     ` HTML5 Ingo Schwarze
2014-08-10  4:33 ` HTML5 Anthony J. Bentley
2014-08-10 15:17   ` Ingo Schwarze [this message]
2014-08-10 17:38     ` HTML5 Anthony J. Bentley

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:

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

  git send-email \
    --in-reply-to=20140810151725.GC325@iris.usta.de \
    --to=schwarze@usta.de \
    --cc=anthony@cathet.us \
    --cc=discuss@mdocml.bsd.lv \


* 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).