Subject: [Tools-discuss] rfcmarkup changes

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 23 Jul 2006 21:09:15 +0200

Hi,

  I've added a number of changes to the rfcmarkup tool over the last two days,
many of them triggered by Julian Reschke, but some also by the qRFCView program
(see http://www1.tools.ietf.org/inventory/reading-tools).

A number of these changes affect the way the htmlized RFCs and drafts available
from http://tools.ietf.org/html/ are rendered, and I'd like feedback on how the
changes work out.  I've tested the changes under several browsers, including
Firefox, Opera, Lynx and an old version of Explorer on Mac, but that probably
doesn't cover the majority of users, so feedback is needed.

The changes that influence how the HTMLized drafts are rendered also could be
slightly controversial, so also in this respect I'd like you to check out the
changes and provide feedback.

Visual changes:

 * Normalized white-space at the beginning of documents.  The white-space is
   now normalized to 3 blank lines plus the area for obsoleted/updated/errata
   notices at the top.

 * Page header and footer text is now greyed out in the on-screen version.  When
   printing, the headers and footers should appear as normal.

 * Page break css instructions for printing.  This should make modern browsers
   print the documents with correct page breaks.

 * Printed versions of the HTMLized RFCs now don't show the html links as
   underlined blue.

 * Added a visual page break indication (a document-width solid line) in the
   screen view.

 * Document title and section titles are now set in bold, rather than normal
   font.

 * The shortcut icon has been enabled, so if your browser supports it, you
   should see a special shortcut icon indicating an HTMLized RFC.

Does this look good to you all?  Is there anything that should be reverted, or
additional tweaks to add?

Regards,

	Henrik

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 24 Jul 2006 11:44:00 +0200

Henrik Levkowetz wrote:

> Does this look good to you all?

No, the old version as near as possible to the "real" document
was better.  Please get rid of those strange <h1>.  It's ugly
for titles needing more than one line, if only the first line
is big.  Maybe use some fancy CSS colours or classes for such
decorations, but please no XHTML.  <h1> etc. within <pre> is
also invalid.

The page divider lines are unnecessary decorations, please use
CSS classes for such effects.  And please use external CSS, not
inline CSS.  Folks who like this can then create their own "RfC
skins" (shudder).

The class=grey" etc. stuff should be good enough.  You need an
additional id="xyz" whereever you have name="xyz" in anchors.
Maybe replace the dubious self-links href="#xyz" by id="xyz".

The self closing <span class="break"/> is unusual, better don't
use it unless you're 100% sure that it's valid and allowed in
all normative and non-normative XHTML appendices,   If that's
the case you would need <span class="break" /> adding a space.

Your logic to determine the header level is wrong, you should
get exactly one "h1" (to be replaced by a span class), all the
other h1 (now) should be some ersatz-"h2", all h2 should be an
ersatz-"h3", etc. 

A link to the plain text version would be nice, maybe in the
last line.  What's the idea of meta robots nofollow ?  And why
are there two identical link rel icons ?  One should be enough,
or is that a workaround for some browsers ? 

Please add lang="en" xml:lang="en" and the xmlns to the <html>.

The charset=iso-8859-1 is unlikely, if all is well that should
be us-ascii.  At some point in time it will be utf-8.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 Jul 2006 12:32:16 +0200

Hi Frank,

on 2006-07-24 11:44 Frank Ellermann said the following:
> was better.

Hmm.  In that case 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.

> Please get rid of those strange <h1>.  It's ugly
> is big.

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?  The purpose of the <h?/> tags
was covered in my post with subject "Document Map" yesterday,
and is to provide additional functionality, not appearance.

If the <h?/> tags provide text with the same size as the rest
of the doucment, are you OK with the intended appearance change
of making the section titles bold?

>  Maybe use some fancy CSS colours or classes for such

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

> inline CSS.  Folks who like this can then create their own "RfC

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.

> 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.  Providing both id and name is no
problem.

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

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

> other h1 (now) should be some ersatz-"h2", all h2 should be an

Why?  This is not immediately obvious to me.  There is no reason
why there can't be more than one <h1/> level in a document, as
far as I can see??

When you suggest a span class instead of <h?/> you seem to be
assuming that the purpose is cosmetic rather than functional, but
the opposite is the case, as mentioned above, and the spans
would not provide the desired structure information.

> last line.

Good point.  Why not at the top, though?

>  What's the idea of meta robots nofollow ?

Currently, the documents are re-generated on each access, and I'm
worried about the server load if robots follow all the links too
often.  I plan to change this as soon as I've converted to static
files, something I've started working on, but not completed.

>  And why
> are there two identical link rel icons ?

There aren't -

> One should be enough,

There's one with rel="icon", and one with rel="shortcut icon".
And yes, it's a result of browser non-standardization...

> Please add lang="en" xml:lang="en" and the xmlns to the <html>.

Done.

> be us-ascii.  At some point in time it will be utf-8.

True.

Thanks,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Jul 2006 14:26:28 +0200

> decorations, but please no XHTML.  <h1> etc. within <pre> is

What does this have to do with XHTML? <h1> and friends have been around 
since the beginning...

> additional id="xyz" whereever you have name="xyz" in anchors.

Actually, it's better to *replace* "name" by "id".

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

The above notation would be a hack for user agents that do not support 
XHTML (such as IE). I think it's better to not to serve XHTML as HTML, 
but to use HTML4 in the first place.

> other h1 (now) should be some ersatz-"h2", all h2 should be an

Why?

> be us-ascii.  At some point in time it will be utf-8.

Well, if it's ASCII, it will be ISO-8859-1 as well (by definition). On 
the other hand, it may be suboptimal if the charset (as supplied by the 
web server) and the actual charset (as given in the content) disagree.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 Jul 2006 20:18:46 +0200

Hi,

> files, something I've started working on, but not completed.

It's now in place, and seems to work well.  There's now a 404 error
handler script that will attempt to generate any missing htmlized
version of an RFC or draft if the file doesn't exist; otherwise
the file is served from disk.  URLs without an html extension is
handled with http negotiation, resulting in the html file being
served without script intervention.

If you see any anomalies, please let me know.

Best,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 25 Jul 2006 00:17:59 +0200

Julian Reschke wrote:

>> <h1> etc. within <pre> is also invalid.

> What does this have to do with XHTML? <h1> and friends have
> been around since the beginning...

A <h1> etc. within <pre> would be also invalid for HTML 4.01,
The rfcmarkup script creates XHTML 1, that's fine from my POV.

>> You need an additional id="xyz" whereever you have
>> name="xyz" in anchors.

> Actually, it's better to *replace* "name" by "id".

But that would break backwards compatibility for no compelling
reason.  My browser couldn't use id="x" only, without name="x".

>> you would need <span class="break" /> adding a space.

> The above notation would be a hack for user agents that do
> not support XHTML (such as IE).

Yes, XHTML appendices C.2 and C.3 (informative).  It's AFAIK
always possible to get this right, if all else fails simply try
<span class="break"></span>.  Or here add the class="break" to
class="grey" / class="light" in an adjacent non-empty span.

> I think it's better to not to serve XHTML as HTML, but to use
> HTML4 in the first place.

I found that XHTML transitional is the best way to get valid
documents working with "any" browser (for HTML 3.2 or better),
if I stay away from a few HTML 4.01 only contructs like <del>.

>> all the other h1 (now) should be some ersatz-"h2", all h2
>> should be an ersatz-"h3", etc.

> Why?

Because there is excatly one <h1> in a document, before any
following <h2>.  And there's no <h3> without a preceding <h2>,
etc.  "Abusing" <h1> etc. for decorative purposes, e.g. because
<h3> is "nicer" than <h2> with a specific browser, isn't the
idea of these elements.

For some time I did this, abusing <h2> instead of <h1> because
I didn't like the <h1> in my browsers.  But that was stupid.

> Well, if it's ASCII, it will be ISO-8859-1 as well (by
> definition).

