Looking for Help with FAQ

G

Garrett Smith

It has been noted that the "notes" url is unmemorable. The current url
for the notes:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

It was proposed to provide a better URL for the notes. The proposed path
would be:- /faq/notes/ - defaulting to index.html.

URLs need to be current to the FAQ and should use relative paths. This
makes the pages more portable. For example, a link:
href="http://jibbering.com/faq/#FAQ4_4", should be changed to:
href="/faq/#testCookie"

After all files have been fixed, the FAQ can link to the new index page.

It is a lot of tedious work. If anyone is interested in pitching in on
this, please contact me.

Garrett
 
R

Richard Cornford

It has been noted that the "notes" url is unmemorable.

So what? URLs are not things that are required to be memorable.
The current url for the notes:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

It was proposed to provide a better URL for the notes.

That would be a very subjective judgment of what would be better. I
would regard the change as pointless effort with no real benefit and
much potential disadvantage, so not "better".
The proposed path
would be:- /faq/notes/ - defaulting to index.html.

So you intend doubling up (at least one page of) the notes? Because
currently the archives, many third party web pages and numerous books,
reference notes pages using the current URLs, so making the pages
unavailable from their current URLs will not be doing anyone any
favours.
URLs need to be current to the FAQ and should use relative paths.

They did use relative paths.
This makes the pages more portable. For example, a link:
href="http://jibbering.com/faq/#FAQ4_4", should be changed
to: href="/faq/#testCookie"

Not necessarily. The FAQ should never have been changed in a way that
made the fragment identifier #FAQ4_4 ineffective as the archives are
full of references to the FAQ that use that style of fragment
identifier that should never have been broken by modifications to the
FAQ (otherwise the archives are diminished as a resource). After all,
even if there is no longer a section 4.4 there is no reason why the
answer it once contained could not be tagged with the fragment
identifier "FAQ4_4".

If modifications to the FAQ didn't invalidate the references to the
FAQ in the archives they would not invalidate the URLs in the notes.
After all files have been fixed, the FAQ can link to the new
index page.

It is a lot of tedious work. If anyone is interested in pitching
in on this, please contact me.

The notes pages use very simple and uniform mark-up. Mechanically
transforming the URLs would be trivial.

Richard.
 
T

Thomas 'PointedEars' Lahn

[posted & mailed]

Garrett said:
It has been noted that the "notes" url is unmemorable. The current url
for the notes:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

It was proposed to provide a better URL for the notes. The proposed path
would be:- /faq/notes/ - defaulting to index.html.

URLs need to be current to the FAQ and should use relative paths. This
makes the pages more portable. For example, a link:
href="http://jibbering.com/faq/#FAQ4_4", should be changed to:
href="/faq/#testCookie"

Full ACK.
After all files have been fixed, the FAQ can link to the new index page.

The beauty of it is that the files don't really need to be fixed, given
proper Web server configuration.
It is a lot of tedious work.

I don't think so.
If anyone is interested in pitching in on this, please contact me.

I think I know my way around Regular Expressions, Apache/2.x, and
mod_rewrite (I use them both professionally and privately on a daily basis),
so I volunteer.


Regards,

PointedEars
 
T

Thomas 'PointedEars' Lahn

Richard said:
So what? URLs are not things that are required to be memorable.

IBTD!

<http://www.w3.org/Provider/Style/URI>
<http://www.w3.org/QA/Tips/uri-choose>

Short but talking URLs are a requirement for good search engine ranking and
even for accessibility nowadays.
That would be a very subjective judgment of what would be better. I
would regard the change as pointless effort with no real benefit and
much potential disadvantage, so not "better".

You don't think that referring to

