Marshall,
of course the ability to point to a particular section is much more
important than to have that on paragraphs as well.
For the sake of testing, I've added a HTML title attribute to every
element which has an automatically generated anchor (this will produce a
tooltip when hovering over the paragraph), but I'm not sure that this a good
application of the title attribute.
What *is* important is that the generated anchors are named consistently.
For the record, here's what I'm using (I don't have problems changing the
syntax...):
numbered figures: rfc.figure.
unnumbered figures: rfc.figure.u.
sections: rfc.figure. (no trailing ".")
copyright: rfc.copyright
index: rfc.index
toc: rfc.toc
authors: rfc.authors
references: rfc.references
(open issues as in my editing extensions): rfc.issue.
Things to consider:
1) Standardizing the link name for "informative references"
2) Change the prefix to reduce the risk of name collisions (start with "_"?)
Julian
> -----Original Message-----
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Saturday, March 02, 2002 8:05 PM
> To: Julian Reschke
> Cc: xml2rfc@lists.xml.resource.org
> Subject: Re: [xml2rfc] Proposal: consistent labeling of sections (and
> paragraphs) when producing HTML
>
>
> julian -
>
> 1. the problem with per-paragraph anchoring is the fact that it's
> not visible on the page, and depending on how the viewer chooses
> to render either the xslt or html output, the indentation can
> move around a bit. when looking at the same html with konqueror,
> netscape, and ie, there is a noticable different in how things like
>
> ......
...
>
> get rendered. so, unless the graf is visually labelled in the
> rendering, there's just no way that a random person can look at
> the output and say ("that's paragraph 3").
>
> the only thing worse than not anchoring each paragraph is to
> confuse people, so i'd really prefer not to agree on a convention
> for that. you're free to keep doing so, of course, i'd prefer not to.
>
> 2. as i said in my reply, i can live with anchoring each section,
> providing that it does not interfere with the author's own
> anchoring. so, i'll implement your convention of
>
> "rfc.section."
>
> this weekend.
>
> /mtr
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@lists.xml.resource.org
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>
From: GK@ninebynine.org (Graham Klyne)
Date: Sun, 03 Mar 2002 10:22:36 +0000
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <20020302000801.645410ba.mrose@dbc.mtview.ca.us>
References: <20020226231731.65f659fe.mrose@dbc.mtview.ca.us>
Message-ID: <5.1.0.14.2.20020303101957.0392eec0@joy.songbird.com>
I sometimes use a utility (htmltoc) to generate a toc for an HTML document
from tags... it works by detecting and using any section anchors that
the autor has defined, and generating a "random" anchor name where they aren't.
#g
--
At 12:08 AM 3/2/02 -0800, Marshall Rose wrote:
>ancoring each section is viable, but it shouldn't interfere with the
>author picking their own anchors. this means that we'll end up putting two
>anchors in some places. that's fine, i guess...
------------
Graham Klyne
GK@NineByNine.org
From: mrose@dbc.mtview.ca.us (Marshall Rose)
Date: Sat, 2 Mar 2002 11:05:03 -0800
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To:
References: <20020302000801.645410ba.mrose@dbc.mtview.ca.us>
Message-ID: <20020302110503.4fb2fce2.mrose@dbc.mtview.ca.us>
julian -
1. the problem with per-paragraph anchoring is the fact that it's not visible on the page, and depending on how the viewer chooses to render either the xslt or html output, the indentation can move around a bit. when looking at the same html with konqueror, netscape, and ie, there is a noticable different in how things like
......
...
get rendered. so, unless the graf is visually labelled in the rendering, there's just no way that a random person can look at the output and say ("that's paragraph 3").
the only thing worse than not anchoring each paragraph is to confuse people, so i'd really prefer not to agree on a convention for that. you're free to keep doing so, of course, i'd prefer not to.
2. as i said in my reply, i can live with anchoring each section, providing that it does not interfere with the author's own anchoring. so, i'll implement your convention of
"rfc.section."
this weekend.
/mtr
From: julian.reschke@gmx.de (Julian Reschke)
Date: Sat, 2 Mar 2002 11:46:49 +0100
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <20020302000801.645410ba.mrose@dbc.mtview.ca.us>
Message-ID:
> From: xml2rfc-admin@lists.xml.resource.org
> [mailto:xml2rfc-admin@lists.xml.resource.org]On Behalf Of Marshall Rose
> Sent: Saturday, March 02, 2002 9:08 AM
> To: xml2rfc@lists.xml.resource.org
> Cc: julian.reschke@gmx.de
> Subject: Re: [xml2rfc] Proposal: consistent labeling of sections (and
> paragraphs) when producing HTML
>
>
> > When a section does provide an anchor attribute, xml2rfc already inserts
> > that name as HTML anchor name. I'd like to propose that the HTML version
> > contains anchors for *all* sections, even if the source does
> not contain an
> > anchor attribute.
> >
> > For instance, rfc2629.xslt produces
> >
> > "rfc.section." for each section
> >
> > "rfc.section..p." for
> each paragraph
> >
> > I think it would be a good thing if rfc2629 would specify a
> standard format
> > for this, so that one can rely on this naming convention no
> matter *which*
> > rfc2629 processor has produced the HTML version.
>
> an interesting idea, but i don't know if it will work in practice.
It's working just fine for me -- I'd just have it working reliably across
xml2rfc implementations...
> to begin, anchoring each paragraph isn't all that helpful unless
> you can easily look at a document and figure out the tag
> associated with each paragraph...
That's a good point. For me it was good enough to know that for
"rfc.section.1.2.3", the second paragraph will be "rfc.section.1.2.3.p.2".
Of course one could consider adding some HTML markup that allows you to
discover this easier.
> ancoring each section is viable, but it shouldn't interfere with
> the author picking their own anchors. this means that we'll end
> up putting two anchors in some places. that's fine, i guess...
That's no problem.
What is a problem is avoiding name conflicts -- but this is already an issue
with xml2rfc. I think just defining that anchors with the prefix "rfc"
aren't available to authors would do.
From: mrose@dbc.mtview.ca.us (Marshall Rose)
Date: Sat, 2 Mar 2002 00:08:01 -0800
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To:
References: <20020226231731.65f659fe.mrose@dbc.mtview.ca.us>
Message-ID: <20020302000801.645410ba.mrose@dbc.mtview.ca.us>
> When a section does provide an anchor attribute, xml2rfc already inserts
> that name as HTML anchor name. I'd like to propose that the HTML version
> contains anchors for *all* sections, even if the source does not contain an
> anchor attribute.
>
> For instance, rfc2629.xslt produces
>
> "rfc.section." for each section
>
> "rfc.section..p." for each paragraph
>
> I think it would be a good thing if rfc2629 would specify a standard format
> for this, so that one can rely on this naming convention no matter *which*
> rfc2629 processor has produced the HTML version.
an interesting idea, but i don't know if it will work in practice.
to begin, anchoring each paragraph isn't all that helpful unless you can easily look at a document and figure out the tag associated with each paragraph...
ancoring each section is viable, but it shouldn't interfere with the author picking their own anchors. this means that we'll end up putting two anchors in some places. that's fine, i guess...
/mtr
From: mrose@dbc.mtview.ca.us (Marshall Rose)
Date: Fri, 1 Mar 2002 14:54:50 -0800
Subject: [xml2rfc] HTML version: Upper-case URIs
In-Reply-To: <4.2.0.58.J.20020301184346.03f26eb8@localhost>
References: <4.2.0.58.J.20020301184346.03f26eb8@localhost>
Message-ID: <20020301145450.732b93b2.mrose@dbc.mtview.ca.us>
> Hello Marshall,
>
> I just saw that in the HTML output, URIs appear as uppercased.
>
> The uppercasing convention may be useful for some other place, but for
> URIs, it's very counterproductive.
>
>
> Many thanks and kind regards, Martin.
ok. it will be in the next release.
/mtr
From: julian.reschke@gmx.de (Julian Reschke)
Date: Fri, 1 Mar 2002 15:49:09 +0100
Subject: [xml2rfc] Proposal: consistent labeling of sections (and paragraphs) when producing HTML
In-Reply-To: <20020226231731.65f659fe.mrose@dbc.mtview.ca.us>
Message-ID:
Hi,
IMHO, one of the most useful features of the HTML version of a draft/RFC is
the ability to link to a specific section.
When a section does provide an anchor attribute, xml2rfc already inserts
that name as HTML anchor name. I'd like to propose that the HTML version
contains anchors for *all* sections, even if the source does not contain an
anchor attribute.
For instance, rfc2629.xslt produces
"rfc.section." for each section
"rfc.section..p." for each paragraph
I think it would be a good thing if rfc2629 would specify a standard format
for this, so that one can rely on this naming convention no matter *which*
rfc2629 processor has produced the HTML version.
Julian
From: duerst@w3.org (Martin Duerst)
Date: Fri, 01 Mar 2002 22:14:47 +0900
Subject: [xml2rfc] HTML version: Upper-case URIs
Message-ID: <4.2.0.58.J.20020301184346.03f26eb8@localhost>
Hello Marshall,
I just saw that in the HTML output, URIs appear as uppercased.
But URIs are in general case-sensitive. Actually,
http://www.ietf.org/shadow.html and
HTTP://WWW.IETF.ORG/SHADOW.HTML are different URIs.
If the user copies the later rather than the former, it won't work.
Even if this is only done with css style, it's not a good idea,
because users copy URIs from and to paper.
So please change:
A:link { color: #990000; font-size: 10px; text-transform: uppercase;
font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica,
arial, sans-serif }
A:visited { color: #333333; font-weight: bold; font-size: 10px;
text-transform: uppercase;
font-family: MS Sans Serif, verdana, charcoal, helvetica,
arial, sans-serif }
A:name { color: #333333; font-weight: bold; font-size: 10px;
text-transform: uppercase;
font-family: MS Sans Serif, verdana, charcoal, helvetica,
arial, sans-serif }
to:
A:link { color: #990000; font-size: 10px; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica,
arial, sans-serif }
A:visited { color: #333333; font-weight: bold; font-size: 10px;
font-family: MS Sans Serif, verdana, charcoal, helvetica,
arial, sans-serif }
A:name { color: #333333; font-weight: bold; font-size: 10px;
font-family: MS Sans Serif, verdana, charcoal, helvetica,
arial, sans-serif }
The uppercasing convention may be useful for some other place, but for
URIs, it's very counterproductive.
Many thanks and kind regards, Martin.