Depends, ISO 8859-1 allows to use characters which might be not
available on the other side, a Russian mobile device or another
very odd constellation.  Admittedly Latin-1 used to be the HTML
default long enough - and AFAIK it still is the HTTP default -
that it should work everywhere.

Henrik already fixed it, and one of the three tools servers
doesn't send any inconsistent info in its header - tested with
http://tools.ietf.org/html/rfc2277

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 25 Jul 2006 03:34:53 +0200

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.

> 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

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>

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Jul 2006 09:27:14 +0200

> reason.  My browser couldn't use id="x" only, without name="x".

So your browser doesn't support HTML 4, which has been around since 
1998? But it *does* CSS? I'm confused.

> class="grey" / class="light" in an adjacent non-empty span.

These are the "HTML compatibility guidelines" for people who serve XHTML 
with content type text/html. This is an extremely bad idea in the first 
place. See for instance <http://annevankesteren.nl/2004/06/invalid-html>).

> if I stay away from a few HTML 4.01 only contructs like <del>.

What'S the advantage of HTML 4.01?

> <h3> is "nicer" than <h2> with a specific browser, isn't the

I'm not sure what you're talking about. From 
<http://www.w3.org/TR/html4/struct/global.html#edef-H1>:

"There are six levels of headings in HTML with H1 as the most important 
and H6 as the least. Visual browsers usually render more important 
headings in larger fonts than less important ones."