http://jibbering.com/faq/notes/closures#IE-memory-leak
(or http://cljs.example/faq/notes/closures#IE-memory-leak)

is easier to do and easier legible than referring to

http://www.jibbering.com/faq/faq_notes/closures.html#clMem

? Think again.
So you intend doubling up (at least one page of) the notes?

Hopefully not, as there is no need for that in order to achieve the above.
Not necessarily. The FAQ should never have been changed in a way that
made the fragment identifier #FAQ4_4 ineffective as the archives are
full of references to the FAQ that use that style of fragment
identifier that should never have been broken by modifications to the
FAQ (otherwise the archives are diminished as a resource). After all,
even if there is no longer a section 4.4 there is no reason why the
answer it once contained could not be tagged with the fragment
identifier "FAQ4_4".

Yes, AFAIK fragment identifiers are not sent to the server and so cannot be
URL-rewritten. However, one can do

<h3><a name="testCookie">Setting</a> <a name="FAQ4_4">Cookies</a></h3>

because

<a name="foo"></a>

or

<a name="foo"> </a>

might not be regarded an anchor, and `a' elements must not nest. Keeping
track of the changes is what this makes difficult, though.

BTW, I do not think that the current

<h3 id="formatDate">
<a class="empty" name="FAQ4_1"> </a>
4.1 How do I format a date with javascript?
</h3>

is a good idea. Should be at least

<h3 id="formatDate">
<a name="FAQ4_1">4.1 How do I format a date with javascript?</a>
</h3>

Also note that not all user agents support IDs as anchors.


PointedEars
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
september.org>, Thu, 21 May 2009 00:00:25, Garrett Smith
It has been noted that the "notes" url is unmemorable. The current url
for the notes:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

It was proposed to provide a better URL for the notes. The proposed
path would be:- /faq/notes/ - defaulting to index.html.


Not important. You have better things to do. There is no need to type
the Notes URL at all; users should bookmark it and the FAQ.

Anyway, it is only necessary to put javascript faq notes in a
browser address bar. I get 16e6 hits, with the right one first. One
early hit is a CLJ wiki, at <http://www.cljwiki.org/>.

Especially not important when you add the Notes Index to the FAQ, as
discussed before.


However, add to the TOC/Intro page anything that might aid searches.
For example, one of my pages includes "The word Millennium is not spelt
Millenium, Milenium, or Milennium (but that reference may help bad
spellers using search engines!)."

Search terms should include clj, c.l.j, ecmascript, news, newsgroup,
Usenet.


Equally, the Notes should have a copyright statement in the Intro, and a
copyright indication on the other pages.
It is a lot of tedious work. If anyone is interested in pitching in on
this, please contact me.

Don't let Lahn anywhere near it.
 
G

Garrett Smith

Richard said:
So what? URLs are not things that are required to be memorable.


That would be a very subjective judgment of what would be better. I
would regard the change as pointless effort with no real benefit and
much potential disadvantage, so not "better".

The benefit is that it is shorter and more memorable.
So you intend doubling up (at least one page of) the notes? Because
currently the archives, many third party web pages and numerous books,
reference notes pages using the current URLs, so making the pages
unavailable from their current URLs will not be doing anyone any
favours.

Yes, double it up then create a redirect or a rewrite.
They did use relative paths.

The faq notes I don't have permissions on. I don't know if they were
ever changed or not, but they do link to FAQ page on jibbering.com,
using a full url (see just below).
Not necessarily. The FAQ should never have been changed in a way that
made the fragment identifier #FAQ4_4 ineffective as the archives are
full of references to the FAQ that use that style of fragment
identifier that should never have been broken by modifications to the
FAQ (otherwise the archives are diminished as a resource). After all,
even if there is no longer a section 4.4 there is no reason why the
answer it once contained could not be tagged with the fragment
identifier "FAQ4_4".

Changing the FAQ to give more semantic fragment identifiers made those
links more meaningful to humans and bots.

Changing to use relative paths to link to the FAQ makes the FAQ portable
to another server, which has been the subject of a few recent threads.
It would also make it easy to find the faq_notes index page from the
cookies page.

The current notes index:
http://www.jibbering.com/faq/faq_notes/

That page, while useful, is not quite what one might expect to find from
the "notes" page, and does not link back to the FAQ.

Instead, I think it would be more intuitive to have the default page as
what is now faq_notes.html, and should be found at /faq/notes/ and that
all pages should have a breadcrumb for faq / notes (linking to both the
faq and to the notees).

Ineffectualizing fragment identifier in the links was a mistake that has
been rectified. http://jibbering.com/faq/#FAQ4_4 links to the faq
section, which links back to the cookies page.
If modifications to the FAQ didn't invalidate the references to the
FAQ in the archives they would not invalidate the URLs in the notes.


The notes pages use very simple and uniform mark-up. Mechanically
transforming the URLs would be trivial.

The pages need to be downloaded.

Find/replace in path: "notes"
Find: http://jibbering.com/faq/#FAQ([^'"]+)
Replace: ../\1

First steps could be to do that and test it.

Garrett
 
D

David Mark

It has been noted that the "notes" url is unmemorable. The current url
for the notes:http://www.jibbering.com/faq/faq_notes/faq_notes.html

It was proposed to provide a better URL for the notes. The proposed path
would be:- /faq/notes/ - defaulting to index.html.

URLs need to be current to the FAQ and should use relative paths. This
makes the pages more portable. For example, a link:
href="http://jibbering.com/faq/#FAQ4_4", should be changed to:
href="/faq/#testCookie"

After all files have been fixed, the FAQ can link to the new index page.

It is a lot of tedious work. If anyone is interested in pitching in on
this, please contact me.

As I've mentioned before, the markup and style need to be torn down
and rewritten from scratch. At the very least, major surgery is
needed.

I'd leave the URI's alone. It doesn't really matter in the larger
scheme of things. Who memorizes such URI's? Well, other than the
spiders and bookmarks, etc. Sure, you could use redirects to make the
move seamless, but it all sounds like a waste of time to me.
 
G

Garrett Smith

Dr said:
In comp.lang.javascript message <[email protected]
september.org>, Thu, 21 May 2009 00:00:25, Garrett Smith



Not important. You have better things to do. There is no need to type
the Notes URL at all; users should bookmark it and the FAQ.

The faq and notes should be portable to another server. This is more
easily facilitated by using relative paths.

The contributions page needs fixing. There is a mistake in the closures
article that needs fixing.
Anyway, it is only necessary to put javascript faq notes in a
browser address bar. I get 16e6 hits, with the right one first. One
early hit is a CLJ wiki, at <http://www.cljwiki.org/>.

Especially not important when you add the Notes Index to the FAQ, as
discussed before.

The notes index page is linked from the faq.

"For additional explanation and detail relating to some aspects of the
FAQ, please see the FAQ Notes. "

I do not agree that this index page should be included on the FAQ. This
would make the TOC excessively long.

Instead, I believe the notes should instead be linked at the top, as it
is, and throughout, where relevant (as it is).
Don't let Lahn anywhere near it.

I do not plan to provide access to Jim's server to anyone; that is up to
Jim to decide.

All personal feelings aside, I do not have a good reason not to accept
assistance from anyone. I have not gotten to respond to those comments
of the suggestion to use mod_rewrite, but I will.

All right enough, I am out of here now. Time to go appreciate the great
weather.

Garrett
 
G

Garrett Smith

David said:
As I've mentioned before, the markup and style need to be torn down
and rewritten from scratch. At the very least, major surgery is
needed.

All right.
I'd leave the URI's alone. It doesn't really matter in the larger
scheme of things. Who memorizes such URI's? Well, other than the
spiders and bookmarks, etc. Sure, you could use redirects to make the
move seamless, but it all sounds like a waste of time to me.

I propose we start with a new URI path:
/faq/notes/

faq/notes/closures.html seems easy to remember for me. It is shorter. It
is more along the w3c guidelines that Thomas linked to.

The old URIs can be made to still work. A URL rewrite to the new URI(s)
(for old references to that URI) would work. That way, anyone typing in
the "old" (current) URI would get the URIs that have undergone whatever
surgery has been decided upon.

Garrett
 
P

Peter Michaux

So what? URLs are not things that are required to be memorable.



That would be a very subjective judgment of what would be better. I
would regard the change as pointless effort with no real benefit and
much potential disadvantage, so not "better".

I agree with Richard.

The URL is not a problem, has been well logged in search engines,
written on paper and in bookmarks. Better to leave it alone.

Peter
 
D

David Mark

All right.


I propose we start with a new URI path:
/faq/notes/
Why?


faq/notes/closures.html seems easy to remember for me. It is shorter. It
is more along the w3c guidelines that Thomas linked to.

Shorter than what? And who needs to remember these things?
The old URIs can be made to still work. A URL rewrite to the new URI(s)
Yes.

(for old references to that URI) would work. That way, anyone typing in
the "old" (current) URI would get the URIs that have undergone whatever
surgery has been decided upon.

I say skip the voluntary surgery. The markup, style (and content of
course) are where the energy should be directed.
 
G

Garrett Smith

Thomas said:
IBTD!

<http://www.w3.org/Provider/Style/URI>
<http://www.w3.org/QA/Tips/uri-choose>

Short but talking URLs are a requirement for good search engine ranking and
even for accessibility nowadays.


You don't think that referring to

http://jibbering.com/faq/notes/closures#IE-memory-leak
(or http://cljs.example/faq/notes/closures#IE-memory-leak)

is easier to do and easier legible than referring to

http://www.jibbering.com/faq/faq_notes/closures.html#clMem

? Think again.


Hopefully not, as there is no need for that in order to achieve the above.


Yes, AFAIK fragment identifiers are not sent to the server and so cannot be
URL-rewritten. However, one can do

<h3><a name="testCookie">Setting</a> <a name="FAQ4_4">Cookies</a></h3>

because

<a name="foo"></a>

or

<a name="foo"> </a>

might not be regarded an anchor, and `a' elements must not nest. Keeping
track of the changes is what this makes difficult, though.

BTW, I do not think that the current

<h3 id="formatDate">
<a class="empty" name="FAQ4_1"> </a>
4.1 How do I format a date with javascript?
</h3>

is a good idea. Should be at least

<h3 id="formatDate">
<a name="FAQ4_1">4.1 How do I format a date with javascript?</a>
</h3>

That is not what the markup looks like. This is the real markup:

<h3 id='formatDate'><a class='empty' name='formatDate'>&nbsp;</a>4.1
How do I format a date with javascript?</h3><a class='empty'
name='FAQ4_30'>&nbsp;</a>

There are old IDs and new IDs.

This part:-

<h3 id='formatDate'><a class='empty' name='formatDate'>&nbsp;</a>4.1
How do I format a date with javascript?</h3>

- is for newer links to something like "#formatDate", and this part:

<a class='empty' name='FAQ4_1'>&nbsp;</a>

- is a named anchor for an old ID.

I think there was a reason I moved the second link outside of the
heading. It may have affected the display in some way. I can't remember.
I can try moving it back inside the heading.
Also note that not all user agents support IDs as anchors.

The cost of id and not using name="example" attribute for anchors is
that links to "#example" won't be recognized NS4 and possibly others (I
am unaware, but probably exist) won't work.

