[Tools-discuss] Re: rfcmarkup changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tools-discuss] Re: rfcmarkup changes
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
_______________________________________________
Tools-discuss mailing list
Tools-discuss at ietf.org
https://www1.ietf.org/mailman/listinfo/tools-discuss
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.