Re: [Tools-discuss] Re: rfcmarkup changes

[Henrik Levkowetz <henrik at levkowetz.com>]

Hi Frank,

on 2006-07-25 03:34 Frank Ellermann said the following:
> 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.

Yes.  My purpose was very definitely _not_ to change the layout
by adding headers in different fonts and sizes - I find that
distracting when reading RFCs.

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

Bah.  Ok.

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

I still want to preserve the original ASCII look and feel, and
I'm sorry not to have managed to do that for all users in this
case.  I'm looking into ways of reverting to the proper look
without loosing the added functionality.

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

I assume that by "enhanced" you mean with changed look and feel,
in this case ;-)  .  Yes, I understand.

>> 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".

I've always thought it meant 'preformatted'.  But that doesn't
really matter here.

> 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".

I don't get the colour effects, but it seems I've only tested
documents with one-line headers.

> 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 ?

I don't know where the trade-off is here.  The tests I did showed
a preserved look-and-feel, but obviously they were incomplete.

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

But the only purpose of this span is to provide print page breaks
using CSS; so as long as older browsers ignore the <span /> we
should be fine, no?  (I've added the trailing space, that's easy.)

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

Ok.  I'll add it.

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

Right.  The worst case behaviour is that they don't get the favicon,
no big problem.


Regards,

	Henrik

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