The benefit is that there is not an extra anchor.

Garrett
 
D

David Mark

That is not what the markup looks like. This is the real markup:

<h3 id='formatDate'><a class='empty' name='formatDate'>&nbsp;</a>4.1
How do I format a date with javascript?</h3><a class='empty'
name='FAQ4_30'>&nbsp;</a>

This is what I'm talking about. I don't know if this is the extant
markup or a proposal, but I don't like it.
 
G

Garrett Smith

David said:
Shorter than what? And who needs to remember these things?

The guy who found a neat article by doing a web search, and tells his
friend about it, on the bus.

The email that was sent, but the link didn't quite make it through
because it was a little too long and it wrapped and the (buggy) email
program broke the URI.

You. When someone asks what you have contributed to online, and you're
on the train, on your mobile phone, you can say it, and (bonus) the
probability of the other person typing in something short and seeing
your name on the contributor list (provided you contribute something).

I say skip the voluntary surgery. The markup, style (and content of
course) are where the energy should be directed.

If there is a new uri, that can be a development URI. The current
faq_notes will work, without any change. When ready, the new URI will be
linked to from the FAQ.

The notes will then be (re)publishable (publicly linked) and will be
portable to other servers.

To avoid a problem with search engines picking up mistakes, we can just
refer to paths, such as "I updated the page at /faq/notes/foo.html -
please check what I did."

