<FAQENTRY> corrections
Gérard Talbot
I read/glanced through
comp.lang.javascript FAQ - 9.5 - 2007-01-23
and have some corrections and additions to submit.
In section 4.26
---------------
http://jibbering.com/faq/#FAQ4_26
To add in the list of links:
Developing Cross Browser/Cross Platform Pages
http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Developing_Cross_Browser.2FCross_Platform_Pages
Also, "to offer different CSS stylesheets"
http://w3development.de/css/hide_css_from_browsers/
That document is clearly outdated.
Somewhere, a link to a document on conditional comment to
identify/detect IE6 or IE7 would be good. IE7 fixed a lot of css parsing
bugs so that now, one reliable way is to use conditional comment. There
must be a recent Microsoft document on this somewhere... Maybe
Detecting Internet Explorer More Effectively
http://msdn.microsoft.com/library/?url=/workshop/author/dhtml/overview/browserdetection.asp?frame=true
but that document more or less still strongly recommends userAgent
string detection.
In section 4.35
---------------
http://jibbering.com/faq/#FAQ4_35
"Some browsers may be configured to disallow scripts from setting the
status."
My proposal is to change "Some" by "Most". At least, the most frequently
used browsers out there have user preferences having veto power over
script.
In fact, already most browsers (at least recent ones)
disallow by default status bar text updates via script.
So, I'd say that
*Most* browsers can prevent scripts from setting the status bar text and
they are pre-configured to disallow scripts from setting the
status.
In IE7
......
Tools/Internet Options/Security tab/Internet Zone/Custom level
button/Scripting category/
Allow status bar updates via script/
and here "Disable" is the default value
In Firefox
..........
dom. disable_window_status_change
True (default in Firefox): JavaScript access to window.status is disabled
http://kb.mozillazine.org/About:config_entries#DOM..2A
It must be the same for Seamonkey 1.x and Camino.
In section 4.41
---------------
http://jibbering.com/faq/#FAQ4_41
The given link
http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access
should be
http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Accessing_Elements_with_the_W3C_DOM
In section 4.42
---------------
http://jibbering.com/faq/#FAQ4_42
A complete, cross-browser and (pretty well) up to date reference is
available at
DOM:window.open
http://developer.mozilla.org/en/docs/DOM:window.open
Please add that reference in the link section of section 4.42
Best regards,
Gérard Talbot
--
Using Web Standards in your Web Pages (Updated Dec. 2006)
http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages
FAQEditor
> Hello Randy and Jim,
>
> I read/glanced through
> comp.lang.javascript FAQ - 9.5 - 2007-01-23
> and have some corrections and additions to submit.
>
> In section 4.26
> ---------------
>
> http://jibbering.com/faq/#FAQ4_26
>
> To add in the list of links:
>
> Developing Cross Browser/Cross Platform Pages
> http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Developing_Cross_Browser.2FCross_Platform_Pages
The URL is added.
> Also, "to offer different CSS stylesheets"
> http://w3development.de/css/hide_css_from_browsers/
> That document is clearly outdated.
> Somewhere, a link to a document on conditional comment to
> identify/detect IE6 or IE7 would be good. IE7 fixed a lot of css parsing
> bugs so that now, one reliable way is to use conditional comment. There
> must be a recent Microsoft document on this somewhere... Maybe
>
> Detecting Internet Explorer More Effectively
> http://msdn.microsoft.com/library/?url=/workshop/author/dhtml/overview/browserdetection.asp?frame=true
>
> but that document more or less still strongly recommends userAgent
> string detection.
If you can find a good reputable link on conditional comments it can be
added. Not sure adding a link to a page on browser detection would be a
good idea in a section saying don't use browser detection :)
(I have wondered why hiding CSS is even mentioned in a JS FAQ).
> In section 4.35
> ---------------
>
> http://jibbering.com/faq/#FAQ4_35
>
> "Some browsers may be configured to disallow scripts from setting the
> status."
> My proposal is to change "Some" by "Most". At least, the most frequently
> used browsers out there have user preferences having veto power over
> script.
> In fact, already most browsers (at least recent ones)
> disallow by default status bar text updates via script.
> So, I'd say that
> *Most* browsers can prevent scripts from setting the status bar text and
> they are pre-configured to disallow scripts from setting the
> status.
Changed to:
Most browsers are configured, by default, to disallow scripts from
setting the status bar text.
<snip>
> In section 4.41
> ---------------
>
> http://jibbering.com/faq/#FAQ4_41
>
> The given link
> http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access
> should be
> http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Accessing_Elements_with_the_W3C_DOM
Changed.
> In section 4.42
> ---------------
>
> http://jibbering.com/faq/#FAQ4_42
>
> A complete, cross-browser and (pretty well) up to date reference is
> available at
> DOM:window.open
> http://developer.mozilla.org/en/docs/DOM:window.open
Added.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
FAQ Notes: http://www.jibbering.com/faq/faq_notes/faq_notes.html
ECMAScript Language Specification via FAQ2.6
VK
> If you can find a good reputable link on conditional comments it can be
> added. Not sure adding a link to a page on browser detection would be a
> good idea in a section saying don't use browser detection :)
>
> (I have wondered why hiding CSS is even mentioned in a JS FAQ).
I'm sharing your doubts about conditional comments (while the
conditional compilation is surely connected with javascript
programming, but it is another matter).
If one decides to go with conditional comments info in FAQ then the
most complete yet short summary AFAIK is made by your humble
servant :-) in "bye-bye holly hack..." post at ciwas, see
<http://groups.google.com/group/
comp.infosystems.www.authoring.stylesheets/msg/5ee25a044f4503e2>
Anyone is welcome to remove the introduction and use the explanatory
part as it is.
Richard Cornford
> Gérard Talbot said the following on 3/4/2007 1:13 AM:
> (I have wondered why hiding CSS is even mentioned in a JS FAQ).
I would speculate that it was because of a demand to use javascript (and
javascript browser detection in particular) to compensate for browser's
varying CSS support. As with many such demands the 'correct' answer is
not to use javascript at all, but instead to use a more direct and/or
reliable approach.
<snip>
>> The given link
>> http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access
>> should be
>> http://developer.mozilla.org/en/docs/Using_Web_Standards_
>> in_your_Web_Pages#Accessing_Elements_with_the_W3C_DOM
>
> Changed.
<snip>
It is a pity that this, much longer, URL will be broken (literally and
effectively) in many text presentations of the FAQ. Generally I am in
favour of meaningful URLs, but sometimes things go too far.
Richard.
Gérard Talbot
> FAQEditor wrote:
>> Gérard Talbot said the following on 3/4/2007 1:13 AM:
> <snip>
>> (I have wondered why hiding CSS is even mentioned in a JS FAQ).
>
> I would speculate that it was because of a demand to use javascript (and
> javascript browser detection in particular) to compensate for browser's
> varying CSS support. As with many such demands the 'correct' answer is
> not to use javascript at all, but instead to use a more direct and/or
> reliable approach.
Sometimes, one may want to use a stylesheet only for, say, MSIE 6 and
another stylesheet for MSIE 7. This can be logical, possible, since both
MSIE 6 and MSIE 7 are used by a lot of internet users and since MSIE 7
has fixed a lot of CSS bugs.
"(...) We would like to ask your help in cleaning up existing CSS hacks
in your pages for IE7. (...) For IE7, we (...) cleaned up our parser
bugs. This leads now to several CSS hacks failing. (...) If you want to
target IE or bypass IE, you can use conditional comments
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/ccomment_ovw.asp>.
"
Call to action: The demise of CSS hacks and broken pages
IE Blog
October 12th 2005
http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx
> <snip>
>>> The given link
>>> http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access
>>> should be
>>> http://developer.mozilla.org/en/docs/Using_Web_Standards_
>>> in_your_Web_Pages#Accessing_Elements_with_the_W3C_DOM
>>
>> Changed.
> <snip>
>
> It is a pity that this, much longer, URL will be broken (literally and
> effectively) in many text presentations of the FAQ. Generally I am in
> favour of meaningful URLs, but sometimes things go too far.
>
> Richard.
I absolutely and completely understand and share your opinion on this
(length of url), in particular length of fragment identifier (a
reference to the identified fragment of that document). I have
unfortunately zero control over how URL to inner sections
(#Fragment_identifier) of a Mozilla Developer Center (MDC) document is
created. I certainly wish the old anchor names would have been kept.
I worked over 18 months in bug 74952
<https://bugzilla.mozilla.org/show_bug.cgi?id=74952>
to improve that document when it was hosted at www.mozilla.org. And
then, I had to migrate it to MDC while it had to be migrated under XHTML
1.0 transitional DTD (already an illogical decision considering what the
document itself was saying) along with many editorial conventions and
coding conventions which, I believe, were clearly not best, otherwise
incoherent.
Gérard
Gérard Talbot
> Gérard Talbot said the following on 3/4/2007 1:13 AM:
>> Hello Randy and Jim,
>> To add in the list of links:
>>
>> Developing Cross Browser/Cross Platform Pages
>> http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Developing_Cross_Browser.2FCross_Platform_Pages
>
>
> The URL is added.
[snipped]
Thank you!
> If you can find a good reputable link on conditional comments it can be
> added. Not sure adding a link to a page on browser detection would be a
> good idea in a section saying don't use browser detection :)
[snipped]
The best I have found is referred by IE blog itself:
"(...) We would like to ask your help in cleaning up existing CSS hacks
in your pages for IE7. (...) For IE7, we (...) cleaned up our parser
bugs. This leads now to several CSS hacks failing. (...) If you want to
target IE or bypass IE, you can use conditional comments
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/ccomment_ovw.asp>.
"
Call to action: The demise of CSS hacks and broken pages
IE Blog
October 12th 2005
http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx
> Changed to:
>
> Most browsers are configured, by default, to disallow scripts from
> setting the status bar text.
>
[snipped]
Great! Excellent!
>> should be
>> http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages#Accessing_Elements_with_the_W3C_DOM
>
>
> Changed.
Bravo!
>> In section 4.42
>> ---------------
>>
>> http://jibbering.com/faq/#FAQ4_42
>>
>> A complete, cross-browser and (pretty well) up to date reference is
>> available at
>> DOM:window.open
>> http://developer.mozilla.org/en/docs/DOM:window.open
>
> Added.
Possibly another FAQ-worthy link is
Interactive Mozilla popup window help testcase debugger
http://www.gtalbot.org/BugzillaSection/MozPopupHelpTestcaseDebugger.html
which is a complete cross-browser updated popup window debugger that I
use (as empirical basis) for fixing bug 195867
<https://bugzilla.mozilla.org/show_bug.cgi?id=195867>
see comment #c7
Please notify Jim Ley that the document at
<http://jibbering.com/du/MozPopupHelpTestcaseDebugger.html>
can be replaced with a link to
<http://www.gtalbot.org/BugzillaSection/MozPopupHelpTestcaseDebugger.html>
Best regards,
Gérard
Randy Webb
> Richard Cornford wrote :
>> FAQEditor wrote:
>>> Gérard Talbot said the following on 3/4/2007 1:13 AM:
>> <snip>
>>> (I have wondered why hiding CSS is even mentioned in a JS FAQ).
>>
>> I would speculate that it was because of a demand to use javascript
>> (and javascript browser detection in particular) to compensate for
>> browser's varying CSS support. As with many such demands the 'correct'
>> answer is not to use javascript at all, but instead to use a more
>> direct and/or reliable approach.
>
>
> Sometimes, one may want to use a stylesheet only for, say, MSIE 6 and
> another stylesheet for MSIE 7. This can be logical, possible, since both
> MSIE 6 and MSIE 7 are used by a lot of internet users and since MSIE 7
> has fixed a lot of CSS bugs.
"If you want to hide CSS styles for certain browsers, try asking in
news:comp.infosystems.www.authoring.stylesheets"
I still don't see where hiding CSS is a JS issue.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb
<snip>
> Please notify Jim Ley that the document at
> <http://jibbering.com/du/MozPopupHelpTestcaseDebugger.html>
> can be replaced with a link to
> <http://www.gtalbot.org/BugzillaSection/MozPopupHelpTestcaseDebugger.html>
The best way to handle that is to email Jim directly.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Randy Webb
> FAQEditor wrote:
<snip>
> <snip>
>>> The given link
>>> http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access
>>> should be
>>> http://developer.mozilla.org/en/docs/Using_Web_Standards_
>>> in_your_Web_Pages#Accessing_Elements_with_the_W3C_DOM
>>
>> Changed.
> <snip>
>
> It is a pity that this, much longer, URL will be broken (literally and
> effectively) in many text presentations of the FAQ. Generally I am in
> favour of meaningful URLs, but sometimes things go too far.
That one goes *way* too far in trying to be a meaningful URL.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Randy Webb
> On Mar 4, 7:52 pm, FAQEditor <clj...@ctvea.net> wrote:
>> If you can find a good reputable link on conditional comments it can be
>> added. Not sure adding a link to a page on browser detection would be a
>> good idea in a section saying don't use browser detection :)
>>
>> (I have wondered why hiding CSS is even mentioned in a JS FAQ).
>
> I'm sharing your doubts about conditional comments (while the
> conditional compilation is surely connected with javascript
> programming, but it is another matter).
Conditional Comments have nothing to do with JS other than that you can
include JS for particular browsers in them.
> If one decides to go with conditional comments info in FAQ then the
> most complete yet short summary AFAIK is made by your humble
> servant :-) in "bye-bye holly hack..." post at ciwas, see
> <http://groups.google.com/group/comp.infosystems.www.authoring.stylesheets/msg/5ee25a044f4503e2>
I am so dumb that I would think this URL:
<URL:
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/ccomment_ovw.asp>
would be a much better resource than a URL to a VK posting.
The least you could have done was provided the URL to the entire thread:
BTW, you need a better posting agent that won't hose URL's.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Dr J R Stockton
Sun, 4 Mar 2007 01:13:45, Gérard Talbot <newsbl...@gtalbot.org>
posted:
>
>Somewhere, a link to a document on conditional comment to
>identify/detect IE6 or IE7 would be good.
ISTM that the FAQ should be aimed to help with two types of use -
reading javascript and writing javascript. All who write javascript
should also be readers, and some will need to read without wanting to
write. The FAQ is mostly aimed at writers.
For the readers, ISTM that there should be a FAQ question something like
"What's this funny stuff that I see", with a two-part answer.
(1) Seen in Web page code - give enough information so that conditional
comment, VBscript, ... might be recognised as such, with links to
outside sources of information such as the corresponding newsgroup (if
apparently functional).
(2) Seen elsewhere, for example in News or on Web page text - it may
look like javascript, but it could be C or C++ or ...; links likewise.
Essentially, it should be a re-routing, rather than an answering, FAQ
entry; if mote is to be done under the same general aegis, it could be
done in a FAQ note, and, for the better distribution of labour, by a
different maintainer.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Gérard Talbot
> "If you want to hide CSS styles for certain browsers, try asking in
> news:comp.infosystems.www.authoring.stylesheets"
>
> I still don't see where hiding CSS is a JS issue.
Ok, then. Since the issue is not a JS one, then you can avoid that issue.