> I didn't like the <h1> in my browsers.  But that was stupid.

That's stupid if you don't have an <h1> at all. It's also stupid to 
choose elements based on the default rendering they get; that's what CSS 
is for.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Jul 2006 09:41:25 +0200

> for legacy browsers, but maybe it's possible.

Well. At some point the Tools team needs to decide what platforms it is 
supporting. I think it's clearly acceptable to assume HTML 4. Users with 
browsers that haven't been updated since the 1990's can still use the 
authoritative TXT version.

Don't forget that the *purpose* of the HTMLification (IMHO) is to make 
the ASCII versions more accessible/linkable.

>    instead of only ...<hn>...</hn>...

Yes.

>    have their own ideas how to display or use header level 1.

All browsers *I* know (IE, Firefox, Opera) display h1 the way it's 
defined in CSS.

>    disable its side effects doesn't work.

That is simply incorrect. Could you please making assumptions about how 
HTML rendering works based on old and buggy browser implementations?

> anchors, plus some meta data before the original text.

I don't think it's constructive to call something "obscure" which works 
*very* well for many people, and in addition takes advantage of header 
tags exactly the way they've been designed to.

> original look and feel for other browsers, is this desirable ?

Make it "...because one tool can't cope properly with CSS?".

> purpose is, e.g. C.2 and C.16 are important for my browsers.

Again, these are *guidelines* for serving XHTML as text/html. Don't. 
It's that simple.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Jul 2006 12:01:34 +0200

Hi Frank,

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

>    disable its side effects doesn't work.

Bah.  Ok.

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

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

> original look and feel.  No surprise, "pre" means "preserve".

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

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

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

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

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

Ok.  I'll add it.

> 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

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Jul 2006 12:50:21 +0200

Hi Frank,

on 2006-07-25 12:01 Henrik Levkowetz said the following:
[Henrik]
>>> >> subject "Document Map" yesterday

[Frank]
>> > anchors, plus some meta data before the original text.

[Henrik]
> without loosing the added functionality.

Ok, so I just think I worked out a way of keeping the functionality
*and* the original look-and-feel.

Given that, how original should that be?

You indicated earlier that the greying out of the page header/footer
was OK.  Does that still hold?

What about boldfacing the section headers -- no other changes; same
font-size and font-family as the rest of the document, such as in
http://www1.tools.ietf.org/html/rfc4321 ?  Is that desirable or
undesirable?