Garrett
 
D

David Mark

The guy who found a neat article by doing a web search, and tells his
friend about it, on the bus.

Well, if you want to get anywhere, don't take the bus. :)
The email that was sent, but the link didn't quite make it through
because it was a little too long and it wrapped and the (buggy) email
program broke the URI.

Seems reaching.
You. When someone asks what you have contributed to online, and you're
on the train, on your mobile phone, you can say it, and (bonus) the
probability of the other person typing in something short and seeing
your name on the contributor list (provided you contribute something).

That's where you are wrong. My standard response is: mind your own
contributions.

[snip]
 
G

Garrett Smith

Peter said:
I agree with Richard.

The URL is not a problem, has been well logged in search engines,
written on paper and in bookmarks. Better to leave it alone.

What if all the current URIs could still work? What if the markup could
be made more semantic and search-engine friendly? What if the contents
could be edited. What if new, shorter, more memorable URIs could be
used? Any of this sound any good? What about that while still
maintaining the old URI references?

The strategy I have in mind?

Do not remove the current notes. Do not use a shortcut URI and rewrite
to the existing one.

Instead, recreate the notes on a different path. Edits to the notes will
take place in new location. The new location should not become public
until acceptably complete.

Finally, after the copy is accepted by approval, it will be publicly
linked. Follwing that, a mod_rewrite or a redirect rule can be applied
so that anyone navigating to the faq_notes uri will either get a
redirect or get the content at the new URI.

