Re: HTML5

[Kristaps Dzonsons <kristaps@bsd.lv>]

Ingo, Anthony,

> Let me put it this way:  We should not use any fancy features.
> If somebody has a browser that doesn't know about HTML versions
> and just assumes everything is HTML 4 without looking at any
> document types and stuff, then the pages should render cleanly.
> Whether or not they validate as HTML 5 seems irrelevant to me.
>
> Supporting multiple HTML variants seems pointless to me and just
> complicates the code.

I agree.  In short, unifying under HTML5 will simplify the code (no 
switching)--that much is clear.  I don't care whether it's HTML5 or 
asciidoc so long as it gets the job done.  And for browsers, it's 
between flavours of HTML.  So let's consider why HTML5 instead of just 
HTML4 or XHTML1 as-is.

First, note that the patch's HTML5 is called "polyglot" HTML5, which is 
to say, HTML5 with XML syntax.

(Link: <http://dev.w3.org/html5/html-polyglot>.)

A "pro" is that polyglot HTML5 has the same doctype *and content type* 
for its XHTML and HTML modes.  So we can create well-formed, parseable 
HTML5 mark-up using strict XML syntax, then serve it with text/html and 
be happily standards-compliant.  As it is, we put a burden on the agency 
serving -Thtml or -Txhtml pages to know the difference.

The "con" is that by unifying -Thtml/xhtml as HTML5--or anything, 
really--we lose strict HTML4 callers of -Ofragment (XHTML1 callers would 
be fine).  The only caller right now is cgi.c, which stipulates HTML4. 
This can be fixed easily: remove the HTML4 parts of to cgi.c's DOCTYPE 
and close the void img, meta, and link elements.  See the "pro" above 
for why that's also a smart idea.

Another "pro" is that we get eqn.  Ingo, this is the "feature" you're 
worried about.  And it's a pretty big issue for me (so this is a "for 
me"): all of my equations (in eqn, or really in DocBook--which I use 
with docbook2mdoc for some scientific applications--which I'd like to 
convert into eqn) are lost.  Also lost are LAPACK manuals, OpenGL, and a 
host of other eqn systems.  If we stick to HTML4, we'd need to cripple 
ourselves with table-based equations.  If we stick with XHTML1, we need 
to jump through namespace hoops.  But with HTML5, we get embedded MathML.

The "con", yes, is that MathML is a scary feature, and it doesn't exist 
yet.  YET.

At the end of the day, the browser doesn't really care whether it's 
HTML4, XHTML1, or HTML5.  It'll render regardless.  Callers of 
-Ofragment will care, but right now that's just us.  Ingo, you mentioned 
non-conforming browsers.  Care to point me to one that will puke on the 
HTML5 output from the patch?  Even lynx(1) can read that!

If we're really at loggerheads over it, /adding/ HTML5 is as easy as 
another switch statement of two.  I think it's a good idea regardless of 
whether it's added or replacing for the reasons above.

...on to other matters: the style-sheet.

The status quo bugs me because of the header and footer table.  These 
have hard-coded widths and alignments to make them look decent without a 
stylesheet.  This is inadvisable in any modern flavour of HTML.  At the 
very least, we should replace the "width" and "height" for embedded 
styles.  Unfortunately, that's a problem: inline styles can't be 
overriden without the "!important" qualifier in CSS, which is annoying. 
  (That's why I used the width attributes in the first place.)  So I 
think that putting just the table styles *before* the <link stylesheet 
/> is a good idea.  The question goes: if we're going to do that, is 
there anything else that should go there?

The stylesheet I put in place does serve an important purpose: it 
prevents overriding styles.  In man(7) and mdoc(7), for example, you 
can't have overlapping styles.  E.g.,

.Bf Sy
Hi
.Ar there
.Ef

The "there" doesn't have both styles: they reset when they're nested. 
(There are probably better ways to do it in CSS, but it needs to be done 
one way or another.)  Without some sort of style-sheet, font modes will 
be nested.  Yes, I'm at conflict with myself: on the one hand, mdoc(7) 
does this because consoles generally haven't supported overlapping 
fonts, and I don't like console hold-vers in HTML output.  Or should we 
discard that convention?  (groff's -Tps does it too!)

And yes, I agree that we should just have a single stylesheet in the 
source.  I don't particularly care what it shows.

Best,

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