Hoping to work this out to most people's satisfaction...

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Jul 2006 05:55:08 +0200

Julian Reschke wrote:
 
> your browser doesn't support HTML 4, which has been around
> since 1998? But it *does* CSS?

My "mozilla 3" monster doesn't support CSS, it's a HTML 3.2
browser.  For "good" pages that's no problem, I don't get the
decorations, working as designed.  

If the effect of say class=grey" is ugly I won't see it.  The
source says #777 for .grey, and #ccc for .light, the latter
would be almost invisible on a silver background, this might
be a missing background colour problem, but I can't judge it,

  [XHTML appendix C]
> These are the "HTML compatibility guidelines" for people who
> serve XHTML with content type text/html.

Yes.

> This is an extremely bad idea in the first place.

No, it's a clear MAY.  If you want no backwards compatibility
at all you could use XHTML 1.1 instead of 1.0 transitional,
for XHTML 1.1 and BASIC sending text/html is a SHOULD NOT.

> <http://annevankesteren.nl/2004/06/invalid-html>

Yes, some folks don't like XHTML 1.0 transitional... <shrug />
My browsers don't support HTML, no </> and other SGML tricks,
and I like the simply structure of XHTML.  Admittedly I would
not know how to get inline <style> or <script> elements right
with XHTML, but it's possible.  It's not as simple as in the
rfcmarkup output.  

It "works" (= no visual effect) for me as is, but probably it's
better to move this stuff into an external style sheet later -
devices not using CSS are also not interested to download it.

> What'S the advantage of HTML 4.01?

Wait a moment, you're advocating HTML 4, and I prefer XHTML 1,
limited to what works with 3.2 browsers, so this is the wrong
question... :-)

Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Jul 2006 07:10:06 +0200

Julian Reschke wrote:

> Don't forget that the *purpose* of the HTMLification (IMHO)
> is to make the ASCII versions more accessible/linkable.

As it did until Saturday, turning some pieces of text into
links, adding some anchors, and a header with meta data, but
keeping anything else as is.  The look and feel of the real
draft or RFC.

> All browsers *I* know (IE, Firefox, Opera) display h1 the way
> it's defined in CSS.

Testing CSS is simple, it still has to work if you disable it.
It's for decorations, not for hacks trying to disable whatever
browsers "normally" do with <h1>.  Nobody knows what "normal"
is, e.g. with my browsers it breaks the original ASCII layout.

A <center><h1><small><small><small><tt> hack to "disable" <h1>
without CSS for these browsers probably has horrible effects
with other browsers.  It's not possible to retrofit <h1> into
<pre> working for any browser.

> That is simply incorrect. Could you please making assumptions
> about how HTML rendering works based on old and buggy browser
> implementations?

That's no assumption, that's what I get.  And the behaviour is
correct, displaying <h1> like <center><big><big><big><strong>
is perfectly legal.  It's not the only possibility to display
<h1>, therefore "disabling" <h1> with <small> and what else is
no plan.  "Disabling" <h1> with CSS is also no plan, because it
has to work with any browser, also without CSS.

> I don't think it's constructive to call something "obscure"
> which works *very* well for many people

Breaking it for others.  Rfcmarkup should work for any browser,
not only for IE or for FF.  And AFAIK that was the case until
Saturday.

> in addition takes advantage of header tags exactly the way
> they've been designed to.

If they'd be designed to work within <pre> they'd be allowed
within <pre>, but that's not the case.  <span> is designed to
work within <pre>, it can add classes for additional magic.
 
> Make it "...because one tool can't cope properly with CSS?".

The basic CSS test is to disable it.
  
> these are *guidelines* for serving XHTML as text/html. Don't.
> It's that simple.

Rfcmarkup tries to create output for any browser, otherwise it
could create PDF or XHTML 1.1.  And that worked until Saturday,
it's no rocket science.  With the XHTML advantage that you find
the closing tag for any given tag (or an error) with closed
eyes.  If the "price" for that advantage is to add a space
before all "/>" plus a few other rules it's cheap.

