Re: [Tools-discuss] Re: rfcmarkup changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tools-discuss] Re: rfcmarkup changes
Hi Frank,
on 2006-07-24 11:44 Frank Ellermann said the following:
> Henrik Levkowetz wrote:
>
>> Does this look good to you all?
>
> No, the old version as near as possible to the "real" document
> 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
> for titles needing more than one line, if only the first line
> 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
> decorations, but please no XHTML. <h1> etc. within <pre> is
> also invalid.
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.
> 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 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.
> 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-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 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.
Tested with validator, added space. Why would this not be valid?
> 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.
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.
> A link to the plain text version would be nice, maybe in the
> 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,
> or is that a workaround for some browsers ?
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.
> 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.
True.
Thanks,
Henrik
> Frank
_______________________________________________
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.
