Re: <FAQ..TRY> Comments, suggestions on comp.lang.javascript FAQ
- From: Garrett Smith <dhtmlkitchen@xxxxxxxxx>
- Date: Thu, 15 Oct 2009 16:22:29 -0700
GTalbot wrote:
On 15 oct, 06:45, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
wrote:
GTalbot wrote:
a) To remove this: "Read recent relevant posts in c.l.js. "Why?
Such advice is general, quite loose, not that helpful, not well
targeted. I assume people do read a bit (glance at the subject lines)
posts to see what's going on in a newsgroup before posting, anyway.
A new poster is probably more likely to have read recent posts than to have read the FAQ.
Nonetheless, it is still good advice, for those who happen to read the FAQ first.
But to suggest that treads in c.l.js are good examples of posting
manners is very far from truth. There are people in this newsgroups
who are rude, not that helpful, nitpicking, etc., you know.
By reading recent posts, the person making the new post can have an idea of the sort of reply that might come.
b) To replace this: "If the code is more than about 300 lines,Absolutely not. First, I don't recall any discussion about, let alone
provide a link instead."
with
"If the code is more than about 50 lines, provide a link instead. "
agreement to, reduce the constraint on the amount of code posted from
500 lines to 300 lines, and had every intention of complaining about
that some time soon.
Why should 500 LOC be the suggested cap-off point? It is certainly not to be encouraged by a new post.
A reduced example will normally be much shorter than 500 LOC. A *reduced* example over even 300 LOC would certainly be well beyond the phase of "help it doesn't work."
The other problem with long example code, or multi-document examples, is that the context of the problem/example can be harder to follow.
Reduced examples tend to be pretty short.
500 seems very long. I would much rather suggest shorter examples.
Posting URLs is necessary for some examples; those extensively using
images (because images cannot be posted to the group), frames, or where
the headers may significant. However, the vast majority of scripting
issues can be reduced to examples that are simple enough to post,
Well, if you restrict to posting only javascript code, then readers
will miss everything about doctype declaration, markup validity, CSS
validity, <style> blocks, etc.. all which can (and usually does)
influence layout or expected results of DHTML. This happens all the
time too.
JS debugging will not work efficiently or just correctly with
malformed markup code and invalid CSS code.
the
practice of reducing them to those examples is invariably beneficial for
the person being asked to do it, and separating the script and related
mark-up
I'm all for a clear separation of script with markup and for a clear
separation of style (presentation) with markup and script. But
separation is not omission or absence of. Sometimes, questions and
comments are directed toward markup which has not been posted, are
directed toward doctype declaration which isn't posted, etc.
So, to really answer questions, you often need the whole HTML document
code anyway. That can make quite a lot of lines of code as people
generally do not know how to reduce a webpage to minimum code
relevant. And if you have a 200 lines of code, anyone replying to such
post will have to do the work (copy, paste, upload, type, etc.) and it
won't reveal possible situations (like http headers, server
configuration) which may be affecting the poster's real webpage.
The source code required to produce the problem scenario is required, completely. There are already statements in the FAQ:
1. Try to reduce the problem as much as possible.
2. Validate the HTML and CSS http://validator.w3.org/,
http://jigsaw.w3.org/css-validator/.
3. Make sure the code is executable as transmitted.
<PROPOSAL>
Propose change (1) to:
| Post a reduced example. Remove everything that does not contribute to
| the problem (images, scripts, etc).
</PROPOSAL>
from the question adds an extra step for people interested in
reading the question.
It remains possible for the newsgroup to be being read offline (which is
still what I do when reading on my 3G laptop) so referring to a URL when
that is not necessary can get in the way.
Also, external links are very unstable. How many times have you seen a
link to a page that apparently shows some issue only to find out that
the reason that it does not is that it has been changed in the
intervening time?
That's a problem too. Often the poster does not understand that his
post is archived, that modifying his webpage will defeat the purpose
of his posting.
How many URLs of examples referenced last year do you
imagine are still there (haven't been removed entirely)? Making the
archiving of the group less useful as code not directly posted to the
group tends to become unavailable.
I could bring arguments against posting long chuncks of code too:
satellite connexion, paying for bandwidth, http headers not available.
If I want to see how the posted code is doing in a real webpage
context, I have to waste more time, more energy and more bandwidth.
In a post that links to a document, the bandwidth will be lower if the reader does not click the link. But that does not seem to be a significant concern here, to me, at least.
It can be less troublesome for some to spot the bug when code is posted in a message than to read the message, click the link, try the example, view source, then find the cause.
One searching the archives would realize the advantage to having an actual example (instead of a broken link).
<snip>> 8- References to IE 6 should be removed IMO. For over 18 months,there has been a strong movement to phase out, to stop supporting<snip>
IE 6. The FAQ should reflect this.
While directly talking about Netscape 4 is probably pointless now, this
group should not take any attitude at all towards the browsers that
Internet users employ.
Well, I definitely disagree on this. In all fairness, IE6 deserves a
bad reputation and I see no reason at all to suggest or to propose to
Internet users that IE6 is still a browser version which deserves to
be supported with all kinds of dedicated hacks.
IE6 is a very buggy browser. IE6 has become a security risk by itself
for those using it.
All right, so we agree :-D.
You'll be hard-pressed to find someone who disagrees with IE6 bugginess.
It might be worht considering "How can I get my users/client to upgrade from an older browser?" That does not seem to be an actual FAQ, though.
It is reasonable to recognise when a browser is no longer in use but it
is not this group's place to attempt to dictate which browsers people
use.
I did not say dictate. My suggestion regarding IE6 had nothing to do
with browser marketshare either.
There is now a strong world-wide movement against supporting IE 6
furthermore: you just can't ignore it.
The FAQ contains factual and relevant information for programmers, including how create solutions that are widely supported. That is a good thing.
The idea of removing all mention of IE6 does not fit with the goals of the FAQ. I do not believe it would do any good at all.
Browser upgrade not a new trend. Recall the web standards project when NS6 came out, there were strategies to out NS4. Some good, others offensive (and I participated in that, too). Things that are offensive to the user:-
if(document.layers) {
window.open("upgrade.html");
}
IE6 requires a lot of weird hacks, ugly workarounds, dedicated code in
hundreds of code situations. I say IE6 is not a recommendable browser
to use, to code for. For tons of reasons (CSS 2.1, HTML 4, DOM 1,
javascript, security reasons). Why should this newsgroup FAQ suggest
that IE6 is just another browser like others. Promoting or even just
suggesting that IE6 is just another browser like others which may have
bugs, flaws, shortcomings like any other browser (which is not true)
is doing a grave disservice to readers of c.l.js. IE6 is extremely
buggy.
You'll be hard-pressed to find disagreement to your claims that IE6 is buggy.
I do not know what you mean by "dedicated code". Strategies that consider not breaking in IE6 help the thought process for solving cross browser problems. I do not agree that it is a disservice.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
.
- References:
- <FAQENTRY> Comments, suggestions on comp.lang.javascript FAQ
- From: GTalbot
- Re: <FAQENTRY> Comments, suggestions on comp.lang.javascript FAQ
- From: Richard Cornford
- Re: <FAQ..TRY> Comments, suggestions on comp.lang.javascript FAQ
- From: GTalbot
- <FAQENTRY> Comments, suggestions on comp.lang.javascript FAQ
- Prev by Date: FAQ Topic - Why doesn't the global variable "divId" always refer to the element with id="divId"? (2009-10-16)
- Next by Date: Re: <FAQ..TRY> Comments, suggestions on comp.lang.javascript FAQ
- Previous by thread: Re: <FAQ..TRY> Comments, suggestions on comp.lang.javascript FAQ
- Next by thread: Re: <FAQ..TRY> Comments, suggestions on comp.lang.javascript FAQ
- Index(es):
Relevant Pages
|
