Re: <FAQ..TRY> Comments, suggestions on comp.lang.javascript FAQ

GTalbot wrote:
On 15 oct, 06:45, Richard Cornford 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.

Detailed advice takes more space than has been considered appropriate for that document. It is available in related documents.

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. But to suggest that treads in c.l.js are good examples
of posting manners is very far from truth.

What has that to do with anything?

There are people in this newsgroups who are rude, not that
helpful, nitpicking, etc., you know.

Yes, but nobody is in a position to control what others, only to do whatever they think should be done.

b) To replace this: "If the code is more than about 300
lines, provide a link instead."
with
"If the code is more than about 50 lines, provide a link instead. "

Absolutely not. First, I don't recall any discussion about, let
alone 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.

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,

I don't. The standing advice is to post minimal stand-alone test cases that demonstrate the issue(s) in isolation (it is also suggested that those test case be made available online in order to maximise reader convenience).

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.

Yes, posting code that attempts to interact with the DOM resulting from mark-up is nearly completely useless without the mark-up that it attempts to interact with. But creating a minimal test-case involves removing the superfluous mark-up, css, etc.

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.

Obviously reducing an example to something that no longer exhibits the issue(s) is not going to help any third party identify the cause and effect relationships behind the issue(s), though it often lets the people who create such examples appreciate that their issues are located where they thought they were.

Sometimes, questions and comments are directed toward markup
which has not been posted, are directed toward doctype declaration
which isn't posted, etc.

So they should be posted, which is not going to be outcome of imposing extreme constraints on the amount of code that is posted.

So, to really answer questions, you often need the whole HTML
document code anyway.

An whole HTML document, not necessarily any HTML document.

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.

Yes, but it is such a useful practice that they really should learn, and if/when they do learn there is no reason for objecting to their posting the results.

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

Not if they post a URL as well. And if an issue is obvious from the source code there may be no need to actually load/execute it in order to point out the cause and effect relationships involved.

and it won't reveal possible situations (like http headers,
server configuration) which may be affecting the poster's
real webpage.

It is extremely rare that HTTP headers have anything to do with causing issues that result in questions being asked here (they probably would be a significant issue if people severed their XHTML-style mark-up as XHTML, but the people who know enough to do that generally understand enough to abandon XHTML).

On the other hand, if someone creates a test-case and discovers that it works fine when not requested over HTTP from a server then they have just gained a huge clue about what is going on.

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.

So you have seen that. I was expecting that you would have, as it happens all the time.

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,

Except when the URL leads to someone's non-cut down web page the odds are that they have left the images in, and the bandwidth consumption of one normal image stands a good chance of walking all over the size of a plain text message, even a big one.

http headers not available.

And that is one of the things that don't show up, so it is a good thing that they re rarely significant to JS issues.

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.

<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
IE 6. The FAQ should reflect this.

<snip>

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

Much as Opera 5, Konqeror 2, Netscape 6 and many others have in their time.

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.

The browser has never been a reason for decisions about supporting or not supporting browsers. After all, IE 6 ahs been around for a long time and has never been less buggy during that time, yet a few years ago absolutely nobody was even considering not supporting it.

IE6 is a very buggy browser. IE6 has become a security risk
by itself for those using it.

Become?

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.

I haven't ignored it, I frequently ridicule it. ;-)

IE6 requires a lot of weird hacks, ugly workarounds, dedicated
code in hundreds of code situations.

Yes, but not nearly as many as IE 4, Opera 6 or Netscape 4.

I say IE6 is not a recommendable browser to use,

It isn't.

to code for.

That should not depend on the browser. Whether coding for a browser is recommended or not depends on the context. There are contexts where not coding for IE 6 is suicide, and there it is not only recommended but actually essential. However, The number of context where disregarding IE 6 is recommendable is not nearly as low as the people who struggle to cope with it like to make out.

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.

Because it is. Browsers have bugs. IE 6 may have more than most current browsers, but there have been infinitely worse browsers ( and may still be).

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)

In what sense is it not true?

is doing a grave disservice to readers of c.l.js. IE6 is
extremely buggy.

The main reason for considering coding for IE 6, and so for the group to tell newcomers about how to code for IE 6, is the reason we are discussing it now. We are not even considering coding for Netscape 4, IE 4 or Opera 6 any more because they have been relegate to history. Eventually IE 6 will join them, but that has not yet happened, and it is not going to happen for at least another year. People can wing about that as much as they like but it isn't going to change much because the stronghold of IE 6 is on the desktops of businesses who have more to take into account when deciding about upgrading than just how good any particular browser is considered to be. For them it is doing the job they want it to do now, and any transition to another browsers is not necessarily risk free and/or cost free.

Richard.

.

Relevant Pages

  • Re: asp textbox not reflecting changed text on postback to server
    ... that the click event was what started the entire postback process from the ... browser so I assumed it would happen first, ... > Thanks for posting here. ... > #Control Execution Lifecycle ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Comments, suggestions on comp.lang.javascript FAQ
    ... posts to see what's going on in a newsgroup before posting, ... will miss everything about doctype declaration, markup validity, CSS ... Internet users that IE6 is still a browser version which deserves to ... IE6 is a very buggy browser. ...
    (comp.lang.javascript)
  • Re: FormsAuthentication client-side problem
    ... this posting is provided "AS IS" with no expressed or implied ... > I'm using FormsAuthentication to secure access to a web site. ... > authentication process works correctly initially. ... > browser), they are allowed into that page. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: How to make IE browser by default by GPO
    ... This posting is provided "AS IS" with no warranties, ... browser on USB drive you can not prevent this. ... as other applications with a shortcut. ... Ace Fekay, MCT, MCSE, MCSA 2003 & 2000, MCSA Messaging Microsoft ...
    (microsoft.public.windows.server.active_directory)
  • Re: Event Matchmaker updated
    ... > "contact us" one for some reason. ... > actually cover your logo to the point that the logo isn't visible. ... > being resized by the browser. ... > - The FAQ pages don't look anything like any FAQ I've ever seen, ...
    (rec.juggling)