Bye

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Jul 2006 09:06:43 +0200

Henrik Levkowetz wrote:

>> No surprise, "pre" means "preserve".

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

ACK, probably I confused this with the xml:space="preserve"
for <pre>.  Not allowed elsewhere in XHTML 1.  It's an odd
test for XHTML validators, they have to accept this for <pre>.

> documents with one-line headers.

My copy of Lynx has some "LSS" files where the behaviour for
various tags is defined.  I never touched it, but it's cute,
it uses the "colour" for <big> for a nested <small><big><big>.

If you also never touched it you have another version or more
likely a monochrome or dumb terminal emulation.  Something like
SET TERM=ANSI could change this, or show_color=always in the
.lynxrc settings (same effect as option -color).  Apparently I
use both show_color=always and SET TERM=OS2 (whatever that is),
the Lynx docu says that it also depends on the compilatation.

> 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 can't tell, it certainly "works" (= no visual effect) for me.
Is <span class="break"></span> anywhere different from a self-
closing "not recommended" <span class="break" /> ?

 [link to plain text]
> I'll add it.

Thanks, I had completely forgotten that I only have to replace
"html" by "id" in the URL.  The tools page doesn't mention this,
or I didn't find it, therefore I tried to use the ID-tracker to
update some drafts in my "collection", but that was so clumsy
that I somehow managed to recall the "id" URL for this purpose.

Maybe I need a script for this, input a directory with drafts,
strip trailing *-nn.txt, request HEAD .../id/draft-..., the
tools server then tells me what's state of the art, and if it's
better than my *-nn.txt GET it.

Your second message:
> You indicated earlier that the greying out of the page
> header/footer was OK.  Does that still hold?

It has no visual effect for legacy browsers, therefore it can't
cause harm for such browsers.  What if a popular browser uses
an almost silver background ?  Your class="light" could end up
as almost invisible, to some degree that's probably the idea.

If you want guaranteed contrasts maybe set a white background.

Probably you can get rid of the one class="pre", and apparently
you don't need class="light" and class="hr" anymore.   You have
definitions for h7, h8, and h9.  AFAIK there are no such tags,
the smallest header level is h6.

> What about boldfacing the section headers -- no other
> changes; same font-size and font-family as the rest of the
> document, such as in http://www1.tools.ietf.org/html/rfc4321 ?
> Is that desirable or undesirable?

Works for me, also with Lynx, but still only the first line of
the title.  Lynx desperately trying to do "something" with <b>
displays it as red.  I've screenshots of style tags with four
different legacy browsers, for Lynx see

http://purl.net/xyzzy/pub/struck_2.jpg

The section number (<a> within <b>) is green with my Lynx, no
problem.  All anchors are green, also the references.

Bye

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Jul 2006 10:09:00 +0200

> has to work with any browser, also without CSS.

Well, let me disagree here. I think it's perfectly reasonable to use CSS 
in a way that's compatible with the almost all user agents *in use*.

> work within <pre>, it can add classes for additional magic.

I didn't argue with the statement that the HTML should be valid 
according to the HTML DTD. I was arguing with the assumptions that it's 
useless to use the proper semantic markup, just because the same 
*visual* effect can be achieved with <span>.

> before all "/>" plus a few other rules it's cheap.

