Re: [Tools-discuss] Re: rfcmarkup changes

[Henrik Levkowetz <henrik at levkowetz.com>]

Hi Frank,

on 2006-07-26 09:06 Frank Ellermann said the following:
> 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>.

Right.

>> I don't get the colour effects, but it seems I've only tested
>> 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.

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

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

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

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

Sounds like a nice little utility :-)

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

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

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

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.

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

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

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

Ah, thanks.

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

Ok.

Regards,

	Henrik

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