So what about the "edits" I mentioned? I have a few improvements in
mind. So does D Mark.

My ideas for improvement:
A more useful default page, breadcrumb links (to the notes and to the
FAQ itself, technical editing (one nagging in particular), edits to the
contributors page, more semantic markup.

Why not change the notes, but keep the same location?
The notes would not be portable to another server. The benefit of
shorter URIs would not be realized. Changes to the articles would
require either posting draft text to the group posting an in-progress
document at a different URI (which would be the new location).

If posting a new draft URI, content and markup could be easily
critiqued. Any mistakes would be made on the copy pages. These would be
rectified in the approval process. The current live pages would not be
edited and would remain as they are.

What do you think?

Garrett
 
T

Thomas 'PointedEars' Lahn

Garrett said:
Thomas said:
Richard said:
[...] The FAQ should never have been changed in a way that
made the fragment identifier #FAQ4_4 ineffective as the archives are
full of references to the FAQ that use that style of fragment
identifier that should never have been broken by modifications to the
FAQ (otherwise the archives are diminished as a resource). After all,
even if there is no longer a section 4.4 there is no reason why the
answer it once contained could not be tagged with the fragment
identifier "FAQ4_4".
Yes, AFAIK fragment identifiers are not sent to the server and so cannot be
URL-rewritten. However, one can do

<h3><a name="testCookie">Setting</a> <a name="FAQ4_4">Cookies</a></h3>

because

<a name="foo"></a>

or

<a name="foo"> </a>

might not be regarded an anchor, and `a' elements must not nest. Keeping
track of the changes is what this makes difficult, though.

BTW, I do not think that the current

<h3 id="formatDate">
<a class="empty" name="FAQ4_1"> </a>
4.1 How do I format a date with javascript?
</h3>

is a good idea. Should be at least

<h3 id="formatDate">
<a name="FAQ4_1">4.1 How do I format a date with javascript?</a>
</h3>

That is not what the markup looks like.

Well, it is what Firebug shows to date. I have no reason to believe that
I am seeing an old version, only that Firebug displays &nbsp; as a space
character.
This is the real markup:

<h3 id='formatDate'><a class='empty' name='formatDate'>&nbsp;</a>4.1
How do I format a date with javascript?</h3><a class='empty'
name='FAQ4_30'>&nbsp;</a>

There are old IDs and new IDs.

No, there is a new ID and two names. Anyhow, Firefox (as per its built-in
View Selected Source feature, and therefore, Firebug) doesn't seem to care
about it, probably because it is wrong. Firstly, the markup is not Valid:
when an _anchor_ has a name, there must not be another element that has it
as ID or name. Secondly, the "empty" anchor after the `h3' element is
ignored (as I have pointed out above).

And, in fact, it is only your declaring HTML 4.01 Transitional that doesn't
make the `a' element outside of the `h3' block element invalid in itself.
This part:-

<h3 id='formatDate'><a class='empty' name='formatDate'>&nbsp;</a>4.1
How do I format a date with javascript?</h3>

- is for newer links to something like "#formatDate", and this part:

<a class='empty' name='FAQ4_1'>&nbsp;</a>

- is a named anchor for an old ID.

But you MUST NOT do this per Specification.

<http://www.w3.org/TR/html401/struct/links.html#h-12.2.3>

(One would have thought that a maintainer of a FAQ written/generated
in HTML would at least know how HTML links and anchors work ...)
I think there was a reason I moved the second link outside of the
heading. It may have affected the display in some way. I can't remember.
I can try moving it back inside the heading.

You definitely SHOULD do that, but it would still be insufficient.
The cost of id and not using name="example" attribute for anchors is
that links to "#example" won't be recognized NS4 and possibly others
(I am unaware, but probably exist) won't work.

The benefit is that there is not an extra anchor.

And now do weigh them against each other, please.

And trim your quotes, please.


PointedEars
 
P

Peter Michaux

What if all the current URIs could still work?

I still don't see the point in changing the URL. The current URL is
not so unfriendly and changing it is more confusing that it is worth.
What if the markup could
be made more semantic and search-engine friendly?

That is a great idea for change.

What if the contents
could be edited.

I assumed the contents could be edited now by the FAQ editor.
What if new, shorter, more memorable URIs could be
used?

The URLs are not a problem. They don't need to be memorable. Who is
running around in life needing the c.l.js URLs at the tip of their
fingertips? The pages are found through Google search, links here,
etc.
Any of this sound any good?

Yes, the bit about semantic markup.
What about that while still
maintaining the old URI references?

The URLs are not the problem.
The strategy I have in mind?

Do not remove the current notes. Do not use a shortcut URI and rewrite
to the existing one.

Instead, recreate the notes on a different path. Edits to the notes will
take place in new location. The new location should not become public
until acceptably complete.

Finally, after the copy is accepted by approval, it will be publicly
linked. Follwing that, a mod_rewrite or a redirect rule can be applied
so that anyone navigating to the faq_notes uri will either get a
redirect or get the content at the new URI.

I don't think it is worth it.
So what about the "edits" I mentioned? I have a few improvements in
mind. So does D Mark.

My ideas for improvement:
A more useful default page, breadcrumb links (to the notes and to the
FAQ itself, technical editing (one nagging in particular), edits to the
contributors page, more semantic markup.

Sounds good.
Why not change the notes, but keep the same location?
The notes would not be portable to another server.

As long as the link URLs don't contain the jibbering domain then I
don't think that is the case. The notes are portable. sed is probably
up to the task. Alternately Apache config wizardry could do it.

Also it is unlikely you will use a relative URL that is where a mirror
site would want to keep it anyway so the situation wouldn't really be
improved.
The benefit of
shorter URIs would not be realized.

I don't think there are any real benefits.
Changes to the articles would
require either posting draft text to the group posting an in-progress
document at a different URI (which would be the new location).

If posting a new draft URI, content and markup could be easily
critiqued. Any mistakes would be made on the copy pages. These would be
rectified in the approval process. The current live pages would not be
edited and would remain as they are.

What do you think?

Work on the pages on a different domain (beta.jibbering.com,
beta.dhtmlkitchen.com something else) and when things are ready just
copy the files into the current location with the current URLs.

Peter
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
september.org>, Thu, 21 May 2009 17:34:32, Garrett Smith


It is more important to get the FAQ right first, before putting effort
into anything else. Too few people read the FAQ anyway; hardly any will
read the Notes.

Since the regular posting of FAQ parts has been working incorrectly for
a couple of months at least, most of it has not been reviewed lately;
remember that you are the editor rather than the author.

Until the regular posting is fixed, I suggest that you post sections
manually each day that you are at your machine, starting at the end and
working backwards. Straight copy'n'paste from the Web view will
suffice.



Secondly, there is no real need for the FAQ notes to link to specific
FAQ articles, which may in any case have changed enough to make the
references moot. Just ensure that top and bottom of each FAQ Note page
have links to the FAQ itself. Let the connection be made by the test
of the subjects.


Before anything else is done to the Notes, they should be reviewed for
decrepitude, and problems fixed or noted. For example,
<http://jibbering.com/faq/faq_notes/faq_notes.html#toc> says
[link] The complete FAQ and Notes in ZIP format (174KB)
which contains
"comp.lang.javascript FAQ - 8.1 - 2005-11-05".
There is no great need nowadays to provide such ZIPs, and it is
positively wasteful when they turn out to be out-of-date.



It might be easier to keep the Notes as they were a year ago, as an
archive. and build and maintain, in a different directory, an entirely
new structure filled by selective copying and editing.

The notes index page is linked from the faq.
I do not agree that this index page should be included on the FAQ. This
would make the TOC excessively long.

We discussed that before, and I thought that you had understood. The
FAQ should contain about 20 lines for the Notes Index part; it should
link only to what the top level of UL in the full Notes index links to,
except miscellaneous, plus the contents of miscellaneous. That should
be one link per FAQ notes web page. It would not be in the FAQ TOC; it
would be in a subsection of a FAQ section, perhaps "3.3 What are the FAQ
Notes?"



In <http://jibbering.com/faq/faq_notes/faq_notes.htm>, there should be a
conspicuous link to the FAQ; not just one buried in a paragraph at the
bottom. Make the second t in that page upper-case, and make that "The
comp.lang.javascript FAQ" be itself a link to the FAQ. That will be
conspicuous, especially when you get rid of the non-default colouring
of link-related text.



The FAQ, as seen here, has an _apparent_ CSS fault. There is a big gap
after headings (almost always) and a small one before them; it should be
the other way round. Your code, but my whitespace :

... input elements in a way that is useful.</p>

<h3 id='propertyAccess'>
<a class='empty' name='propertyAccess'>&nbsp;</a>
8.2 My element is named myselect[], how do I access it?</h3>

<a class='empty' name='FAQ4_25'>&nbsp;</a>

<p>Form controls with ...

The FAQ4_25 part should be within the H3, perhaps first, I suspect :
yes, seems so. And the CSS should give extra spacing before <Hn>;
perhaps about an em for <H2> decreasing smoothly to almost nothing for
<H6>.

Perhaps that is the best XML can give - I suspect that the XML is a
handicap rather than an advantage, and it would be better to abandon it.
 
P

Peter Michaux

Not a problem, no, but not ideal.

If it is not a problem then I wouldn't touch it.
Which part?

Changing the URLs is not worth it. They are fine the way they are.

As I posted in this thread, the links do contain the jibbering domain.

I'm not sure what I was thinking. Even the jibbering domain in the
URLs could be handled by sed. Someone who wants to mirror the pages
could use cron, wget and sed to regularly mirror the files regardless
of the jibbering domain and jibbering urls.

Links in the FAQ do, too. This is because the text that is posted to the
newsgroup needs full URLs, as relative paths would not work. However,
that can be fixed, and, if noone objects, I will use all relative URLs
on the FAQ page and have the URLs for the text links mechanically
generated to contain the protocol + domain.

It is probably easier to just leave the full URLs in the FAQ. The
burden of manipulating the URLs will be on the person who wants to
mirror anyway.
Sorry, I didn't get what you meant.

If the URLs are currently

http://www.jibbering.com/faq/faq_notes/form_access.html

and you change them to be something else like

/faq/notes/form_access.html

then no matter what, if I want to mirror the site, I'm going to have
to do some text manipulation anyway because I'd host them at

/c.l.js/faq/notes/form_access.html

, for example. (I think I'd also add the canonical tag in the head
element if it wasn't already there.) So changing the URLs doesn't
likely make it easier to mirror because it is not likely the person
doing the mirroring will want to have the same paths anyway.

Apparently nobody else except Thomas does, either.

What does that tell you?

If all but two want to keep the current URLs then it should be a dead
issue. Democracy.

Did you read the w3c documents regarding URIs? I've read through them a
few times before (and again). I think that has had an impact on me.

This part:-
| A few questions to consider when you choose a URI for a new location:
|
| * Can you easily write the chosen URI on a piece of paper, or can
| you remember it easily?
|
| * Can you spell the chosen URI on the phone?

Underscore is not easily communicated over a (mobile) phone.

I just say "underscore" to people and it seems to work. I don't do it
over a mobile phone; however, and I'd bet no one has ever given a
jibbering URL for the faq notes over the phone.


There may
be some browsers that convert speech to text, so a11y would be improved
by shorter URI (without an underscore).

| * Does the chosen URI give hints about the content of the resource?
| Will it still make sense if the resource evolves?
|
| * Did you choose to locate the URI near the root level of your Web
| server? Are you certain it is the best location?

"Where are the FAQ notes?".

If a user does not know the URI, he may try direct navigation by typing
directly into the browser location bar.

For example, let me try guessing the CSS spec right now:-

www.w3.org/TR/css/

I have no idea what "TR" abbreviates. I never would have guessed it.
I've even seen that URL many times.

Brings up the CSS specification in FIrefox atwww.w3.org/TR/CSS/
(redirected). It works.

Sort of works for other specs, too.

Having a URI with path /faq/faq_notes/faq_notes.html is not a likely
first guess.

No, but no one is guessing the FAQ Notes URLs anyway. People probably
wouldn't even know they are called "FAQ Notes". They might guess they
are called "FAQ Articles".
A separate domain is not needed for development. A path could work with
the same amount of effort.

The important part is the majority of respondents think leaving the
production URLs as they are is the best course of action.

I think updating the HTML and making the page content more friendly is
a great idea and worth the investment.

Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,981
Messages
2,570,188
Members
46,732
Latest member
ArronPalin

Latest Threads

Top