How is that an advantage? The markup is generated by a script (not a 
human), and consumed by user agents (not humans). (No, I don't argue the 
benefits of XHTML over HTML, I just don't see those *here*).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Jul 2006 10:15:57 +0200

> test for XHTML validators, they have to accept this for <pre>.

This seems to be incorrect (see for instance 
<http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict#dtdentry_xhtml1-strict.dtd_style>).

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 26 Jul 2006 14:22:43 +0200

Hi Frank,

> test for XHTML validators, they have to accept this for <pre>.

Right.

> the Lynx docu says that it also depends on the compilatation.

I get colours, but not the same colours as you.  Not terribly
important.  I have TERM=xterm-color.

> closing "not recommended" <span class="break" /> ?

Doesn't matter to me.  I can do a separate close.

> better than my *-nn.txt GET it.

Sounds like a nice little utility :-)

> If you want guaranteed contrasts maybe set a white background.

Right.  I'm removing the 'light' class anyway.

> the smallest header level is h6.

I've run into drafts with more than 6 levels, so I guess I'll
just let them stay - I don't see any harm in it.

> different legacy browsers, for Lynx see

Ok.  I'll probably do the boldface with a stylesheet command,
instead of <b/>.

> http://purl.net/xyzzy/pub/struck_2.jpg

Ah, thanks.

> problem.  All anchors are green, also the references.

Ok.

Regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Jul 2006 14:32:20 +0200

> just let them stay - I don't see any harm in it.

Well, only h1..h6 are defined in HTML. So I wouldn't want to use 
anything except that.

Best regards, Julian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 28 Jul 2006 11:46:55 +0200

> <http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict#dtdentry_xhtml1-strict.dtd_style>).

Oh, yes, also for <style> and <script>, not only <pre>, I tend
to forget those two because I don't use them.  With the same
restriction as for <pre>, the xml:space="preserved" can't be
modified.

In another message (h7 / h8 / h9):  ACK, the rfcmarkup output
should be valid, it's not that we disagree about everything ;-)

In a third message about XHTML and CSS in general:

> I think it's perfectly reasonable to use CSS in a way that's
> compatible with the almost all user agents *in use*.

Disabling CSS for testing is a remommended WAI technique.  If
you end up with something that simply doesn't work without CSS
it's not only some stoneage browsers which might be affected,
it could also hurt state of the art mobile devices.  

Admittedly I've no clear idea how to define "original RFC look
and feel" wrt mobile devices.

> The markup is generated by a script (not a human), and 
> consumed by user agents (not humans). (No, I don't argue the

You're the author of tools doing interesting stuff with XML -
do these tools also work with similar SGML ?  The one time I
tried to parse XHTML "manually" (writing a script) I was very
happy that it was "only" XHTML and not HTML.

Bye, Frank

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jul 2006 11:56:52 +0200

> it could also hurt state of the art mobile devices.  

Semantics markup instead of div/span is something that actually *helps* 
accessibility. If browsing the HTML version of an RFC on a mobile device 
with no CSS support shows headers in a bigger font, I really really 
couldn't care less.

> do these tools also work with similar SGML ?  The one time I

No.

> happy that it was "only" XHTML and not HTML.

But why would you want to parse the output of the RFCmarkup script in 
the first place? I'd really like to understand the use case?

Best regards, Julian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 28 Jul 2006 13:49:44 +0200

Julian Reschke wrote:

> why would you want to parse the output of the RFCmarkup
> script in the first place? I'd really like to understand
> the use case?

I'm not planning to do something with it.  Stuff somebody
else might wish to try is to evaluate links and anchors in
some way.  The output is of course simple enough to get it
right also for a hypothetical HTML version.

Probably Henrik uses some general procedures to create the
XHTML, and there might be more interesting output cases than
rfcmarkup, where XHTML instead of HTML is a serious advantage.

Now I dare test JavaScript 1.1 enabled:  Only two errors, no
visual effect, no browser crash, good.

1035 has an IEN-116 reference, and I vaguely recall that this
is available at the RfC editor...  yes, here:

ftp://ftp.isi.edu/in-notes/ien/ien116.txt

The rfcmarkup link creator could resolve these IEN references.

Bye, Frank

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jul 2006 14:34:44 +0200

> visual effect, no browser crash, good.

Why aren't you simply using Firefox, instead of insisting on 
non-maintained browsers?

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 28 Jul 2006 15:14:32 +0200

Hi Frank,

on 2006-07-28 13:49 Frank Ellermann said the following:
> [...]

Good to hear.

> The rfcmarkup link creator could resolve these IEN references.

Added to the TODO list.

Regards,

	Henrik