[Tools-discuss] Re: rfcmarkup changes

[Frank Ellermann <nobody at xyzzy.claranet.de>]

Henrik Levkowetz wrote:

> I probably have to provide two versions, as there seems to
> be too many things you comment on below for which there are
> functional (not appearance) reasons.

Maybe, but there are already many sites and tools "beautifying"
(= "mutilating" in my terminology) RFCs like faqs.org or the
HTML output of xml2rfc.  And xml2rfc is better suited for this
task, it has the complete meta data - that's the only part I
missed in the old rfcmarkup output.

> The style sheet makes all the <h?/> tags the same size as the
> rest of the text - which browser did you use which made them
> big, and can we find a workaround?

None of my four browsers support CSS, for Netscape 4.x because
I disabled its strange implementation baseed on JSS.  I never
tried to use header elements avoiding all their side effects
for legacy browsers, but maybe it's possible.

1: For valid (X)HTML you'd need ...</pre><hn>...</hn><pre>...
   instead of only ...<hn>...</hn>...
2: <h1> is probably hopeless, all browsers I know and googlebot
   have their own ideas how to display or use header level 1.
3: <h2> it roughly (!) the same as <big><big> with my browsers,
   see also <URL:http://purl.net/xyzzy/strikedel.htm#h2>  If
   that's also the case elsewhere you could try to "diasable"
   it with <h2><small><small><tt>...</tt></small></small></h2>,
   similar <h3><small><tt>...</tt></small></h3>, disabling <h4>
   needs only <tt>, for <h5> you get <big><tt>, and finally you
   hit <h6><big><big><tt>...</tt></big></big></h6>

   This would still shift headers to the left margin.  In the
   case of RFCs maybe some columns too much, I didn't test it.
   An ugly hack, better forget it, it's broken by design.

   There simply is no <hn> in monospaced US ASCII plain text,
   and retrofitting <hn> into these documents with CSS hacks to
   disable its side effects doesn't work.

> The purpose of the <h?/> tags was covered in my post with
> subject "Document Map" yesterday

Okay, some obscure plugin for a browser I don't and can't use,
I read his message.  But until yesterday rfcmarkup preserved
the original ASCII look and feel, adding working links and
anchors, plus some meta data before the original text.

Apparently we disagree about the purpose of this HTML tool.
I could get "enhanced" RFCs at faqs.org if I'd want them.

> I started using <div style="white-space:pre">, but that
> broke lynx, so in order to support text-mode browsing with
> lynx I chose to be pragmatic rather than pure.

It was perfect until Saturday - probably it was also valid, I
never had a reason to check this.   You can try <span> magic
within <pre>, but as soon as you leave <pre> you've lost the
original look and feel.  No surprise, "pre" means "preserve".

AFAIK <pre> is the only element where an xml:space="preserve"
attribute is allowed - and pointless, it's implied by <pre>.

> The page divider lines can be skipped altogether if people
> don't like them.  The main reason to use the current
> implementation was again to provide support for lynx.

I'm no regular Lynx user, I only start it for testing, or for
very strange cases (like idnits) where my Netscapes both fail.

If I test http://tools.ietf.org/html/4408 with Lynx the result
is ugly, a yellow on blue "Sender Policy Framework (SPF) for
<h1>, then two blank lines, followed by the rest of the real
header, here "Authorizing Use of Domains in E-Mail, Version 1".

If you want to disable all <h1> side effects for this and other
browsers you need the complete "real" header (here two lines),
something in this direction:

<div align="center"><h1><small<small><small><tt>1st line<br />
2nd line</tt></small></small></small></h1></div>.  Or maybe try
<center> instead of <div align="center">, my source claims that
the browser support for <center> is better.

But <center><h1><small><small><small><tt> only because one tool
can do interesting things with <h1>, potentially destroying the
original look and feel for other browsers, is this desirable ?

>> Maybe replace the dubious self-links href="#xyz" by id="xyz"

> The self-links were on request, I can loose them if most
> people don't like them.  The purpose is to show that there is
> an anchor here which you can link to.

That should be obvious in the ToC, and guessing the format of a
few anchors not mentioned in the ToC like #page-1 is no rocket
science.  In <URL:http://purl.net/xyzzy/usefor07.htm> I tried
a "manual XHTML-ficication" some years ago, and there I linked
all "[page nn]" to the ToC (allowing to skip the boilerplate
before the ToC from any page).  Not important, only an idea.

>> If that's the case you would need <span class="break" />
>> adding a space.

> Tested with validator, added space.  Why would this not be
> valid?

Now I checked it, <URL:http://www.w3.org/TR/xhtml1/#guidelines>
appendix C,3 says "don't" - maybe some browsers don't like it,

My favourite browser doesn't know what a <span> is, self-closed
or not, so from my POV it's only a theoretical problem.  But I
wouldn't dare violate a guideline where I've no clue what its
purpose is, e.g. C.2 and C.16 are important for my browsers.

> There is no reason why there can't be more than one <h1/>
> level in a document, as far as I can see??

I've forgotten where I "learned" that, maybe it's wrong.  It's
not in the QA tip <http://www.w3.org/QA/Tips/Use_h1_for_Title>

> When you suggest a span class instead of <h?/> you seem to be
> assuming that the purpose is cosmetic rather than functional,

Maybe "breaking the original look and feel of the documents for
the functionality offered by an obscure plugin for one specific
browser while hurting others" is more precise, but it doesn't
change the issue.

>> A link to the plain text version would be nice, maybe in the
>> last line.

> Good point.  Why not at the top, though?

Also fine, I'd use it rarely, download for offline reading.

> one with rel="icon", and one with rel="shortcut icon".

Yes, I thought that rel="shortcut icon" is a space-separated
enumeration of relations, same idea as for a class=, checking:

http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html#LinkTypes

> And yes, it's a result of browser non-standardization...

The URL for both icon relationships is the same, this probably
works as expected.  If the browsers wanting the separate "icon"
link also support PNG as favicon, I can't tell what old IEs do.

Bye, Frank



_______________________________________________
Tools-discuss mailing list
Tools-discuss at ietf.org
https://www1.ietf.org/mailman/listinfo/tools-discuss