Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Looking for Help with FAQ

Reply
Thread Tools

Looking for Help with FAQ

 
 
David Mark
Guest
Posts: n/a
 
      05-22-2009
On May 22, 1:00*am, Garrett Smith <(E-Mail Removed)> wrote:
> David Mark wrote:
> > On May 21, 3:00 am, Garrett Smith <(E-Mail Removed)> wrote:
> >> 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.

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


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.
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      05-22-2009
Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
>> On May 21, 8:00 am, Garrett Smith wrote:
>>> It has been noted that the "notes" url is unmemorable.

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

>
> 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_not...res.html#clMem
>
> ? Think again.
>
>>> The proposed path
>>> would be:- /faq/notes/ - defaulting to index.html.

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

>
> 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
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      05-22-2009
On May 22, 1:41*am, Garrett Smith <(E-Mail Removed)> wrote:
> Thomas 'PointedEars' Lahn wrote:
> > Richard Cornford wrote:
> >> On May 21, 8:00 am, Garrett Smith wrote:
> >>> It has been noted that the "notes" url is unmemorable.
> >> 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 rankingand
> > even for accessibility nowadays.

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

>
> > You don't think that referring to

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

>
> > is easier to do and easier legible than referring to

>
> > *http://www.jibbering.com/faq/faq_not...res.html#clMem

>
> > ? *Think again.

>
> >>> The proposed path
> >>> would be:- /faq/notes/ - defaulting to index.html.
> >> 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.

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

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


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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      05-22-2009
David Mark wrote:
> On May 22, 1:00 am, Garrett Smith <(E-Mail Removed)> wrote:
>> David Mark wrote:
>>> On May 21, 3:00 am, Garrett Smith <(E-Mail Removed)> wrote:
>>>> 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.

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

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


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


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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      05-22-2009
On May 22, 2:01*am, Garrett Smith <(E-Mail Removed)> wrote:
> David Mark wrote:
> > On May 22, 1:00 am, Garrett Smith <(E-Mail Removed)> wrote:
> >> David Mark wrote:
> >>> On May 21, 3:00 am, Garrett Smith <(E-Mail Removed)> wrote:
> >>>> 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.
> >> 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/

>
> > 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 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]
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      05-22-2009
Peter Michaux wrote:
> On May 21, 2:21 am, Richard Cornford <(E-Mail Removed)>
> wrote:
>> On May 21, 8:00 am, Garrett Smith wrote:
>>
>>> 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".

>
> 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
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-22-2009
Garrett Smith wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Richard Cornford wrote:
>>> [...] 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.

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


And now do weigh them against each other, please.

And trim your quotes, please.


PointedEars
 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      05-22-2009
On May 22, 12:13 am, Garrett Smith <(E-Mail Removed)> wrote:
> Peter Michaux wrote:
> > On May 21, 2:21 am, Richard Cornford <(E-Mail Removed)>
> > wrote:
> >> On May 21, 8:00 am, Garrett Smith wrote:

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

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


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
 
Reply With Quote
 
Dr J R Stockton
Guest
Posts: n/a
 
      05-23-2009
In comp.lang.javascript message <gv4rut$pl3$(E-Mail Removed)-
september.org>, Thu, 21 May 2009 17:34:32, Garrett Smith
<(E-Mail Removed)> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <gv2u6d$8t0$(E-Mail Removed)-
>> september.org>, Thu, 21 May 2009 00:00:25, Garrett Smith
>> <(E-Mail Removed)> posted:
>>> 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.



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.


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


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

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      05-23-2009
On May 23, 1:13 am, Garrett Smith <(E-Mail Removed)> wrote:
> Peter Michaux wrote:
> > On May 22, 12:13 am, Garrett Smith <(E-Mail Removed)> wrote:
> >> Peter Michaux wrote:
> >>> On May 21, 2:21 am, Richard Cornford <(E-Mail Removed)>
> >>> wrote:
> >>>> On May 21, 8:00 am, Garrett Smith wrote:


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

>
> Not a problem, no, but not ideal.


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

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

>
> Which part?


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


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

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

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

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


> >> The benefit of
> >> shorter URIs would not be realized.

>
> > I don't think there are any real benefits.

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

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

>
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FAQ or not FAQ? =?ISO-8859-15?Q?Juli=E1n?= Albo C++ 28 01-15-2007 04:33 AM
FAQ/FAQ notes site makeover Peter Michaux Javascript 22 11-27-2006 01:55 AM
FAQ - How do I direct someone to this FAQ? FAQ server Javascript 1 08-04-2006 10:13 PM
[de] Update of FAQ in German/FAQ auf Deutsch ueberarbeitet Josef 'Jupp' Schugt Ruby 0 09-22-2003 08:56 PM
Looking for a FAQ control ... Michael Tissington ASP .Net 1 08-04-2003 07:58 PM



Advertisments