Script for Hiding/Un-Hiding Text On Click
Ste
I've got a website with a list of Frequently Asked Questions, so
there's a question and answer in a long list down the page.
Can anyone recommend a simple script that would allow me to hide each
answer when the page loaded, but then made them individually
appear/disappear when clicking the question?
I'm after a solution that will degrade gracefully if a page doesn't
load, i.e. unlike this example which doesn't seem to show the answers
if JavaScript is disabled (when it should actually show everything if
there's no JavaScript): http://www.virb.com/faq
Thanks for any advice on this,
Ste
David Mark
"Ste" <623...@343.com> wrote in message
news:46a10574$0$15853$fa0f...@news.zen.co.uk...
Right. Don't do it like that. Give the answers a class (eg "answer") and
use JS to write (or append) a style block containing a rule like:
p.answer {display:none}
Also write (or append) the "show answer" interface elements with script so
that users without script enabled won't see them. These are typically links
that call a common handler in their onclick events to display a single
answer. To identify which answer to display, pass its id to the handler.
To display the associated element, use document.getElementById to retrieve
it and set its display style to "block" or "inline."
That's a simple solution. If you don't know how to write it, find a FAQ
page that works without script and look at the code. Most work in a similar
fashion.
Ste
Thanks for this. I know HTML/CSS but not JavaScript, so I'll have to
try and find a site that already does this. I across them all the time
but now I want one, I can't find one!
I did find some tutorials for jQuery and mootools, but to be honest, I
couldn't get these to work even after following the tutorials!
Thanks,
Ste
David Mark
[snip]
> I did find some tutorials for jQuery and mootools, but to be honest, I
> couldn't get these to work even after following the tutorials!
>
You certainly don't need jquery or mootools for this. And if you
don't know JS at all, you should learn a bit before attempting this.
Ste
I actually found a script that did what I wanted, except that I had to
enter 'display = 'none' to make it hide all the text by default (as I
don't want answers to appear until the question is clicked, unless
JavaScript is disabled, then everything should appear), but this has
the side effect that it just doesn't degrade nicely when JavaScript is
disabled (so similar to tha virb link).
From the code below, is there a simple piece of code I can add in order
to make it display 'none' if JavaScript is enabled, or not if it's
disabled?
<script type="text/javascript">
<!--
function toggle_visibility(id) {
var e = document.getElementById(id);
if(e.style.display == 'none')
e.style.display = 'block';
else
e.style.display = 'none';
}
//-->
</script>
........
<a href="#" onclick="toggle_visibility('foo');">Click here to toggle
visibility of element #foo</a><div id="foo">This is foo</div>
Thanks,
Ste
Jim
------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title> FAQ
</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<style type="text/css">
div#question {
font-weight:bold;
margin-bottom:5px;
}
div#question a {
display: block;
margin-left:20px;
text-decoration: none;
color:black;
}
/*this rule must be set for it to work*/
div#question a:hover {
background: none;
}
div#question a span {
display: none;
}
div#question a:hover span {
display: inline;
padding: 25px;
width:150px;
}
</style>
</head>
<body >
<h3>Place your mouse/cursor over "Answer" to view the answers</h3>
<ol>
<li><div id="question">
Question: Who's buried in Grant's Tomb?<br/>
<a href="#" >Answer:
<span> → President Grant</span>
</a>
</div></li>
<li><div id="question">
Question: What color are bananas?<br/>
<a href="#" >Answer:
<span> → Yellow</span>
</a>
</div></li>
<li><div id="question">
Question: What is 2 + 2?<br/>
<a href="#" >Answer:
<span> → 4 </span>
</a>
</div></li>
</ol>
</body>
</html>
David Mark
> Ste, here's a css mouseover solution as well:
> ------------------------------------------------
> <?xml version="1.0" encoding="utf-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
> <head>
> <title> FAQ
> </title>
> <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
> <style type="text/css">
> div#question {
> font-weight:bold;
> margin-bottom:5px;
> }
>
> div#question a {
> display: block;
> margin-left:20px;
> text-decoration: none;
> color:black;
> }
>
> /*this rule must be set for it to work*/
> div#question a:hover {
> background: none;
> }
I don't see that.
This solution overlooks keyboard users. These rules work better:
div#question {
font-weight:bold;
margin-bottom:5px;
}
div#question a {
display: block;
margin-left:20px;
text-decoration: none;
color:black;
}
div#question a span {
display: none
}
div#question a:hover span, div#question a:active span, div#question
a:focus span {
display: inline
}
But I contend that displaying the answers in this manner (on rollovers
and focus) is an odd solution.
David Mark
> On 2007-07-20 21:51:17 +0100, David Mark <dmark.cins...@gmail.com> said:
>
> > On Jul 20, 4:41 pm, Ste <6df...@5dfg25.com> wrote:
> > [snip]
> >> I did find some tutorials for jQuery and mootools, but to be honest, I
> >> couldn't get these to work even after following the tutorials!
>
> > You certainly don't need jquery or mootools for this. And if you
> > don't know JS at all, you should learn a bit before attempting this.
>
> I actually found a script that did what I wanted, except that I had to
> enter 'display = 'none' to make it hide all the text by default (as I
> don't want answers to appear until the question is clicked, unless
> JavaScript is disabled, then everything should appear), but this has
> the side effect that it just doesn't degrade nicely when JavaScript is
> disabled (so similar to tha virb link).
>
> From the code below, is there a simple piece of code I can add in order
> to make it display 'none' if JavaScript is enabled, or not if it's
> disabled?
[snip]
I think I mentioned how to do this before, but I didn't realize you
had no scripting experience. Here is a simple example. Put the
script in an external file and you can reuse it with any page that
contains the same structure (a div with id="questions" that contains
one or more div's with class="question", each containing an anchor for
the question and a div for the answer.)
<html>
<head>
<script type="text/javascript">
if (document.getElementById) document.write('<style type="text/
css">div.question div {display:none} div.question a
{cursor:pointer;text-decoration:underline;color:blue}</style>');
function showAnswer() {
var p = this.parentNode;
if (p) {
var a = p.getElementsByTagName('div');
if (a.length) a[0].style.display = (a[0].style.display ==
'block')?'none':'block'
}
}
function windowLoad() {
var el = document.getElementById('questions');
if (el) {
var links = el.getElementsByTagName('a');
for (var i = links.length - 1; i >= 0; i--)
links[i].onclick = showAnswer
}
}
window.onload = windowLoad;
</script>
</head>
<body>
<div id="questions">
<div class="question">
<a name="q1">Q. Why am I here?</a>
<div>A. I don't know what to tell you.</div>
</div>
<div class="question">
<a name="q2">Q. Why are you here?</a>
<div>A. Don't you know?</div>
</div>
</div>
</body>
</html>
ASM
message sibyllin suivant :
>
> I've got a website with a list of Frequently Asked Questions, so there's
> a question and answer in a long list down the page.
>
> Can anyone recommend a simple script
Not so "simple" because of to degrade gracefully
> that would allow me to hide each
> answer when the page loaded, but then made them individually
> appear/disappear when clicking the question?
It could easily be made with css but ...
IE (even IE 7 I think) can't understand speudo class :hover if not in a link
> I'm after a solution that will degrade gracefully if a page doesn't
> load, i.e. unlike this example which doesn't seem to show the answers if
> JavaScript is disabled (when it should actually show everything if
> there's no JavaScript): http://www.virb.com/faq
I don't know what they do, but the easiest way could be to :
- set css rules to hide answers
and to show answers when necessary (not understood by IE<7)
- css rules to show answers if it is IE
- set by JS the css rule to hide answer
if the browser can understand the css or JS code to show them
- create JS function to hide/swhow answers if this IE can understand
> Thanks for any advice on this,
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<head>
<title>questions and answers</title>
<style type="text/css">
#FAQ { cursor: pointer; _cursor: hand; }
#FAQ dd { color: maroon; background:#eee; }
#FAQ dl:hover dd,
#FAQ dl.ie dd { display: block; }
</style>
<script type="text/javascript">
if(document.getElementById)
document.write('<style type="text/css">#FAQ dd '+
'{display:none;}<\/style>');
// following is for IE (Win and Mac)
var IE = /*@cc_on!@*/false;
if(IE && document.getElementById) {
function hs(what) { // hide/show answer
while(what.tagName.toLowerCase() != 'dl') what = what.parentNode;
what.className = what.className==''? 'ie' : '';
}
window.onload = function() {
var A = document.getElementById('FAQ');
A = A.getElementsByTagName('dt');
for(var i=0; i<A.length; i++) {
A[i].onmouseover = function(){ hs(this);};
A[i].onmouseout = function(){ hs(this);};
}
}
}
</script>
</head>
<body>
<div id="FAQ">
<dl>
<dt>Question 1 :</dt>
<dd>Answer 1</dd>
</dl>
<dl>
<dt>Question 2 :</dt>
<dd>Answer 2<br>
and one line more</dd>
</dl>
<dl>
<dt>Question 3 :</dt>
<dd>Answer 3</dd>
</dl>
<dl>
<dt>Question 4 :</dt>
<dd>Answer 4</dd>
</dl>
</div>
</body>
</html>
--
Stephane Moriaux et son (moins) vieux Mac
David Mark
wrote:
[snip]
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <head>
> <title>questions and answers</title>
> <style type="text/css">
> #FAQ { cursor: pointer; _cursor: hand; }
Why not:
cursor:pointer;cursor:hand
Standards-based browsers will just throw out the second one. And you
should put the "hand" rule in an IE conditional comment.
I don't follow the semantics. They are slightly improved from the
empty semantics in my original example, but it seems like a FAQ would
be a single definition list.
And then there is the keyboard access issue. I think this is a
preferable solution:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>FAQ</title>
<script type="text/javascript">
if (document.getElementById) document.write('<style type="text/
css">#questions dd {display:none}<\/style>');
function showAnswer() {
var id = this.id;
var el = document.getElementById('a' + id.substring(1));
if (el) el.style.display = (el.style.display ==
'block')?'none':'block';
return false
}
function windowLoad() {
var el = document.getElementById('questions');
if (el) {
var links = el.getElementsByTagName('a');
for (var i = links.length - 1; i >= 0; i--) {
links[i].onclick = showAnswer;
links[i].href = '#';
links[i].tabIndex = 0
}
}
}
window.onload = windowLoad
</script>
</head>
<body>
<dl id="questions">
<dt><a id="q1">Q. Why am I here?</a></dt>
<dd id="a1">A. I don't know what to tell you.</dd>
<dt><a id="q2">Q. Why are you here?</a></dt>
<dd id="a2">A. Don't you know?</dd>
</dl>
</body>
</html>
Randy Webb
> On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> wrote:
> [snip]
<snip>
>> #FAQ { cursor: pointer; _cursor: hand; }
>
> Why not:
>
> cursor:pointer;cursor:hand
>
> Standards-based browsers will just throw out the second one. And you
> should put the "hand" rule in an IE conditional comment.
And why is that? There may be a browser other than IE that doesn't
support cursor: pointer but that supports cursor:hand and by putting
them in an IE conditional you just ruled out a potential browser for no
reason at all. The "Standards-based browsers" will simply ignore it and
no harm is done.
<snip>
> I don't follow the semantics. They are slightly improved from the
> empty semantics in my original example, but it seems like a FAQ would
> be a single definition list.
>
> And then there is the keyboard access issue. I think this is a
> preferable solution:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
> TR/html4/strict.dtd">
Two ongoing threads where you are defending the use of XHTML on the web
and you post an HTML4 example. WOW!
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>FAQ</title>
> <script type="text/javascript">
> if (document.getElementById) document.write('<style type="text/
> css">#questions dd {display:none}<\/style>');
That is a preposterously inept test. I would think that a test for the
ability to change the styles *might* be a better test. But, simply
testing for getElementById doesn't even come close to what you need to
test for to know whether to write the style tag or not. It also doesn't
cover the aspect of CSS disabled browsers.
> function windowLoad() {
> var el = document.getElementById('questions');
No test here to see if the browser supports gEBI or not?
> if (el) {
> var links = el.getElementsByTagName('a');
What makes you sure the browser supports getElementsByTagName?
<snip>
So no, your code doesn't come close to being a "preferable" solution. It
may be better than what was posted.....
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
David Mark
> David Mark said the following on 7/22/2007 6:20 PM:
>
> > On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> > wrote:
> > [snip]
>
> <snip>
>
> >> #FAQ { cursor: pointer; _cursor: hand; }
>
> > Why not:
>
> > cursor:pointer;cursor:hand
>
> > Standards-based browsers will just throw out the second one. And you
> > should put the "hand" rule in an IE conditional comment.
>
> And why is that? There may be a browser other than IE that doesn't
> support cursor: pointer but that supports cursor:hand and by putting
> them in an IE conditional you just ruled out a potential browser for no
> reason at all. The "Standards-based browsers" will simply ignore it and
> no harm is done.
Except your CSS is invalid!
>
> <snip>
>
> > I don't follow the semantics. They are slightly improved from the
> > empty semantics in my original example, but it seems like a FAQ would
> > be a single definition list.
>
> > And then there is the keyboard access issue. I think this is a
> > preferable solution:
>
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
> > TR/html4/strict.dtd">
>
> Two ongoing threads where you are defending the use of XHTML on the web
> and you post an HTML4 example. WOW!
Did you really want me to post an XML version? To do so would require
including the XML prolog as the character set meta tag would obviously
be omitted. It wouldn't be of much use as a static example.
>
> > <html>
> > <head>
> > <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> > <title>FAQ</title>
> > <script type="text/javascript">
> > if (document.getElementById) document.write('<style type="text/
> > css">#questions dd {display:none}<\/style>');
>
> That is a preposterously inept test. I would think that a test for the
Not true. If document.getElementById is not supported then you don't
want to write this style. See below.
> ability to change the styles *might* be a better test. But, simply
> testing for getElementById doesn't even come close to what you need to
> test for to know whether to write the style tag or not. It also doesn't
> cover the aspect of CSS disabled browsers.
Tested in Mozilla with no style, no script and both together.
Everything is fine. The only nit-pick you could make is that when
style is disabled and scripting is enabled (an odd case to be sure),
the anchors look like links. The logical solution to that is simple
and can be found at the end of the post.
>
> > function windowLoad() {
> > var el = document.getElementById('questions');
Here you are correct. The onload listener should not be attached
without testing for document.getElementById. This is in symmetry with
the document.write line. I can now see why you misunderstood the
intention of testing document.getElementById before writing the style
rule.
>
> No test here to see if the browser supports gEBI or not?
>
> > if (el) {
> > var links = el.getElementsByTagName('a');
>
> What makes you sure the browser supports getElementsByTagName?
What browser supports getElementById, but not getElementsByTagName?
If you can come up with one, then there should be two feature tests
before writing the style and attaching the onload handler.
>
> <snip>
>
> So no, your code doesn't come close to being a "preferable" solution. It
Preferable is relative.
> may be better than what was posted.....
See the previous sentence. And by "may be", I assume you did compare
it to the previous post. So what exactly are you saying? Other than
the point about detecting getElementById, what would you suggest to
improve it?
I didn't claim the previous post was perfection. But tell me this
isn't:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>FAQ</title>
<script type="text/javascript">
if (document.getElementById) document.write('<style type="text/
css">#questions dd {display:none}<\/style>');
function showAnswer() {
var id = this.id;
var el = document.getElementById('a' + id.substring(1));
if (el) el.style.display = (el.style.display ==
'block')?'none':'block'
}
function windowLoad() {
var el = document.getElementById('questions');
if (el) {
var links = el.getElementsByTagName('a');
for (var i = links.length - 1; i >= 0; i--) {
links[i].onclick = showAnswer;
links[i].href = '#a' + (i + 1);
links[i].tabIndex = 0
}
}
}
if (document.getElementById) window.onload = windowLoad
ASM
le message sibyllin suivant :
> On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> wrote:
> [snip]
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>> "http://www.w3.org/TR/html4/strict.dtd">
>> <head>
>> <title>questions and answers</title>
>> <style type="text/css">
>> #FAQ { cursor: pointer; _cursor: hand; }
>
> Why not:
>
> cursor:pointer;cursor:hand
yes, why not.
(I don't remember if my IE(Mac) can read '_cursor'
nor if he understands 'hand')
>
> Standards-based browsers will just throw out the second one. And you
> should put the "hand" rule in an IE conditional comment.
certainly, but I built this example several times with/without IE
conditionnal comments and ... see above about IE(Mac)
(I'm almost sure IE(Mac) doesn't read '_cursor' but understands 'pointer')
As never I was abble to do something with keyboard access with my
Firefox on my Mac ... I squeeze this aspect.
> I think this is a preferable solution:
Except all browsers will have to run this JS as all of them except IE
could easier do the job with CSS.
Except you need a lot of ids, growing possibilities of mistakes (or errors)
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
> TR/html4/strict.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>FAQ</title>
> <script type="text/javascript">
> if (document.getElementById) document.write('<style type="text/
> css">#questions dd {display:none}<\/style>');
> function showAnswer() {
> var id = this.id;
> var el = document.getElementById('a' + id.substring(1));
> if (el) el.style.display = (el.style.display ==
> 'block')?'none':'block';
> return false
> }
> function windowLoad() {
> var el = document.getElementById('questions');
> if (el) {
> var links = el.getElementsByTagName('a');
Why won't you assign that to DTs ?
and suppress all your anchors changed to links
and give the IDs now in the loop to the DTs and DDs
> for (var i = links.length - 1; i >= 0; i--) {
> links[i].onclick = showAnswer;
> links[i].href = '#';
> links[i].tabIndex = 0
not understood ...
(tabindex to 0 for everybody ?)
> }
> }
> }
function windowLoad() {
var el = document.getElementById('questions');
if (el) {
var links = el.getElementsByTagName('DT');
var targs = el.getElementsByTagName('DD');
for (var i = 0; i<links.length; i++) {
links[i].id = 'l'+i;
targs[i].id = 'a'+i;
links[i].onclick = showAnswer;
links[i].tabIndex = i;
}
}
}
window.onload = windowLoad
</script>
</head>
<body>
<dl id="questions">
<dt>Q. Why am I here?</dt>
<dd>A. I don't know what to tell you.</dd>
<dt>Q. Why are you here?</dt>
<dd>A. Don't you know?</dd>
</dl>
</body>
</html>
--
David Mark
wrote:
> En r?ponse ? David Mark qui nous a susurr?, en date du : 23/07/07 0:20,
> le message sibyllin suivant :
>
> > On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> > wrote:
> > [snip]
> >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> >> "http://www.w3.org/TR/html4/strict.dtd">
> >> <head>
> >> <title>questions and answers</title>
> >> <style type="text/css">
> >> #FAQ { cursor: pointer; _cursor: hand; }
>
> > Why not:
>
> > cursor:pointer;cursor:hand
>
> yes, why not.
> (I don't remember if my IE(Mac) can read '_cursor'
> nor if he understands 'hand')
If IE for the Mac does not understand "hand", then it should ignore it
and use "pointer."
>
>
>
> > Standards-based browsers will just throw out the second one. And you
> > should put the "hand" rule in an IE conditional comment.
>
> certainly, but I built this example several times with/without IE
> conditionnal comments and ... see above about IE(Mac)
> (I'm almost sure IE(Mac) doesn't read '_cursor' but understands 'pointer')
IE Mac will ignore the contents of the conditional comment, as will
the validators.
I don't understand you there. Firefox for the Mac doesn't tab through
links?
>
> > I think this is a preferable solution:
>
> Except all browsers will have to run this JS as all of them except IE
> could easier do the job with CSS.
Without JS it degrades to show the answers without user interaction.
>
> Except you need a lot of ids, growing possibilities of mistakes (or errors)
If it is to be semantic (eg not nested div's like my first example or
multiple lists as in yours), the id's are necessary. I would think a
FAQ would normally be created with CGI, which would eliminate the
possibility or human error in assigning the id's.
>
>
>
>
>
>
>
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
> > TR/html4/strict.dtd">
> > <html>
> > <head>
> > <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> > <title>FAQ</title>
> > <script type="text/javascript">
> > if (document.getElementById) document.write('<style type="text/
> > css">#questions dd {display:none}<\/style>');
> > function showAnswer() {
> > var id = this.id;
> > var el = document.getElementById('a' + id.substring(1));
> > if (el) el.style.display = (el.style.display ==
> > 'block')?'none':'block';
> > return false
> > }
> > function windowLoad() {
> > var el = document.getElementById('questions');
> > if (el) {
> > var links = el.getElementsByTagName('a');
>
> Why won't you assign that to DTs ?
> and suppress all your anchors changed to links
> and give the IDs now in the loop to the DTs and DDs
If I understand you correctly, you would prefer to assign a tabIndex
to the dt elements and style them to look like links. That could work
too, but I would worry that older browsers and devices might not
support tabstops for dt elements.
>
> > for (var i = links.length - 1; i >= 0; i--) {
> > links[i].onclick = showAnswer;
> > links[i].href = '#';
> > links[i].tabIndex = 0
>
> not understood ...
> (tabindex to 0 for everybody ?)
This makes the tab order the same as the source order. It is odd that
it would be required to assign a tabIndex, but at least one browser I
tested (Opera I think) refused to tab through the newly created links
without this step. BTW, I posted a follow-up that assigns meaningful
href's instead of "#" and it is useful to note that you could add
these attributes to the tags themselves (rather than with script.) I
suspect that Opera would no longer require the tabIndex assignment in
that case, but on the other hand, the anchors would always be (fairly
useless) links, even with scripting disabled (I prefer them to remain
anchors in that case.)
ASM
le message sibyllin suivant :
> David Mark said the following on 7/22/2007 6:20 PM:
>> On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
>> wrote:
[snip]
>> if (document.getElementById) document.write('<style type="text/
>> css">#questions dd {display:none}<\/style>');
>
> That is a preposterously inept test.
Thanks a lot ! I think it is almost my own code ...
> I would think that a test for the
> ability to change the styles *might* be a better test.
Development ?
> It also doesn't cover the aspect of CSS disabled browsers.
?? if CSS are disabled, what is the importance ?
My NC4.5 ignores these CSS (and this JS gBEI) and all seems OK.
FF css disabled : all OK
>> function windowLoad() {
>> var el = document.getElementById('questions');
>
> No test here to see if the browser supports gEBI or not?
I think, here it is not important as these browsers are supposed to
display all the body.
Usually if a browser doesn't support gEBI it ignores this one.
>> if (el) {
>> var links = el.getElementsByTagName('a');
>
> What makes you sure the browser supports getElementsByTagName?
if(el) no ?
Are there browsers that support gBEI and not getElementsByTagName ?
> <snip>
>
> So no, your code doesn't come close to being a "preferable" solution. It
> may be better than what was posted.....
Is it or not ?
and why ?
(I've passed my code to the validator : all OK)
Richard Cornford
> On Jul 22, 6:37 pm, Randy Webb wrote:
>> David Mark said the following on 7/22/2007 6:20 PM:
>>> Why not:
>>
>>> cursor:pointer;cursor:hand
>>
>>> Standards-based browsers will just throw out the second one.
>>> And you should put the "hand" rule in an IE conditional comment.
>>
>> And why is that? There may be a browser other than IE that doesn't
>> support cursor: pointer but that supports cursor:hand and by putting
>> them in an IE conditional you just ruled out a potential browser for
>> no reason at all. The "Standards-based browsers" will simply ignore
>> it and no harm is done.
>
> Except your CSS is invalid!
That is very questionable. The CSS specs mandate the handling of
unrecognised property names and values (they are to be ignored in all
cases, which IE fails to do) and so the question arises as to why it is
necessary to mandate the handling of unrecognised properties and values
if a notion of validity is attached that precludes their appearing in
the first place.
<snip>
>>> <html>
>>> <head>
>>> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>>> <title>FAQ</title>
>>> <script type="text/javascript">
>>> if (document.getElementById) document.write('<style type="text/
>>> css">#questions dd {display:none}<\/style>');
>>
>> That is a preposterously inept test. I would think that a test for
>> the
>
> Not true. If document.getElementById is not supported then you don't
> want to write this style. See below.
<snip>
You also don't want to write the script element whenever the browser
supports - getElementById - but does not support (or react to) the
dynamic assignment of display property values on its element's style
objects. A characteristic that was common in the days of Opera 6 but is
now relegated to the less-capable end of the embedded browser market.
Richard.
David Mark
wrote:
> David Mark wrote:
> > On Jul 22, 6:37 pm, Randy Webb wrote:
> >> David Mark said the following on 7/22/2007 6:20 PM:
> <snip>
> >>> Why not:
>
> >>> cursor:pointer;cursor:hand
>
> >>> Standards-based browsers will just throw out the second one.
> >>> And you should put the "hand" rule in an IE conditional comment.
>
> >> And why is that? There may be a browser other than IE that doesn't
> >> support cursor: pointer but that supports cursor:hand and by putting
> >> them in an IE conditional you just ruled out a potential browser for
> >> no reason at all. The "Standards-based browsers" will simply ignore
> >> it and no harm is done.
>
> > Except your CSS is invalid!
>
> That is very questionable. The CSS specs mandate the handling of
> unrecognised property names and values (they are to be ignored in all
> cases, which IE fails to do) and so the question arises as to why it is
> necessary to mandate the handling of unrecognised properties and values
> if a notion of validity is attached that precludes their appearing in
> the first place.
According to the w3c validator and the error consoles of various
browsers, it is invalid. Maybe they will change the rules in the
future.
>
> <snip>>>> <html>
> >>> <head>
> >>> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> >>> <title>FAQ</title>
> >>> <script type="text/javascript">
> >>> if (document.getElementById) document.write('<style type="text/
> >>> css">#questions dd {display:none}<\/style>');
>
> >> That is a preposterously inept test. I would think that a test for
> >> the
>
> > Not true. If document.getElementById is not supported then you don't
> > want to write this style. See below.
>
> <snip>
>
> You also don't want to write the script element whenever the browser
I assume you mean "style element."
> supports - getElementById - but does not support (or react to) the
> dynamic assignment of display property values on its element's style
> objects. A characteristic that was common in the days of Opera 6 but is
> now relegated to the less-capable end of the embedded browser market.
I think we can forget about Opera 6 at this point, but what other
browsers (embedded or otherwise) display this behavior? It doesn't
sound like anything that can be feature-detected and virtually any Web
application will break under the described circumstances. Is it just
the display property or do all attempts to manipulate style with
script fail?
Randy Webb
> On Jul 22, 6:37 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 7/22/2007 6:20 PM:
>>
>>> On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
>>> wrote:
>>> [snip]
>> <snip>
>>
>>>> #FAQ { cursor: pointer; _cursor: hand; }
>>> Why not:
>>> cursor:pointer;cursor:hand
>>> Standards-based browsers will just throw out the second one. And you
>>> should put the "hand" rule in an IE conditional comment.
>> And why is that? There may be a browser other than IE that doesn't
>> support cursor: pointer but that supports cursor:hand and by putting
>> them in an IE conditional you just ruled out a potential browser for no
>> reason at all. The "Standards-based browsers" will simply ignore it and
>> no harm is done.
>
> Except your CSS is invalid!
You might be intrigued to search the archives and find out what my
opinion of validation - whether it be X/HTML, CSS or anything else. Give
me what *works*, not what "validates". The "validator" says the type
attribute is required on a script element, yet the only type attribute
for it is deprecated. So much for "validation".
>> <snip>
>>
>>> I don't follow the semantics. They are slightly improved from the
>>> empty semantics in my original example, but it seems like a FAQ would
>>> be a single definition list.
>>> And then there is the keyboard access issue. I think this is a
>>> preferable solution:
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
>>> TR/html4/strict.dtd">
>> Two ongoing threads where you are defending the use of XHTML on the web
>> and you post an HTML4 example. WOW!
>
> Did you really want me to post an XML version? To do so would require
> including the XML prolog as the character set meta tag would obviously
> be omitted. It wouldn't be of much use as a static example.
You missed the point, but I expected no more.
>>> <html>
>>> <head>
>>> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>>> <title>FAQ</title>
>>> <script type="text/javascript">
>>> if (document.getElementById) document.write('<style type="text/
>>> css">#questions dd {display:none}<\/style>');
>> That is a preposterously inept test. I would think that a test for the
>
> Not true. If document.getElementById is not supported then you don't
> want to write this style. See below.
Again, you missed the point. You don't want that CSS written if:
a) You can't get a reference to the element (getElementById)
b) You can't change the style property of that element.
Not even the supposition that gEBI is present and that the style
property is present will assure you that you can change it.
>> ability to change the styles *might* be a better test. But, simply
>> testing for getElementById doesn't even come close to what you need to
>> test for to know whether to write the style tag or not. It also doesn't
>> cover the aspect of CSS disabled browsers.
>
> Tested in Mozilla with no style, no script and both together.
> Everything is fine. The only nit-pick you could make is that when
> style is disabled and scripting is enabled (an odd case to be sure),
> the anchors look like links. The logical solution to that is simple
> and can be found at the end of the post.
So you agree with me that your "example" wasn't as good as you thought
it was?
>>> function windowLoad() {
>>> var el = document.getElementById('questions');
>
> Here you are correct. The onload listener should not be attached
> without testing for document.getElementById. This is in symmetry with
> the document.write line. I can now see why you misunderstood the
> intention of testing document.getElementById before writing the style
> rule.
It had nothing to do with the onload listener. It has to do with your
assumption that if the UA supports getElementById then you can change
the styles dynamically and that is a false assumption.
>> No test here to see if the browser supports gEBI or not?
>>
>>> if (el) {
>>> var links = el.getElementsByTagName('a');
>> What makes you sure the browser supports getElementsByTagName?
>
> What browser supports getElementById, but not getElementsByTagName?
> If you can come up with one, then there should be two feature tests
> before writing the style and attaching the onload handler.
And you think that is a better position than testing for it and not
caring if a browser doesn't support it? One way the browser silently
degrades, the other way it doesn't - it throws an error. Which is more
user friendly?
>
>> <snip>
>>
>> So no, your code doesn't come close to being a "preferable" solution. It
>
> Preferable is relative.
>
>> may be better than what was posted.....
>
> See the previous sentence. And by "may be", I assume you did compare
> it to the previous post. So what exactly are you saying? Other than
> the point about detecting getElementById, what would you suggest to
> improve it?
>
> I didn't claim the previous post was perfection. But tell me this
> isn't:
OK, it isn't. Make you feel better? Whether I think it is or not, I
simply said it because you wanted me to. But no, it isn't. Not even
close because you still haven't realized the problem with this testing:
<snip>
> if (document.getElementById) document.write('<style type="text/
> css">#questions dd {display:none}<\/style>');
The simple fact that a browser supports gEBI means *nothing* when it
comes to dynamically altering the CSS properties of an element and that
is the *only* reason for wanting that CSS there to start with. It is
referred to as "feature detection" and falls into a category known as
"defensive programming".
> function windowLoad() {
> var el = document.getElementById('questions');
> if (el) {
> var links = el.getElementsByTagName('a');
Again, you are - incorrectly - assuming that because the browser
supports gEBI that it must support getElementsByTagName and that is -
once again - a faulty assumption. And bear in mind that until recently
(in the last year or so) there was a *very* *regular* poster in this
group that used IE4 exclusively. And emulating gEBI on IE4 is trivial.
> if (document.getElementById) window.onload = windowLoad
That test - once again - is fatally flawed. Reread the post to figure
out why.
No, this isn't my first rodeo.
Randy Webb
<snip>
>> supports - getElementById - but does not support (or react to) the
>> dynamic assignment of display property values on its element's style
>> objects. A characteristic that was common in the days of Opera 6 but is
>> now relegated to the less-capable end of the embedded browser market.
>
> I think we can forget about Opera 6 at this point, but what other
> browsers (embedded or otherwise) display this behavior? It doesn't
> sound like anything that can be feature-detected and virtually any Web
> application will break under the described circumstances. Is it just
> the display property or do all attempts to manipulate style with
> script fail?
I doubt that you would ever come up with a completely fool proof test
for whether you could successfully manipulate the style property of an
element. But, at least testing for the properties you want is better
than not testing at all, isn't it?
if (elemRef && elemRef.style && elemRef.style.visibility)
Would surely have to be better than not testing for it at all. You can
substitute display for visibility as the situation dictates.
ASM
le message sibyllin suivant :
> David Mark said the following on 7/22/2007 9:37 PM:
>> On Jul 22, 9:13 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
>> wrote:
>
> <snip>
>>> supports - getElementById
I expect were are here :
<script type="text/javascript">
if(document.getElementById)
document.write('<style type="text/css">#FAQ dd '+
'{display:none;}<\/style>');
> But, at least testing for the properties you want is better
> than not testing at all, isn't it?
>
> if (elemRef && elemRef.style && elemRef.style.visibility)
>
> Would surely have to be better than not testing for it at all. You can
> substitute display for visibility as the situation dictates.
What I would like to know is :
how do you explain to different browsers what is 'elemRef' ?
ASM
> On Jul 22, 7:52 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> wrote:
>> En r?ponse ? David Mark qui nous a susurr?, en date du : 23/07/07 0:20,
>> le message sibyllin suivant :
>>
>>> cursor:pointer;cursor:hand
>> yes, why not.
>> (I don't remember if my IE(Mac) can read '_cursor'
>> nor if he understands 'hand')
>
> If IE for the Mac does not understand "hand", then it should ignore it
> and use "pointer."
I like so much speaking of IE "it should" :-)
Between what it should and what it does there is a world.
> IE Mac will ignore the contents of the conditional comment, as will
> the validators.
Good.
>> As never I was abble to do something with keyboard access with my
>> Firefox on my Mac ... I squeeze this aspect.
>
> I don't understand you there. Firefox for the Mac doesn't tab through
> links?
There are so much system's shortcuts and Fx shortcuts ...
that I can't see (or remenber) which touch or associations of touches I
have to type to go directly to a tab-indexed element.
(probably I marmalade with 'acceskey' ?)
>> Except all browsers will have to run this JS as all of them except IE
>> could easier do the job with CSS.
>
> Without JS it degrades to show the answers without user interaction.
so it does with CSS
>> Except you need a lot of ids, growing possibilities of mistakes (or errors)
>
> If it is to be semantic (eg not nested div's like my first example or
> multiple lists as in yours), the id's are necessary. I would think a
> FAQ would normally be created with CGI, which would eliminate the
> possibility or human error in assigning the id's.
OK in this point of view.
[links]
>> Why won't you assign that to DTs ?
>> and suppress all your anchors changed to links
>> and give the IDs now in the loop to the DTs and DDs
>
> If I understand you correctly, you would prefer to assign a tabIndex
> to the dt elements and style them to look like links. That could work
> too, but I would worry that older browsers and devices might not
> support tabstops for dt elements.
I prefer clear, small and direct html without apparent complications :-)
I don't know what this or that browser (which understands given css and
js) will do with these tab-index.
I'm not sure whatever is the browser it'll can do something with
tab-index in a DT (about tab-index, is this tag referenced in specs?)
>>> for (var i = links.length - 1; i >= 0; i--) {
>>> links[i].onclick = showAnswer;
>>> links[i].href = '#';
>>> links[i].tabIndex = 0
>> not understood ...
>> (tabindex to 0 for everybody ?)
>
> This makes the tab order the same as the source order.
Ha ! OK.
(but were are following source order in this loop, no ?)
> (Opera I think) refused to tab through the newly created links
> without this step.
Rhaaaa la la ! this Opera !
Haven't we enough jokes with IE ?
David Mark
> David Mark said the following on 7/22/2007 7:36 PM:
>
>
>
>
>
> > On Jul 22, 6:37 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> David Mark said the following on 7/22/2007 6:20 PM:
>
> >>> On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
> >>> wrote:
> >>> [snip]
> >> <snip>
>
> >>>> #FAQ { cursor: pointer; _cursor: hand; }
> >>> Why not:
> >>> cursor:pointer;cursor:hand
> >>> Standards-based browsers will just throw out the second one. And you
> >>> should put the "hand" rule in an IE conditional comment.
> >> And why is that? There may be a browser other than IE that doesn't
> >> support cursor: pointer but that supports cursor:hand and by putting
> >> them in an IE conditional you just ruled out a potential browser for no
> >> reason at all. The "Standards-based browsers" will simply ignore it and
> >> no harm is done.
>
> > Except your CSS is invalid!
>
> You might be intrigued to search the archives and find out what my
> opinion of validation - whether it be X/HTML, CSS or anything else. Give
> me what *works*, not what "validates". The "validator" says the type
> attribute is required on a script element, yet the only type attribute
> for it is deprecated. So much for "validation".
Type of "text/javascript" validates and works, but is deprecated.
What's the problem?
>
> >> <snip>
>
> >>> I don't follow the semantics. They are slightly improved from the
> >>> empty semantics in my original example, but it seems like a FAQ would
> >>> be a single definition list.
> >>> And then there is the keyboard access issue. I think this is a
> >>> preferable solution:
> >>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
> >>> TR/html4/strict.dtd">
> >> Two ongoing threads where you are defending the use of XHTML on the web
> >> and you post an HTML4 example. WOW!
>
> > Did you really want me to post an XML version? To do so would require
> > including the XML prolog as the character set meta tag would obviously
> > be omitted. It wouldn't be of much use as a static example.
>
> You missed the point, but I expected no more.
Posting a static XML version of an entire page would be pointless.
What I posted was appropriate and has nothing to do with the XHTML vs.
HTML threads.
>
> >>> <html>
> >>> <head>
> >>> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> >>> <title>FAQ</title>
> >>> <script type="text/javascript">
> >>> if (document.getElementById) document.write('<style type="text/
> >>> css">#questions dd {display:none}<\/style>');
> >> That is a preposterously inept test. I would think that a test for the
>
> > Not true. If document.getElementById is not supported then you don't
> > want to write this style. See below.
>
> Again, you missed the point. You don't want that CSS written if:
> a) You can't get a reference to the element (getElementById)
Yep.
> b) You can't change the style property of that element.
There's no reliable way to know that. So nobody tests for that. Name
one browser that supports getElementById, but cannot change style
properties.
>
> Not even the supposition that gEBI is present and that the style
> property is present will assure you that you can change it.
Again, name one agent. Just one. Alternatively, post a code example
that tests for this occasion.
>
> >> ability to change the styles *might* be a better test. But, simply
> >> testing for getElementById doesn't even come close to what you need to
> >> test for to know whether to write the style tag or not. It also doesn't
> >> cover the aspect of CSS disabled browsers.
>
> > Tested in Mozilla with no style, no script and both together.
> > Everything is fine. The only nit-pick you could make is that when
> > style is disabled and scripting is enabled (an odd case to be sure),
> > the anchors look like links. The logical solution to that is simple
> > and can be found at the end of the post.
>
> So you agree with me that your "example" wasn't as good as you thought
> it was?
How good do you think I thought it was? I said it was a preferable
example to the mouse-only version posted before it. The second
getElementById test was obviously left out by mistake. So it wasn't
perfect. Why you couldn't see the simple solution and suggested a
bunch of nonsense about testing styles in lieu of making the feature
detection symmetric is beyond me.
>
> >>> function windowLoad() {
> >>> var el = document.getElementById('questions');
>
> > Here you are correct. The onload listener should not be attached
> > without testing for document.getElementById. This is in symmetry with
> > the document.write line. I can now see why you misunderstood the
> > intention of testing document.getElementById before writing the style
> > rule.
>
> It had nothing to do with the onload listener. It has to do with your
> assumption that if the UA supports getElementById then you can change
> the styles dynamically and that is a false assumption.
I am making no such assumption. There simply is no test for whether
styles can be changed dynamically. If you had to test for that, you
couldn't write anything that hides and shows elements.
>
> >> No test here to see if the browser supports gEBI or not?
>
> >>> if (el) {
> >>> var links = el.getElementsByTagName('a');
> >> What makes you sure the browser supports getElementsByTagName?
>
> > What browser supports getElementById, but not getElementsByTagName?
> > If you can come up with one, then there should be two feature tests
> > before writing the style and attaching the onload handler.
>
> And you think that is a better position than testing for it and not
> caring if a browser doesn't support it? One way the browser silently
> degrades, the other way it doesn't - it throws an error. Which is more
> user friendly?
There just aren't any agents out there that support one and not the
other. But it isn't hard to add a test for getElementsByClassName if
you are worried about that. I'll leave that as an exercise.
>
>
>
>
>
>
>
> >> <snip>
>
> >> So no, your code doesn't come close to being a "preferable" solution. It
>
> > Preferable is relative.
>
> >> may be better than what was posted.....
>
> > See the previous sentence. And by "may be", I assume you did compare
> > it to the previous post. So what exactly are you saying? Other than
> > the point about detecting getElementById, what would you suggest to
> > improve it?
>
> > I didn't claim the previous post was perfection. But tell me this
> > isn't:
>
> OK, it isn't. Make you feel better? Whether I think it is or not, I
> simply said it because you wanted me to. But no, it isn't. Not even
> close because you still haven't realized the problem with this testing:
>
> <snip>
>
> > if (document.getElementById) document.write('<style type="text/
> > css">#questions dd {display:none}<\/style>');
>
There you go again. That test makes no sense on its own. But paired
with the identical test a few lines down, it makes perfect sense.
> The simple fact that a browser supports gEBI means *nothing* when it
> comes to dynamically altering the CSS properties of an element and that
> is the *only* reason for wanting that CSS there to start with. It is
> referred to as "feature detection" and falls into a category known as
> "defensive programming".
Again. I am through explaining the symmetry of the testing in this
example. You clearly don't get it.
>
> > function windowLoad() {
> > var el = document.getElementById('questions');
> > if (el) {
> > var links = el.getElementsByTagName('a');
>
> Again, you are - incorrectly - assuming that because the browser
> supports gEBI that it must support getElementsByTagName and that is -
> once again - a faulty assumption. And bear in mind that until recently
> (in the last year or so) there was a *very* *regular* poster in this
> group that used IE4 exclusively. And emulating gEBI on IE4 is trivial.
Now what are you talking about? If a developer creates their own gEBI
that calls document.all and pastes this example into their page and
runs it in IE4, then they will need to add the addition test for
getElementsByClassName. Like I said, I will leave that addition as an
exercise for those in this less-than-regular situation.
>
> > if (document.getElementById) window.onload = windowLoad
>
> That test - once again - is fatally flawed. Reread the post to figure
> out why.
I don't have to re-read anything. You just keep repeating the same
thing as if I don't understand and that is a silly thing to do.
>
> No, this isn't my first rodeo.
>
Odd that at the end of the day, you haven't posted a single line of
code. Where's the "if styles can be changed" feature test? It
obviously is just a theoretical waste of time.
David Mark
> David Mark said the following on 7/22/2007 9:37 PM:
>
> > On Jul 22, 9:13 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> > wrote:
>
> <snip>
>
> >> supports - getElementById - but does not support (or react to) the
> >> dynamic assignment of display property values on its element's style
> >> objects. A characteristic that was common in the days of Opera 6 but is
> >> now relegated to the less-capable end of the embedded browser market.
>
> > I think we can forget about Opera 6 at this point, but what other
> > browsers (embedded or otherwise) display this behavior? It doesn't
> > sound like anything that can be feature-detected and virtually any Web
> > application will break under the described circumstances. Is it just
> > the display property or do all attempts to manipulate style with
> > script fail?
>
> I doubt that you would ever come up with a completely fool proof test
> for whether you could successfully manipulate the style property of an
There you go. So all of that repetition advocating such a thing was a
waste of time.
> element. But, at least testing for the properties you want is better
> than not testing at all, isn't it?
Not really. See below.
>
> if (elemRef && elemRef.style && elemRef.style.visibility)
And some code too! Now we are getting somewhere. Wrong property for
this example though.
That doesn't mean you can change it. In fact, it could be argued that
if the style property is absent, then the agent likely doesn't support
CSS at all and therefore the first example degrades gracefully, and
the revision degrades perfectly.
Randy Webb
It was a shorthand for the reference to an element. In most cases, it
would look something like this:
if (document.getElementById && document.getElementById('someID')){
elemRef = document.getElementById('someId')
Randy Webb
You don't find anything ironically amusing about the W3C telling you to
use a feature that it deprecated? I do.
>>>>> <html>
>>>>> <head>
>>>>> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>>>>> <title>FAQ</title>
>>>>> <script type="text/javascript">
>>>>> if (document.getElementById) document.write('<style type="text/
>>>>> css">#questions dd {display:none}<\/style>');
>>>> That is a preposterously inept test. I would think that a test for the
>>> Not true. If document.getElementById is not supported then you don't
>>> want to write this style. See below.
>> Again, you missed the point. You don't want that CSS written if:
>> a) You can't get a reference to the element (getElementById)
> Yep.
>> b) You can't change the style property of that element.
>
> There's no reliable way to know that. So nobody tests for that. Name
> one browser that supports getElementById, but cannot change style
> properties.
Sure there is. See my code at the bottom.
>> Not even the supposition that gEBI is present and that the style
>> property is present will assure you that you can change it.
>
> Again, name one agent. Just one. Alternatively, post a code example
> that tests for this occasion.
You are thinking backwards. Your attitude is "Until someone names one, I
don't have to worry about it". Mine is, if I code against that
possibility, I don't have to worry about it. One is a flawed attitude to
have.
<snip>
>>>>> function windowLoad() {
>>>>> var el = document.getElementById('questions');
>>> Here you are correct. The onload listener should not be attached
>>> without testing for document.getElementById. This is in symmetry with
>>> the document.write line. I can now see why you misunderstood the
>>> intention of testing document.getElementById before writing the style
>>> rule.
>> It had nothing to do with the onload listener. It has to do with your
>> assumption that if the UA supports getElementById then you can change
>> the styles dynamically and that is a false assumption.
>
> I am making no such assumption. There simply is no test for whether
> styles can be changed dynamically. If you had to test for that, you
> couldn't write anything that hides and shows elements.
I can't? Hmmm. I think I can. See below.
>>>> No test here to see if the browser supports gEBI or not?
>>>>> if (el) {
>>>>> var links = el.getElementsByTagName('a');
>>>> What makes you sure the browser supports getElementsByTagName?
>>> What browser supports getElementById, but not getElementsByTagName?
>>> If you can come up with one, then there should be two feature tests
>>> before writing the style and attaching the onload handler.
>> And you think that is a better position than testing for it and not
>> caring if a browser doesn't support it? One way the browser silently
>> degrades, the other way it doesn't - it throws an error. Which is more
>> user friendly?
>
> There just aren't any agents out there that support one and not the
> other. But it isn't hard to add a test for getElementsByClassName if
> you are worried about that. I'll leave that as an exercise.
I hope your "libraries" aren't riddled with that thought process. If
they are, then it is a good thing we haven't seen any of them.
>>>> <snip>
>>>> So no, your code doesn't come close to being a "preferable" solution. It
>>> Preferable is relative.
>>>> may be better than what was posted.....
>>> See the previous sentence. And by "may be", I assume you did compare
>>> it to the previous post. So what exactly are you saying? Other than
>>> the point about detecting getElementById, what would you suggest to
>>> improve it?
>>> I didn't claim the previous post was perfection. But tell me this
>>> isn't:
>> OK, it isn't. Make you feel better? Whether I think it is or not, I
>> simply said it because you wanted me to. But no, it isn't. Not even
>> close because you still haven't realized the problem with this testing:
>>
>> <snip>
>>
>>> if (document.getElementById) document.write('<style type="text/
>>> css">#questions dd {display:none}<\/style>');
>
> There you go again. That test makes no sense on its own. But paired
> with the identical test a few lines down, it makes perfect sense.
No, the test is moronic whether it is duplicated or not. The style
element isn't even needed in the page at all for a modern browser. Even
if it is (I think IE6 didn't like manipulating styles that weren't
defined), it would be hard coded as display: block. See below.
>> The simple fact that a browser supports gEBI means *nothing* when it
>> comes to dynamically altering the CSS properties of an element and that
>> is the *only* reason for wanting that CSS there to start with. It is
>> referred to as "feature detection" and falls into a category known as
>> "defensive programming".
>
> Again. I am through explaining the symmetry of the testing in this
> example. You clearly don't get it.
I think that anyone that has coded JS for any amount of time can figure
out who "Gets it" and who doesn't.
<snip>
>>> if (document.getElementById) window.onload = windowLoad
>> That test - once again - is fatally flawed. Reread the post to figure
>> out why.
>
> I don't have to re-read anything. You just keep repeating the same
> thing as if I don't understand and that is a silly thing to do.
>
>> No, this isn't my first rodeo.
>>
>
> Odd that at the end of the day, you haven't posted a single line of
> code. Where's the "if styles can be changed" feature test? It
> obviously is just a theoretical waste of time.
It is? You get brownie points if you can correctly answer the last
question in this code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>FAQ</title>
<script type="text/javascript">
function showAnswer() {
var id = this.id;
var el = document.getElementById('a' + id.substring(1));
if (el) el.style.display = (el.style.display == 'block')?'none':'block';
return false
}
function windowLoad() {
var el = document.getElementById('questions')
if (el &&
el.getElementsByTagName &&
el.getElementsByTagName('a') &&
el.getElementsByTagName('dd') )
{
var links = el.getElementsByTagName('a');
var answers = el.getElementsByTagName('dd')
for (var i = links.length - 1; i >= 0; i--)
{
links[i].onclick = showAnswer;
links[i].href = '#';
links[i].tabIndex = 0;
if (answers[i].style)
{
answers[i].style.display = "none";
}
}
}
}
window.onload = windowLoad
</script>
</head>
<body>
<dl id="questions">
<dt><a id="q1">Q. Why isn't there a style element in the source code of
this page?</a></dt>
<dd id="a1">A. It isn't needed as the styles are only set if the browser
can set it.</dd>
<dt><a id="q2">Q. What happens if the browser can't set them?</a></dt>
<dd id="a2">A. Then the answers stay visible for fallback.</dd>
<dt><a id="q3">Q. Why won't the space far activate the links?</a></dt>
<dd id="a3">A. That is a damn good question.</dd>
<dt><a id="q4">Q. Why is this solution better?</a></dt>
<dd id="a4">A. It degrades better than the previous version.</dd>
<dt><a id="q5">Q. Why is there no test for gEBI on the window.onload
call?</a></dt>
<dd id="a5">A. Because whether gEBI is present or not is irrelevant
there.</dd>
<dt><a id="q6">Q. What happens if there is no display property of the
style elemnt?</a></dt>
<dd id="a6">A. Then it assigns it a new property and leaves the answers
visible. Change it to "chicken" to see it fall through gracefully.</dd>
<dt><a id="q7">Q. Are there any other flaws in this code?</a></dt>
<dd id="a7">A. Yes. Can you, as a "programmer" tell me what they are?</dd>
</dl>
</body>
</html>
David Mark
What difference does it make if you find it amusing?
No, I don't think you have a clue what my attitude is. I simply left
the further improvement of the example as an exercise. Do whatever
you want with it.
What "libraries?" I think I mentioned one specific library in another
thread. Is that what you are talking about? If so, your hopes about
it are not of any concern as you don't use XHTML. I don't see how it
is either good or bad that you (and the mouse in your pocket) haven't
seen it.
>
>
>
>
>
> >>>> <snip>
> >>>> So no, your code doesn't come close to being a "preferable" solution. It
> >>> Preferable is relative.
> >>>> may be better than what was posted.....
> >>> See the previous sentence. And by "may be", I assume you did compare
> >>> it to the previous post. So what exactly are you saying? Other than
> >>> the point about detecting getElementById, what would you suggest to
> >>> improve it?
> >>> I didn't claim the previous post was perfection. But tell me this
> >>> isn't:
> >> OK, it isn't. Make you feel better? Whether I think it is or not, I
> >> simply said it because you wanted me to. But no, it isn't. Not even
> >> close because you still haven't realized the problem with this testing:
>
> >> <snip>
>
> >>> if (document.getElementById) document.write('<style type="text/
> >>> css">#questions dd {display:none}<\/style>');
>
> > There you go again. That test makes no sense on its own. But paired
> > with the identical test a few lines down, it makes perfect sense.
>
> No, the test is moronic whether it is duplicated or not. The style
Either you don't get it or you are trying to turn this discussion into
a personal attack. I don't really care either way as I am about ready
to stop reading your posts entirely.
> element isn't even needed in the page at all for a modern browser. Even
What in God's name are you babbling about now? The style element
isn't needed for a modern browser? What does that mean?
> if it is (I think IE6 didn't like manipulating styles that weren't
> defined)
You think wrong.
> it would be hard coded as display: block. See below.
Hard coded? display: block? That's the default!
>
> >> The simple fact that a browser supports gEBI means *nothing* when it
> >> comes to dynamically altering the CSS properties of an element and that
> >> is the *only* reason for wanting that CSS there to start with. It is
> >> referred to as "feature detection" and falls into a category known as
> >> "defensive programming".
>
> > Again. I am through explaining the symmetry of the testing in this
> > example. You clearly don't get it.
>
> I think that anyone that has coded JS for any amount of time can figure
> out who "Gets it" and who doesn't.
Yes. I am sure the lurkers are with you.
>
> <snip>
>
> >>> if (document.getElementById) window.onload = windowLoad
> >> That test - once again - is fatally flawed. Reread the post to figure
> >> out why.
>
> > I don't have to re-read anything. You just keep repeating the same
> > thing as if I don't understand and that is a silly thing to do.
>
> >> No, this isn't my first rodeo.
>
> > Odd that at the end of the day, you haven't posted a single line of
> > code. Where's the "if styles can be changed" feature test? It
> > obviously is just a theoretical waste of time.
>
> It is? You get brownie points if you can correctly answer the last
> question in this code:
You seem to be confused. Lets see how you did on your assignment to
improve my code. By the way, it took you long enough to complete.
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>FAQ</title>
> <script type="text/javascript">
>
> function showAnswer() {
> var id = this.id;
> var el = document.getElementById('a' + id.substring(1));
> if (el) el.style.display = (el.style.display == 'block')?'none':'block';
> return false}
>
> function windowLoad() {
> var el = document.getElementById('questions')
> if (el &&
> el.getElementsByTagName &&
> el.getElementsByTagName('a') &&
> el.getElementsByTagName('dd') )
> {
> var links = el.getElementsByTagName('a');
> var answers = el.getElementsByTagName('dd')
> for (var i = links.length - 1; i >= 0; i--)
> {
> links[i].onclick = showAnswer;
> links[i].href = '#';
If you are going to copy my code, at least copy the last version
posted.
> links[i].tabIndex = 0;
> if (answers[i].style)
> {
> answers[i].style.display = "none";
This is hardly an improvement. What you've done is make the answers
flash for a second during the page load. Furthermore, you now have
links that don't do anything if this assignment does not update the
screen (in whatever fantasy user agent you are "defending" against.)
> }
> }
> }}
>
> window.onload = windowLoad
Wrong. See below.
> </script>
> </head>
> <body>
> <dl id="questions">
> <dt><a id="q1">Q. Why isn't there a style element in the source code of
> this page?</a></dt>
> <dd id="a1">A. It isn't needed as the styles are only set if the browser
> can set it.</dd>
> <dt><a id="q2">Q. What happens if the browser can't set them?</a></dt>
> <dd id="a2">A. Then the answers stay visible for fallback.</dd>
> <dt><a id="q3">Q. Why won't the space far activate the links?</a></dt>
> <dd id="a3">A. That is a damn good question.</dd>
No it isn't. What makes you think the space bar activates links? Try
the enter key.
> <dt><a id="q4">Q. Why is this solution better?</a></dt>
> <dd id="a4">A. It degrades better than the previous version.</dd>
Degrades better for browsers that don't exist, but is far uglier for
many browsers that do exist. I don't like it.
> <dt><a id="q5">Q. Why is there no test for gEBI on the window.onload
> call?</a></dt>
> <dd id="a5">A. Because whether gEBI is present or not is irrelevant
> there.</dd>
You didn't test for it anywhere, which is obviously incorrect. The
very first line of windowLoad attempts to use the getElementById
method. (!)
> <dt><a id="q6">Q. What happens if there is no display property of the
> style elemnt?</a></dt>
I assume you meant "display property of the style object."
> <dd id="a6">A. Then it assigns it a new property and leaves the answers
> visible. Change it to "chicken" to see it fall through gracefully.</dd>
> <dt><a id="q7">Q. Are there any other flaws in this code?</a></dt>
Yes. And apparently in your personality too.
> <dd id="a7">A. Yes. Can you, as a "programmer" tell me what they are?</dd>
Can you as a "jackass" try to understand that this thread is not a
contest? Your series of posts here seem to exist only to impress me.
I'm not impressed with the noisy buildup and the "payoff" turned out
to be a flawed fizzle. What a waste of time.
Randy Webb
> On Jul 23, 6:16 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> David Mark said the following on 7/23/2007 2:08 PM:
>>> On Jul 23, 12:56 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>> David Mark said the following on 7/22/2007 7:36 PM:
>>>>> On Jul 22, 6:37 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>>>> David Mark said the following on 7/22/2007 6:20 PM:
>>>>>>> On Jul 21, 8:18 pm, ASM <stephanemoriaux.NoAd...@wanadoo.fr.invalid>
>>>>>>> wrote:
<snip>
>>>>>>> <html>
Your coding style - and the defense of it - says a lot about your
attitude about browser scripting. And the lack in your abilities of
successfully doing so.
<snip>
>>>>>> No test here to see if the browser supports gEBI or not?
>>>>>>> if (el) {
>>>>>>> var links = el.getElementsByTagName('a');
>>>>>> What makes you sure the browser supports getElementsByTagName?
>>>>> What browser supports getElementById, but not getElementsByTagName?
>>>>> If you can come up with one, then there should be two feature tests
>>>>> before writing the style and attaching the onload handler.
>>>> And you think that is a better position than testing for it and not
>>>> caring if a browser doesn't support it? One way the browser silently
>>>> degrades, the other way it doesn't - it throws an error. Which is more
>>>> user friendly?
>>> There just aren't any agents out there that support one and not the
>>> other. But it isn't hard to add a test for getElementsByClassName if
>>> you are worried about that. I'll leave that as an exercise.
>> I hope your "libraries" aren't riddled with that thought process. If
>> they are, then it is a good thing we haven't seen any of them.
>
> What "libraries?" I think I mentioned one specific library in another
> thread. Is that what you are talking about? If so, your hopes about
> it are not of any concern as you don't use XHTML. I don't see how it
> is either good or bad that you (and the mouse in your pocket) haven't
> seen it.
It is your claim - in that "other thread" - that your code works
flawlessly whether the browser interprets the code as HTML or XHTML so
your claim that I don't use XHMTL (which is wrong in itself) is no
defense at all. Does your local college offer a class in public debate?
If so, you should take it as you suck at it.
>>>>>> <snip>
>>>>>> So no, your code doesn't come close to being a "preferable" solution. It
>>>>> Preferable is relative.
>>>>>> may be better than what was posted.....
>>>>> See the previous sentence. And by "may be", I assume you did compare
>>>>> it to the previous post. So what exactly are you saying? Other than
>>>>> the point about detecting getElementById, what would you suggest to
>>>>> improve it?
>>>>> I didn't claim the previous post was perfection. But tell me this
>>>>> isn't:
>>>> OK, it isn't. Make you feel better? Whether I think it is or not, I
>>>> simply said it because you wanted me to. But no, it isn't. Not even
>>>> close because you still haven't realized the problem with this testing:
>>>> <snip>
>>>>> if (document.getElementById) document.write('<style type="text/
>>>>> css">#questions dd {display:none}<\/style>');
>>> There you go again. That test makes no sense on its own. But paired
>>> with the identical test a few lines down, it makes perfect sense.
>> No, the test is moronic whether it is duplicated or not. The style
>
> Either you don't get it or you are trying to turn this discussion into
> a personal attack. I don't really care either way as I am about ready
> to stop reading your posts entirely.
It has nothing to do with being personal or not, the test for
document.getElementById is moronic if you think it satisfies the
requirement for knowing whether to write the style block or not.
>> element isn't even needed in the page at all for a modern browser. Even
>
> What in God's name are you babbling about now? The style element
> isn't needed for a modern browser? What does that mean?
It means precisely what I wrote. Can you not read plain English? The
style element doesn't have to be written for a "modern browser". Any of
the modern browsers don't need it there in order to manipulate the styles.
>> if it is (I think IE6 didn't like manipulating styles that weren't
>> defined)
>
> You think wrong.
Ok. I didn't really care at the time as it was irrelevant to me.
>> it would be hard coded as display: block. See below.
>
> Hard coded? display: block? That's the default!
You really are as inept as I thought you were. It may have been IE5.0,
IE5.5 I don't remember but it wouldn't allow you to modify a style if it
was not hard coded into the page. The way the code I wrote is written if
the browser couldn't modify it without it being hard coded then you
would have to hard code it. And to be able to - successfully -
manipulate it then you would hard code it and the only way to hard code
it to make it gracefully degrade would be to code it as display: block.
The fact that you know nothing about that speaks volumes.
>> <snip>
>>
>>>>> if (document.getElementById) window.onload = windowLoad
>>>> That test - once again - is fatally flawed. Reread the post to figure
>>>> out why.
>>> I don't have to re-read anything. You just keep repeating the same
>>> thing as if I don't understand and that is a silly thing to do.
>>>> No, this isn't my first rodeo.
>>> Odd that at the end of the day, you haven't posted a single line of
>>> code. Where's the "if styles can be changed" feature test? It
>>> obviously is just a theoretical waste of time.
>> It is? You get brownie points if you can correctly answer the last
>> question in this code:
>
> You seem to be confused. Lets see how you did on your assignment to
> improve my code. By the way, it took you long enough to complete.
The only one confused on how to write cross-browser degrading code is
you. Also, it was not an "assignment" (I will leave those for your
instructor to give you), it was proof of concept to show you how inept
you are at what you claim to do for a living.
I didn't copy "code", I copied some garbage text and modified it. There
is a difference but I doubt you would understand the difference.
>> links[i].tabIndex = 0;
>> if (answers[i].style)
>> {
>> answers[i].style.display = "none";
>
> This is hardly an improvement. What you've done is make the answers
> flash for a second during the page load. Furthermore, you now have
> links that don't do anything if this assignment does not update the
> screen (in whatever fantasy user agent you are "defending" against.)
The difference is that mine degrades, yours doesn't.
BTW, that "fantasy user agent" you keep alluding to is my cell phone
browser that supports gEBI but does not support modifying display
properties nor does it support getElementsByClassName. I know, I know,
you can't be bothered to support such devices as you don't know how.
>> }
>> }
>> }}
>>
>> window.onload = windowLoad
>
> Wrong. See below.
The only person wrong here is you. You just fail to see it is all.
>> </script>
>> </head>
>> <body>
>> <dl id="questions">
>> <dt><a id="q1">Q. Why isn't there a style element in the source code of
>> this page?</a></dt>
>> <dd id="a1">A. It isn't needed as the styles are only set if the browser
>> can set it.</dd>
>> <dt><a id="q2">Q. What happens if the browser can't set them?</a></dt>
>> <dd id="a2">A. Then the answers stay visible for fallback.</dd>
>> <dt><a id="q3">Q. Why won't the space far activate the links?</a></dt>
>> <dd id="a3">A. That is a damn good question.</dd>
>
> No it isn't. What makes you think the space bar activates links?
Because that is precisely how I have to activate links in that "Fantasy
User Agent" you don't know how to support. The lower left key (*)
activates the "Enter key" functionality. The lower right key (#)
activates the "Space Bar" functionality and the only way to activate a
link with it is the space bar. Of which it does just fine with hard
coded links, just not dynamically created links.
> Try the enter key.
See above.
>> <dt><a id="q4">Q. Why is this solution better?</a></dt>
>> <dd id="a4">A. It degrades better than the previous version.</dd>
>
> Degrades better for browsers that don't exist, but is far uglier for
> many browsers that do exist. I don't like it.
Try again moron. The code you posted is utterly broken in the "Fantasy
User Agent" I keep telling you about but the code I posted works
flawlessly in it.
>> <dt><a id="q5">Q. Why is there no test for gEBI on the window.onload
>> call?</a></dt>
>> <dd id="a5">A. Because whether gEBI is present or not is irrelevant
>> there.</dd>
>
> You didn't test for it anywhere, which is obviously incorrect. The
> very first line of windowLoad attempts to use the getElementById
> method. (!)
Awww man, now I gotta get depressed, you have a point.
>> <dt><a id="q6">Q. What happens if there is no display property of the
>> style elemnt?</a></dt>
>
> I assume you meant "display property of the style object."
Yes.
>> <dd id="a6">A. Then it assigns it a new property and leaves the answers
>> visible. Change it to "chicken" to see it fall through gracefully.</dd>
>> <dt><a id="q7">Q. Are there any other flaws in this code?</a></dt>
>
> Yes. And apparently in your personality too.
The only flaw in my "personality" is that I think I can educate idiots
like you. Sue me for it.
>> <dd id="a7">A. Yes. Can you, as a "programmer" tell me what they are?</dd>
>
> Can you as a "jackass" try to understand that this thread is not a
> contest?
Is that as original a name as you can call me? I have been called worse
by a lot better than you. You have mistakenly assumed it was a
"contest". It isn't. It was my failed attempt to educate you as to the
flaws in your code.
> Your series of posts here seem to exist only to impress me.
Keep dreaming moron.
> I'm not impressed with the noisy buildup and the "payoff" turned out
> to be a flawed fizzle. What a waste of time.
Yes, but not for the reasons you think. It was a waste of time on my
part to try to educate your dumb ass. Maybe someone in the future that
reads it can learn from it as you obviously can't.
I couldn't be so lucky as to not have you read my posts though as then I
could correct your non-sense babbling without having to waste my time
trying to educate you.
David Mark
Since you haven't posted any code at all, except for a botched re-hash
of mine, I don't think you have much to say on this subject.
>
> <snip>
>
> >>>>>> No test here to see if the browser supports gEBI or not?
> >>>>>>> if (el) {
> >>>>>>> var links = el.getElementsByTagName('a');
> >>>>>> What makes you sure the browser supports getElementsByTagName?
> >>>>> What browser supports getElementById, but not getElementsByTagName?
> >>>>> If you can come up with one, then there should be two feature tests
> >>>>> before writing the style and attaching the onload handler.
> >>>> And you think that is a better position than testing for it and not
> >>>> caring if a browser doesn't support it? One way the browser silently
> >>>> degrades, the other way it doesn't - it throws an error. Which is more
> >>>> user friendly?
> >>> There just aren't any agents out there that support one and not the
> >>> other. But it isn't hard to add a test for getElementsByClassName if
> >>> you are worried about that. I'll leave that as an exercise.
> >> I hope your "libraries" aren't riddled with that thought process. If
> >> they are, then it is a good thing we haven't seen any of them.
>
> > What "libraries?" I think I mentioned one specific library in another
> > thread. Is that what you are talking about? If so, your hopes about
> > it are not of any concern as you don't use XHTML. I don't see how it
> > is either good or bad that you (and the mouse in your pocket) haven't
> > seen it.
>
> It is your claim - in that "other thread" - that your code works
> flawlessly whether the browser interprets the code as HTML or XHTML so
Applications I have written for both are working for both. What does
that have to do with this thread?
> your claim that I don't use XHMTL (which is wrong in itself) is no
> defense at all. Does your local college offer a class in public debate?
Defense of what?
> If so, you should take it as you suck at it.
Never you mind what I should take.
You still don't get that do you?
>
> >> element isn't even needed in the page at all for a modern browser. Even
>
> > What in God's name are you babbling about now? The style element
> > isn't needed for a modern browser? What does that mean?
>
> It means precisely what I wrote. Can you not read plain English? The
> style element doesn't have to be written for a "modern browser". Any of
> the modern browsers don't need it there in order to manipulate the styles.
Which has nothing at all to do with why I wrote it.
>
> >> if it is (I think IE6 didn't like manipulating styles that weren't
> >> defined)
>
> > You think wrong.
>
> Ok. I didn't really care at the time as it was irrelevant to me.
So it is okay to post nonsense as long as it isn't relevant to you?
>
> >> it would be hard coded as display: block. See below.
>
> > Hard coded? display: block? That's the default!
>
> You really are as inept as I thought you were. It may have been IE5.0,
> IE5.5 I don't remember but it wouldn't allow you to modify a style if it
> was not hard coded into the page. The way the code I wrote is written if
> the browser couldn't modify it without it being hard coded then you
> would have to hard code it. And to be able to - successfully -
This is "plain English?"
> manipulate it then you would hard code it and the only way to hard code
> it to make it gracefully degrade would be to code it as display: block.
Which you didn't do in your example. Yes, this is all quite clear.
> The fact that you know nothing about that speaks volumes.
You are very hard to follow.
>
> >> <snip>
>
> >>>>> if (document.getElementById) window.onload = windowLoad
> >>>> That test - once again - is fatally flawed. Reread the post to figure
> >>>> out why.
> >>> I don't have to re-read anything. You just keep repeating the same
> >>> thing as if I don't understand and that is a silly thing to do.
> >>>> No, this isn't my first rodeo.
> >>> Odd that at the end of the day, you haven't posted a single line of
> >>> code. Where's the "if styles can be changed" feature test? It
> >>> obviously is just a theoretical waste of time.
> >> It is? You get brownie points if you can correctly answer the last
> >> question in this code:
>
> > You seem to be confused. Lets see how you did on your assignment to
> > improve my code. By the way, it took you long enough to complete.
>
> The only one confused on how to write cross-browser degrading code is
> you. Also, it was not an "assignment" (I will leave those for your
> instructor to give you), it was proof of concept to show you how inept
> you are at what you claim to do for a living.
LOL. I never claimed anything about what I do for a living. Cite one
post. Inept is thinking that the length of "000" is 1. Want me to
cite that one, professor? I suspect you are still smarting from it
and that explains your attitude.
"Your" example creates dynamic links just like mine. Not surprising
as it is basically mine with a couple of minor modifications.
>
> > Try the enter key.
>
> See above.
See above.
>
> >> <dt><a id="q4">Q. Why is this solution better?</a></dt>
> >> <dd id="a4">A. It degrades better than the previous version.</dd>
>
> > Degrades better for browsers that don't exist, but is far uglier for
> > many browsers that do exist. I don't like it.
>
> Try again moron. The code you posted is utterly broken in the "Fantasy
> User Agent" I keep telling you about but the code I posted works
> flawlessly in it.
And worse in IE, Opera, etc. And why can't you name the device? I
suspect it is an old cell phone from a garage sale. Did you test with
Netscape 4 too?
>
> >> <dt><a id="q5">Q. Why is there no test for gEBI on the window.onload
> >> call?</a></dt>
> >> <dd id="a5">A. Because whether gEBI is present or not is irrelevant
> >> there.</dd>
>
> > You didn't test for it anywhere, which is obviously incorrect. The
> > very first line of windowLoad attempts to use the getElementById
> > method. (!)
>
> Awww man, now I gotta get depressed, you have a point.
Yes. All of that bluster and your code has a worse flaw than mine.
>
> >> <dt><a id="q6">Q. What happens if there is no display property of the
> >> style elemnt?</a></dt>
>
> > I assume you meant "display property of the style object."
>
> Yes.
You'll notice I didn't insult you for the obvious gaffe. You should
take a page out of my book. Nobody respects a wise-ass.
>
> >> <dd id="a6">A. Then it assigns it a new property and leaves the answers
> >> visible. Change it to "chicken" to see it fall through gracefully.</dd>
> >> <dt><a id="q7">Q. Are there any other flaws in this code?</a></dt>
>
> > Yes. And apparently in your personality too.
>
> The only flaw in my "personality" is that I think I can educate idiots
> like you. Sue me for it.
There you go again. Sue you for what? I doubt you have anything I
would want.
>
> >> <dd id="a7">A. Yes. Can you, as a "programmer" tell me what they are?</dd>
>
> > Can you as a "jackass" try to understand that this thread is not a
> > contest?
>
> Is that as original a name as you can call me? I have been called worse
The most fitting. And this isn't a name-calling contest any more than
it is a coding contest.
> by a lot better than you. You have mistakenly assumed it was a
> "contest". It isn't. It was my failed attempt to educate you as to the
> flaws in your code.
>
> > Your series of posts here seem to exist only to impress me.
>
> Keep dreaming moron.
How many times have you used that word in this thread? You only
degrade yourself.
>
> > I'm not impressed with the noisy buildup and the "payoff" turned out
> > to be a flawed fizzle. What a waste of time.
>
> Yes, but not for the reasons you think. It was a waste of time on my
> part to try to educate your dumb ass. Maybe someone in the future that
> reads it can learn from it as you obviously can't.
"Dumb ass", "moron", etc., etc. You are stuck in a parochial rut.
>
> I couldn't be so lucky as to not have you read my posts though as then I
> could correct your non-sense babbling without having to waste my time
> trying to educate you.
In English, please.
Never mind. We're done talking here.
ASM
le message sibyllin suivant :
(very long snip)
> Did you test with Netscape 4 too?
Because it was said "gracefully degrade",
yes I did (NC 4.5)
and ... all OK with single if(gEBI)
...
of corse
David Mark
"ASM" <stephanemor...@wanadoo.fr.invalid> wrote in message
news:46a65b12$0$25906$ba4a...@news.orange.fr...
> En réponse à David Mark qui nous a susurré, en date du : 24/07/07 3:23,
> le message sibyllin suivant :
>
> (very long snip)
>
>> Did you test with Netscape 4 too?
>
> Because it was said "gracefully degrade",
> yes I did (NC 4.5)
> and ... all OK with single if(gEBI)
> ...
> of corse
Right. Both of our solutions will work with any browser that predates
getElementById. Ironically, the other one posted, which purportedly
degraded better, would break all such browsers, including NS4.
ASM
> "ASM" <stephanemor...@wanadoo.fr.invalid> wrote in message
> news:46a65b12$0$25906$ba4a...@news.orange.fr...
>> and ... all OK with single if(gEBI)
>> ...
>> of corse
>
> Right. Both of our solutions will work with any browser that predates
> getElementById. Ironically, the other one posted, which purportedly
> degraded better, would break all such browsers, including NS4.
I didn't follow all the so interested discus but I think adding some
code with conditional precautions wouldn't afraid NC4
if(document.getElementById)
{
// nothing more here would have to be interpreted by NC4
if(docu ... blah
...
Richard Cornford
> On Jul 22, 9:13 pm, Richard Cornford wrote:
>> David Mark wrote:
<snip>
>>> Except your CSS is invalid!
>>
>> That is very questionable. The CSS specs mandate the
>> handling of unrecognised property names and values
>> (they are to be ignored in all cases, which IE fails
>> to do) and so the question arises as to why it is
>> necessary to mandate the handling of unrecognised
>> properties and values if a notion of validity is
>> attached that precludes their appearing in the first
>> place.
>
> According to the w3c validator and the error consoles of
> various browsers, it is invalid.
Not unless you can establish that the concept of validity attaches to
the use of unrecognised property names or value. If the concept
attaches then why does the specification mandate the handling of
unrecognised property names and values, as they would be precluded in
any 'valid' source? The behaviour of w3c 'validator' is not, in itself,
sufficient to indicate that the concept of validity can be applied here.
> Maybe they will change the rules in the
> future.
>
>>
>> <snip>>>> <html>
>>>>> <head>
>>>>> <meta http-equiv="Content-Type" content="text/html;
>>>>> charset=UTF-8">
>>>>> <title>FAQ</title>
>>>>> <script type="text/javascript">
>>>>> if (document.getElementById) document.write('<style type="text/
>>>>> css">#questions dd {display:none}<\/style>');
>>
>>>> That is a preposterously inept test. I would think that a test for
>>>> the
>>
>> > Not true. If document.getElementById is not supported then you
>> > don't
>> > want to write this style. See below.
>>
>> <snip>
>>
>> You also don't want to write the script element whenever the browser
>
> I assume you mean "style element."
I did. Typing "script" is getting a little too automatic.
>> supports - getElementById - but does not support (or react to)
>> the dynamic assignment of display property values on its
>> element's style objects. A characteristic that was common in
>> the days of Opera 6 but is now relegated to the less-capable
>> end of the embedded browser market.
>
> I think we can forget about Opera 6 at this point,
The last brand new mobile phone I encounter that shipped with Opera 6.12
installed was around the new year, so given the turnover of mobile
phones may 'we' can forget about it now.
> but what other browsers (embedded or otherwise) display
> this behavior?
Pretty much all of the ones with non-dynamic DOMs. NetFont 4 ,for
example.
> It doesn't sound like anything that can be feature-detected
It sounded problematic to detect, but it has been observed that all the
instances of browsers actually identified that did not react to dynamic
assignments to a - display - property either did not have a - style -
object on their elements, or (much more commonly) did not have a -
display - property on their style objects. So the proposed test was to
see if an element had both a style object and that that style object had
a 'string' type - display - property. Without both it was pretty
guaranteed that assigning to the display property of the style object
was not going to work in the given environment. Unfortunately that still
falls down as feature detecting because it assumes that if those two
properties do exist then assigning to the - display - property will
result in browser modifying its presentation.
There is also the problem of getting at an element to test when you want
to apply the test in the context of making decisions about writing out
STYLE elements. You want to (must) write the STYLE element in the HEAD
but the only two elements guaranteed to be available at that point are
the HTML and HEAD elements, neither of which are ever displayed as such
(though you might easily argue that the HTML element is the whole page
and so is effectively displayed) so neither need necessarily implement
the same type of style object as those on elements in the BODY. Thus a
feature test applied to either of those may not produce results
consistent with the same test applied to an element in the BODY.
No actual instances of this being an issue have been observed, it is
just another obvious assumption that is inherent in the strategy of
feature testing to decide whether or not to write out a STYLE element.
Still, while not an ideal 'feature detection' test it is still far
superior to the 'object inference' test you have previously proposed.
The assumptions in that test are demonstrably false, rather than just
being theoretically questionable.
Feature testing for modifications in presentation resulting form
assigning to the - display - property are facilitated where the
environment provides dimension and offset information. If an element is
flowed under the influence of a displayed element and that element is
assigned - display:none; - then the position of the first element will
change as it re-flows. So that change in position can be detected
following the browser's re-drawing of the DOM, and so the dynamic nature
of the display property verified.
Obviously a test on an element in the laid-out document cannot be used
to inform behaviour inside the HEAD element before the opening BODY tag
has even been seen by the browser.
Of course these are a lot of hoops to be jumping through, and so it is
generally considered that a design where the default state of anything
that is to be hidden is visible, where the first action of the script is
to hide it, and then the interaction comes into play to reveal and
re-hide it as needed, is the optimum choice for reliable outcomes. The
symmetry of the script first having to hide the element before it can
reveal it means that whenever the environment is not dynamic enough to
support the desired manipulation the default (visible) state will not be
moved away from, and the result will be either viable by default or
effectively dynamic.
The feature testing is then reduced to; is there a recognised element
retrieval mechanism available for the type of element I am interested
in, if so; when used does it return an object (presumably an element),
if so; does that object have a style property that has trueness (is not
undefined or null). If those tests are passed you can assign to the
element's style object's - display - property as often as you want
without errors, and if the initial hiding of it works you have a dynamic
system, and otherwise it is harmless.
> and virtually any Web application will break under
> the described circumstances.
No, many will, others will not. But we are not dealing with a web
application, we are dealing with a simple web page with a little
scripted gimmickry going on.
> Is it just the display property or do all attempts to
> manipulate style with script fail?
Opera 6 supports about 8 dynamic style properties (including -
visibility -) but will not re-flow its presentation of the DOM (only
absolutely positioned elements may be move once the page has been
drawn). Its style object only has about a dozen exposed properties, but
they include some IE compatibility properties such as - pixelTop - that
are effectively just alternatives for standard properties (- top - in
that case).
Richard.
David Mark
wrote:
> David Mark wrote:
> > On Jul 22, 9:13 pm, Richard Cornford wrote:
> >> David Mark wrote:
> <snip>
> >>> Except your CSS is invalid!
>
> >> That is very questionable. The CSS specs mandate the
> >> handling of unrecognised property names and values
> >> (they are to be ignored in all cases, which IE fails
> >> to do) and so the question arises as to why it is
> >> necessary to mandate the handling of unrecognised
> >> properties and values if a notion of validity is
> >> attached that precludes their appearing in the first
> >> place.
>
> > According to the w3c validator and the error consoles of
> > various browsers, it is invalid.
>
> Not unless you can establish that the concept of validity attaches to
> the use of unrecognised property names or value. If the concept
> attaches then why does the specification mandate the handling of
> unrecognised property names and values, as they would be precluded in
> any 'valid' source? The behaviour of w3c 'validator' is not, in itself,
> sufficient to indicate that the concept of validity can be applied here.
Okay. But it is what I go by. If it won't validate there, I don't
use it.
[snip]
>
> The last brand new mobile phone I encounter that shipped with Opera 6.12
> installed was around the new year, so given the turnover of mobile
> phones may 'we' can forget about it now.
That's good.
>
> > but what other browsers (embedded or otherwise) display
> > this behavior?
>
> Pretty much all of the ones with non-dynamic DOMs. NetFont 4 ,for
> example.
And I think it is NetFront. Regardless, what is that one used for?
>
> > It doesn't sound like anything that can be feature-detected
>
> It sounded problematic to detect, but it has been observed that all the
> instances of browsers actually identified that did not react to dynamic
> assignments to a - display - property either did not have a - style -
> object on their elements, or (much more commonly) did not have a -
> display - property on their style objects. So the proposed test was to
> see if an element had both a style object and that that style object had
> a 'string' type - display - property. Without both it was pretty
> guaranteed that assigning to the display property of the style object
> was not going to work in the given environment. Unfortunately that still
> falls down as feature detecting because it assumes that if those two
> properties do exist then assigning to the - display - property will
> result in browser modifying its presentation.
Sounds like a decent test.
>
> There is also the problem of getting at an element to test when you want
> to apply the test in the context of making decisions about writing out
> STYLE elements. You want to (must) write the STYLE element in the HEAD
Well, only in this simplistic example. You could wait until the body
is loading and then insert the style element into the DOM once you
check if the body's display style is a string.
> but the only two elements guaranteed to be available at that point are
> the HTML and HEAD elements, neither of which are ever displayed as such
> (though you might easily argue that the HTML element is the whole page
> and so is effectively displayed) so neither need necessarily implement
> the same type of style object as those on elements in the BODY.
I think it is likely that they do, regardless of how illogical it is.
Thus a
> feature test applied to either of those may not produce results
> consistent with the same test applied to an element in the BODY.
Right.
>
> No actual instances of this being an issue have been observed, it is
Of what issue? The possibility of the head and body having different
types of style properties?
> just another obvious assumption that is inherent in the strategy of
> feature testing to decide whether or not to write out a STYLE element.
> Still, while not an ideal 'feature detection' test it is still far
> superior to the 'object inference' test you have previously proposed.
I insist I am not using an "object inference." It looks like I am,
but actually the test to write the style sheet is just a bookend for
the test used to run the script that will ultimately show the hidden
elements. I know that gEBI doesn't indicate anything about whether
style properties can be maniupulated.
> The assumptions in that test are demonstrably false, rather than just
> being theoretically questionable.
The aggregate result of the two tests has been shown not to work in
Opera 6 and perhaps some older mobile phones. As we have been over,
this example will never be perfect. Personally, I wouldn't hide the
answers in a FAQ at all. The whole thing is silly, but that is what
the OP wanted to do.
>
> Feature testing for modifications in presentation resulting form
> assigning to the - display - property are facilitated where the
> environment provides dimension and offset information. If an element is
> flowed under the influence of a displayed element and that element is
> assigned - display:none; - then the position of the first element will
> change as it re-flows. So that change in position can be
Yes. I had to do lots of similar things to make positioning work to
the pixel across the various major browsers without resorting to
browser sniffing.
detected
> following the browser's re-drawing of the DOM, and so the dynamic nature
> of the display property verified.
I actually thought about discussing such a test earlier in the thread,
but it seems beyond the scope of this dynamic FAQ example. Also, you
couldn't use document.write for the style, so the whole example would
have to changed to use the DOM. I'm done writing FAQ answer hiding
code at this point.
>
> Obviously a test on an element in the laid-out document cannot be used
> to inform behaviour inside the HEAD element before the opening BODY tag
> has even been seen by the browser.
Right.
>
> Of course these are a lot of hoops to be jumping through, and so it is
> generally considered that a design where the default state of anything
> that is to be hidden is visible, where the first action of the script is
> to hide it, and then the interaction comes into play to reveal and
> re-hide it as needed, is the optimum choice for reliable outcomes. The
> symmetry of the script first having to hide the element before it can
> reveal it means that whenever the environment is not dynamic enough to
> support the desired manipulation the default (visible) state will not be
> moved away from, and the result will be either viable by default or
> effectively dynamic.
I realize all of that, but if the FAQ is going to hide all of its
answers, it doesn't look very good to have them flash at the outset.
I know how to get around this, but again, I think that the solution is
beyond the scope of this simple example. In short, you would want to
avoid using onload to hide the elements, so you would have to use
DOMContentReady if available and simulate it for IE.
>
> The feature testing is then reduced to; is there a recognised element
> retrieval mechanism available for the type of element I am interested
> in, if so; when used does it return an object (presumably an element),
> if so; does that object have a style property that has trueness (is not
> undefined or null). If those tests are passed you can assign to
I don't see what you mean by "trueness." I think checking for a
string type is what we are after. Typically it will be an empty
string, which converts to boolean false.
the
> element's style object's - display - property as often as you want
> without errors, and if the initial hiding of it works you have a dynamic
> system, and otherwise it is harmless.
>
> > and virtually any Web application will break under
> > the described circumstances.
>
> No, many will, others will not. But we are not dealing with a web
> application, we are dealing with a simple web page with a little
> scripted gimmickry going on.
I realize that. What I meant was that there are a lot of applications
out there that hide elements initially. Virtually anything that uses
popup menus falls into this category. So all of these pages are
susceptible to this weird Opera 6/NetFront bug. I am not particularly
concerned about it as I rarely write apps that hide elements
initially, but many do and there would seem to be no simple recourse.
The next time I need to write a page with popup menus, I will use the
DOM to insert the style element, but that won't fix the millions of
pages that use document.write to do this. Many of them don't even
take that precaution, they just make the hide style static, as seen in
a recent menu question posted here.
>
> > Is it just the display property or do all attempts to
> > manipulate style with script fail?
>
> Opera 6 supports about 8 dynamic style properties (including -
> visibility -) but will not re-flow its presentation of the DOM (only
> absolutely positioned elements may be move once the page has been
> drawn). Its style object only has about a dozen exposed
properties, but
> they include some IE compatibility properties such as - pixelTop - that
> are effectively just alternatives for standard properties (- top - in
> that case).
Interesting as my next question would be whether position and
visibility are on that list. It sounds like they are not as modifying
the position style would require a document re-flow. It is a good
thing that Opera 6 is now virtually extinct. How widespread is this
NetFront thing and are there others that behave like this?
Richard Cornford
> On Jul 29, 12:28 pm, Richard Cornford wrote:
>> David Mark wrote:
<snip>
>>> various browsers, it is invalid.
>>
>> Not unless you can establish that the concept of validity
>> attaches to the use of unrecognised property names or value.
>> If the concept attaches then why does the specification mandate
>> the handling of unrecognised property names and values, as they
>> would be precluded in any 'valid' source? The behaviour of w3c
>> 'validator' is not, in itself, sufficient to indicate that the
>> concept of validity can be applied here.
>
> Okay. But it is what I go by. If it won't validate there,
> I don't use it.
Maybe you don't, but a pragmatic approach might say that if you want
consistent behaviour on IE versions <= 5 (as 6+ is fine with 'pointer')
then the fact that standard CSS implementations are required to handle
the unrecognised property value in a particular way give you an
inexpensive means of achieving that consistency without breaking
anything.
> [snip]
>> The last brand new mobile phone I encounter that shipped with
>> Opera 6.12 installed was around the new year, so given the
>> turnover of mobile phones may 'we' can forget about it now.
>
> That's good.
Bear in mind the reason that Opera 6 was still being embedded in mobile
phones as recently as the start of this year (and may well still be). It
is because it is very small. Operas 7-9 are also very small in
comparisons to leviathans like Mozilla, but not as small Opera 6.
The devices into which browsers are embedded are becoming more capable
and have more resources available to them, so the need for very small
browsers diminishes, but at the same time browsers are starting to be
embedded into even smaller devices. I have seen proposals to embed
browsers into watches. I am not sure how that is going to work out (how
useable they could ever be), but that trend may suggest that there may
be an ongoing demand for small-footprint, well tried and reliable web
browsers, and so Opera 6 may be with us in one form or another for a
little while to come.
>>> but what other browsers (embedded or otherwise) display
>>> this behavior?
>>
>> Pretty much all of the ones with non-dynamic DOMs. NetFont 4
>> ,for example.
>
> And I think it is NetFront.
It is.
> Regardless, what is that one used for?
PDAs and mobile phones
>>> It doesn't sound like anything that can be feature-detected
>>
>> It sounded problematic to detect, but it has been observed that
>> all the instances of browsers actually identified that did not
>> react to dynamic assignments to a - display - property either
>> did not have a - style - object on their elements, or (much more
>> commonly) did not have a - display - property on their style
>> objects. So the proposed test was to see if an element had both
>> a style object and that that style object had a 'string' type
>> - display - property. Without both it was pretty guaranteed
>> that assigning to the display property of the style object
>> was not going to work in the given environment. Unfortunately
>> that still falls down as feature detecting because it assumes
>> that if those two properties do exist then assigning to the
>> - display - property will result in browser modifying its
>> presentation.
>
> Sounds like a decent test.
It is the making of assumptions that undermines the effectiveness of
feature testing. this strategy is not assumption-free.
>> There is also the problem of getting at an element to test
>> when you want to apply the test in the context of making
>> decisions about writing out STYLE elements. You want to
>> (must) write the STYLE element in the HEAD
>
> Well, only in this simplistic example. You could wait until
> the body is loading and then insert the style element into
> the DOM once you check if the body's display style is a string.
You could, but if the test were applied to the elements that were to be
hidden (as the probably should be) it would be easier to just set
their - display - properties directly on the element's style object and
forget about adding style elements.
>> but the only two elements guaranteed to be available at that
>> point are the HTML and HEAD elements, neither of which are ever
>> displayed as such (though you might easily argue that the HTML
>> element is the whole page and so is effectively displayed) so
>> neither need necessarily implement the same type of style object
>> as those on elements in the BODY.
>
> I think it is likely that they do, regardless of how illogical
> it is.
It is not a question of the testing being illogical, it is not. Given
that the majority of browsers are written in C++ (or another class-based
OO language) the odds of the element objects all possessing exactly the
same type of style object are extremely high (it would almost be
irrational to do anything else). The issue is with the principles of
feature detection, where the ideal test has a one-to-one relationship
with whatever it is that needs to be known form the test. Testing the
style object of the HEAD or HTML element in order to make decisions
about how to treat elements within the body is more testing a parallel
relationship. That is still much better than an object inference test,
and most parallel relationships do hold in reality, but it is not ideal.
>> Thus a feature test applied to either of those may not produce
>> results consistent with the same test applied to an element
>> in the BODY.
>
> Right.
>
>> No actual instances of this being an issue have been observed, it is
>
> Of what issue?
The issue of the possibility that non-displayable elements would have
different - style - object implementations to displayable elements.
Nobody has been able to point to a single environment where they do, but
as nobody can be familiar with the DOMs of all scriptable browsers that
does not indicate that there is no issue.
> The possibility of the head and body having different
> types of style properties?
Yes.
>> just another obvious assumption that is inherent in the
>> strategy of feature testing to decide whether or not to
>> write out a STYLE element. Still, while not an ideal
>> 'feature detection' test it is still far superior to
>> the 'object inference' test you have previously proposed.
>
> I insist I am not using an "object inference."
Insist away, it won't change anything.
> It looks like I am,
Maybe for a very good reason.
> but actually the test to write the style sheet is just a
> bookend for the test used to run the script that will
> ultimately show the hidden elements.
That is the inference. You are inferring that the existence of the -
getElementById - method of the document implies the ability to override
a STYLE element applied CSS rule by assigning to the - display -
property of an element's - style - object. If you are wrong in that
inference your script will act to render the content hidden by the STYLE
element you write completely inaccessible. That is the worst possible
outcome of a scripted action, and the reason why a much better test, or
alternative strategy, would be appropriate.
> I know that gEBI doesn't indicate anything about whether
> style properties can be maniupulated.
No it doesn't, but the decision to write the style element needs to
relate to the ability to dynamically manipulate the style properties,
because once written it cannot be unwritten (at least in any environment
where the styles could not be dynamically manipulated).
>> The assumptions in that test are demonstrably false, rather
>> than just being theoretically questionable.
>
> The aggregate result of the two tests has been shown not to
> work in Opera 6 and perhaps some older mobile phones.
Not to work in browsers that do not provide a dynamic DOM.
> As we have been over, this example will never be perfect.
Maybe not, but a script that may acts to render content inaccessible is
suffering from a fundamentally flawed design.
> Personally, I wouldn't hide the answers in a FAQ at all.
> The whole thing is silly, but that is what
> the OP wanted to do.
It strikes me as a silly gimmick, but it doesn't need to be a silly
gimmick that will act to interfere with the reliability of the
underlying HTML.
>> Feature testing for modifications in presentation resulting
>> form assigning to the - display - property are facilitated
>> where the environment provides dimension and offset
>> information. If an element is flowed under the influence of
>> a displayed element and that element is assigned
>> - display:none; - then the position of the first element will
>> change as it re-flows. So that change in position can be
>
> Yes. I had to do lots of similar things to make positioning
> work to the pixel across the various major browsers without
> resorting to browser sniffing.
>
>> detected following the browser's re-drawing of the DOM, and
>> so the dynamic nature of the display property verified.
>
> I actually thought about discussing such a test earlier in
> the thread, but it seems beyond the scope of this dynamic
> FAQ example.
Don't let the Subject headers of threads (or the subjects of the OPs)
fool you into limiting the scope of any discussion. The only criterion
for on or off topic is the topic of the entire group
(javascript/ECMAScript). Threads are supposed to wander wherever the
discussion takes them (one of the reasons branching threading is such an
integral part of Usenet, as such discussions don't really make sense in
a chronological/linear presentation).
> Also, you couldn't use document.write for the style,
That is pretty much the crux of criticism of the strategy.
> so the whole example would
> have to changed to use the DOM.
Not if there was no STYLE element involved, and there dos not have to
be.
<snip>
>> Of course these are a lot of hoops to be jumping through,
>> and so it is generally considered that a design where the
>> default state of anything that is to be hidden is visible,
>> where the first action of the script is to hide it, and
>> then the interaction comes into play to reveal and re-hide
>> it as needed, is the optimum choice for reliable outcomes.
>> The symmetry of the script first having to hide the element
>> before it can reveal it means that whenever the environment
>> is not dynamic enough to support the desired manipulation
>> the default (visible) state will not be moved away from,
>> and the result will be either viable by default or
>> effectively dynamic.
>
> I realize all of that, but if the FAQ is going to hide all
> of its answers, it doesn't look very good to have them
> flash at the outset.
They could only flash on browsers that do progressive rendering as the
page loads (which is a long way from being all browsers). It is a
possible minor display glitch, so probably not something that you would
want to sacrifice the viability of the end result to.
> I know how to get around this, but again, I think that the
> solution is beyond the scope of this simple example. In short,
> you would want to avoid using onload to hide the elements, so
> you would have to use DOMContentReady if available and simulate
> it for IE.
>
>> The feature testing is then reduced to; is there a recognised
>> element retrieval mechanism available for the type of element
>> I am interested in, if so; when used does it return an object
>> (presumably an element), if so; does that object have a style
>> property that has trueness (is not undefined or null). If those
>> tests are passed you can assign to
>
> I don't see what you mean by "trueness."
In javascript 'trueness' is attributed to any value that would result in
boolean true if the type-convert-to-boolean rules were applied to it (or
is boolean true to start with). That is, a value that is not necessarily
boolean true itself but will act as boolean true in any context that
implies the type conversion.
> I think checking for a string type is what we are after.
The subject of my 'trueness' requirement was the value of the - style -
property of element. That is all that is necessary in the strategy
outlined above because without trueness - el.style.display =
'whatver'; - will error-out, while with trueness it cannot. Because the
strategy first hides the element before attempting to reveal them it no
longer matters whether the assignment itself is effective as its
possible ineffectiveness will not move the page away from a viable
state, while the code actually erroring-out remains something to be
avoided.
> Typically it will be an empty
> string, which converts to boolean false.
The - display - property of the style object, not the element's -
style - property.
>> the element's style object's - display - property as often
>> as you want without errors, and if the initial hiding of it
>> works you have a dynamic system, and otherwise it is harmless.
>>
>>> and virtually any Web application will break under
>>> the described circumstances.
>>
>> No, many will, others will not. But we are not dealing with a web
>> application, we are dealing with a simple web page with a little
>> scripted gimmickry going on.
>
> I realize that. What I meant was that there are a lot of
> applications out there that hide elements initially.
There is a world of difference between a web application and a web site.
> Virtually anything that uses
> popup menus falls into this category.
Most actual instances of popup menus do not appear in contexts that
should ever be considered web applicaitons.
> So all of these pages are susceptible to this weird
> Opera 6/NetFront bug.
It is not a bug. The display in User Agents is not mandated to be
updated, re-flowed, or re-drawn in response to modifications in the DOM
presented to scripts.
> I am not particularly concerned about it as I rarely write
> apps that hide elements initially, but many do and there
> would seem to be no simple recourse.
It is the people writing web sites and e-commerce sites that need to be
worrying about how there script design strategies impact on viability of
their creations. For web applications the design criteria can be very
different.
> The next time I need to write a page with popup menus,
> I will use the DOM to insert the style element,
If you insist upon using a STYLE element at all.
> but that won't fix the millions of
> pages that use document.write to do this.
Nothing will fix the millions of pages where unconsidered/uninformed
script design decisions have fatally undermined the fundamental
viability of the underlying HTML. That is not really an excuse for
promoting the creation of more of them.
> Many of them don't even take that precaution, they just
> make the hide style static, as seen in a recent menu
> question posted here.
Yep, no matter how badly anything may be seen to be done there is almost
always potential for doing it worse.
>>> Is it just the display property or do all attempts to
>>> manipulate style with script fail?
>>
>> Opera 6 supports about 8 dynamic style properties (including -
>> visibility -) but will not re-flow its presentation of the DOM
>> (only absolutely positioned elements may be move once the page
>> has been drawn). Its style object only has about a dozen exposed
>> properties, but they include some IE compatibility properties
>> such as - pixelTop - that are effectively just alternatives for
>> standard properties (- top - in that case).
>
> Interesting as my next question would be whether position and
> visibility are on that list.
I explicitly stated that - visibility - is in the list. The - position -
property is not, as switching that would require/imply a re-flowing of
the document. But the - position - property was not dynamically
assignable on IE 4, even though it had that property exposed on the
style object.
> It sounds like they are not as modifying
> the position style would require a document re-flow.
It would.
> It is a good thing that Opera 6 is now virtually extinct.
If it is.
> How widespread is this NetFront thing and are there others
> that behave like this?
It is hard to say as it would invariable be listed in browser statistics
as IE. It has been (or seems to have been, as it is not easy to tell for
sure) the browser embedded on about 60% of the new small devices that I
have had a chance to look at over the last year, though the last version
I had a chance to fully test was 4 and there seem be at least some
improvements in the latest versions.
Richard.
David Mark
wrote:
> David Mark wrote:
> > On Jul 29, 12:28 pm, Richard Cornford wrote:
> >> David Mark wrote:
> <snip>
> >>> According to the w3c validator and the error consoles of
> >>> various browsers, it is invalid.
>
> >> Not unless you can establish that the concept of validity
> >> attaches to the use of unrecognised property names or value.
> >> If the concept attaches then why does the specification mandate
> >> the handling of unrecognised property names and values, as they
> >> would be precluded in any 'valid' source? The behaviour of w3c
> >> 'validator' is not, in itself, sufficient to indicate that the
> >> concept of validity can be applied here.
>
> > Okay. But it is what I go by. If it won't validate there,
> > I don't use it.
>
> Maybe you don't, but a pragmatic approach might say that if you want
> consistent behaviour on IE versions <= 5 (as 6+ is fine with 'pointer')
> then the fact that standard CSS implementations are required to handle
> the unrecognised property value in a particular way give you an
> inexpensive means of achieving that consistency without breaking
> anything.
What's wrong with using IE conditional comments to handle this?
>
> > [snip]
> >> The last brand new mobile phone I encounter that shipped with
> >> Opera 6.12 installed was around the new year, so given the
> >> turnover of mobile phones may 'we' can forget about it now.
>
> > That's good.
>
> Bear in mind the reason that Opera 6 was still being embedded in mobile
> phones as recently as the start of this year (and may well still be). It
I suddenly realized that none of my apps are affected by this
problem. I don't write inline style blocks, I write (or append) link
elements and the only ones that hide anything for scripts are screen-
only. Embedded Opera uses the handheld style sheet and my handheld
styles don't hide anything of this sort (eg popup menus.) Does
NetFront also support handheld styles?
> is because it is very small. Operas 7-9 are also very small in
> comparisons to leviathans like Mozilla, but not as small Opera 6.
Right.
>
> The devices into which browsers are embedded are becoming more capable
> and have more resources available to them, so the need for very small
> browsers diminishes, but at the same time browsers are starting to be
> embedded into even smaller devices. I have seen proposals to embed
> browsers into watches. I am not sure how
That sounds crazy to me, but then I don't much care for Web browsing
with my phone either.
that is going to work out (how
> useable they could ever be), but that trend may suggest that there may
> be an ongoing demand for small-footprint, well tried and reliable web
> browsers, and so Opera 6 may be with us in one form or another for a
> little while to come.
Then I'm even more pleased about the above epiphany.
>
> >>> but what other browsers (embedded or otherwise) display
> >>> this behavior?
>
> >> Pretty much all of the ones with non-dynamic DOMs. NetFont 4
> >> ,for example.
>
> > And I think it is NetFront.
>
> It is.
>
> > Regardless, what is that one used for?
>
> PDAs and mobile phones
Which should support handheld styles, but I know some don't (hopefully
not the same ones that have the problematic display behavior.)
[snip]
> You could, but if the test were applied to the elements that were to be
> hidden (as the probably should be) it would be easier to just set
> their - display - properties directly on the element's style object and
> forget about adding style elements.
Easier yes, but still there is the issue of hidden content flash
during load.
>
> >> but the only two elements guaranteed to be available at that
> >> point are the HTML and HEAD elements, neither of which are ever
> >> displayed as such (though you might easily argue that the HTML
> >> element is the whole page and so is effectively displayed) so
> >> neither need necessarily implement the same type of style object
> >> as those on elements in the BODY.
>
> > I think it is likely that they do, regardless of how illogical
> > it is.
>
> It is not a question of the testing being illogical, it is not. Given
> that the majority of browsers are written in C++ (or another class-based
> OO language) the odds of the element objects all possessing exactly the
> same type of style object are extremely high
Right.
(it would almost be
> irrational to do anything else). The issue is with the principles of
> feature detection, where the ideal test has a one-to-one relationship
> with whatever it is that needs to be known form the test. Testing the
> style object of the HEAD or HTML element in order to make decisions
> about how to treat elements within the body is more testing a parallel
> relationship. That is still much better than
Right.
[snip]
> >> just another obvious assumption that is inherent in the
> >> strategy of feature testing to decide whether or not to
> >> write out a STYLE element. Still, while not an ideal
> >> 'feature detection' test it is still far superior to
> >> the 'object inference' test you have previously proposed.
>
> > I insist I am not using an "object inference."
>
> Insist away, it won't change anything.
>
> > It looks like I am,
>
> Maybe for a very good reason.
>
> > but actually the test to write the style sheet is just a
> > bookend for the test used to run the script that will
> > ultimately show the hidden elements.
>
> That is the inference. You are inferring that the existence of the -
> getElementById - method of the document implies the ability to override
> a STYLE element applied CSS rule by assigning to the - display -
Not exactly. I am writing the style sheet to hide the elements only
if I am going to run the script to show the elements. The other issue
has nothing to do with my logic (which is why it remains an issue.)
[snip]
I threw this together to demonstrate how my original example will work
in Opera 6 and NetFront with only one minor modification.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>FAQ</title>
<script type="text/javascript">
function showAnswer() {
var id = this.id;
var el = document.getElementById('a' + id.substring(1));
if (el && el.style) el.style.display = (el.style.display ==
'block')?'none':'block'
}
if (document.getElementById && document.getElementsByTagName) {
document.write('<link href="hideanswers.css" rel="stylesheet"
type="text/css" media="screen">');
window.onload = function() {
var el = document.getElementById('questions');
if (el) {
var links = el.getElementsByTagName('a');
for (var i = links.length - 1; i >= 0; i--) {
links[i].onclick = showAnswer;
links[i].href = '#a' + (i + 1);
links[i].tabIndex = 0
}
}
}
}
</script>
</head>
<body>
<dl id="questions">
<dt><a id="q1">Q. Why am I here?</a></dt>
<dd id="a1">A. I don't know what to tell you.</dd>
<dt><a id="q2">Q. Why are you here?</a></dt>
<dd id="a2">A. Don't you know?</dd>
</dl>
</body>
</html>
And the hideanswers.css has just one rule in this case:
#questions dd {display:none}
So now handheld devices that support handheld style sheets are
unaffected by this gap in DOM support. Other than Opera 6 on the
desktop (extinct), what else is out there that could break this?
Randy Webb
> David Mark wrote:
>> On Jul 29, 12:28 pm, Richard Cornford wrote:
>>> David Mark wrote:
> <snip>
<snip>
>>>> but what other browsers (embedded or otherwise) display
>>>> this behavior?
>>>
>>> Pretty much all of the ones with non-dynamic DOMs. NetFont 4
>>> ,for example.
>>
>> And I think it is NetFront.
>
> It is.
>
>> Regardless, what is that one used for?
>
> PDAs and mobile phones
Richard, how do, or can, you identify NetFront? I have a cell phone with
a browser that has no splash/startup screen, the Manufacturer
can't/won't tell me what browser it is, and the UA string is identical
to my IE7 UA string with the exception of the .NET parts of it.
David Mark
In addition, adding this test should wrap up everything else,
including Opera 6 (provided our assumption about style object
intefaces is correct.)
if (document.getElementById && document.getElementsByTagName) {
var h = document.getElementsByTagName('html');
if (h.length && h[0].style && typeof(h[0].style.display) == 'string')
Randy Webb
> On Jul 29, 8:04 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> In addition, adding this test should wrap up everything else,
> including Opera 6 (provided our assumption about style object
> intefaces is correct.)
>
> if (document.getElementById && document.getElementsByTagName) {
> var h = document.getElementsByTagName('html');
> if (h.length && h[0].style && typeof(h[0].style.display) == 'string')
> {
> document.write('<link href="hideanswers.css" rel="stylesheet"
> type="text/css" media="screen">');
It still doesn't ensure that the browser can dynamically hide/show an
element. Whether due to lack of support or a bug in a browser. The only
way to know - for sure - that script can hide/show an element is to have
it visible to begin with and then hide it with script. And that is the
concept that I have tried - in vain - to get across to you. The mere
fact that the browser supports what you are testing for (which is far
from what you claimed as "adequate") still doesn't mean it can hide the
element via script.
Since you changed your test, does that mean you agree with my original
assessment that a test for gEBI was inadequate to know whether to write
the style element or not?
David Mark
[snip]
> It still doesn't ensure that the browser can dynamically hide/show an
> element. Whether due to lack of support or a bug in a browser. The only
Nobody said it did. Go back and re-read the last half dozen
messages. It is a good indicator that, according to Richard, for all
known cases.
> way to know - for sure - that script can hide/show an element is to have
> it visible to begin with and then hide it with script. And that is the
We've been over this. Obviously I am not going to adopt that
approach. But I did make it work for your cell phone didn't I? And
Opera 6, NetFront, etc. What's left?
[snip]
>
> Since you changed your test, does that mean you agree with my original
> assessment that a test for gEBI was inadequate to know whether to write
> the style element or not?
>
Not really. I still say nothing supports one and not the other. I
never said it was wrong, just over-cautious. I left its addition as
an exercise and ended up doing it myself with this revision.
Looks pretty bullet-proof now. I can see no real world benefit in
using your method, but I do see a detriment. It will add the prospect
of content flash and document re-flow during page load, which is quite
unpleasant.
And if you want anybody to take your suggestions seriously, you need
to adjust your attitude.
Randy Webb
> On Jul 29, 9:31 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> [snip]
>> It still doesn't ensure that the browser can dynamically hide/show an
>> element. Whether due to lack of support or a bug in a browser. The only
>
> Nobody said it did. Go back and re-read the last half dozen
> messages. It is a good indicator that, according to Richard, for all
> known cases.
Richard also said, and I quote:
<quote>
Unfortunately that still falls down as feature detecting because it
assumes that if those two properties do exist then assigning to the -
display - property will result in browser modifying its presentation.
</quote>
Which is precisely what I have been trying to explain in most of my
posts in this thread with regards to your testing to see whether to
write the style element or not. And in the end, it is still what I have
been saying - "The *only* way to know for sure is to make the elements
hidden via script." Any other approach is vulnerable to failure.
The hiding via script introduces the aspect of the flickering (which I
noticed only in Opera 9 when originally testing but making the page
longer introduces it into FF and IE as well).
You are left with a choice then:
1) The flickering for total degradation.
2) The possibility of a script error making the page un-usable to some.
>> way to know - for sure - that script can hide/show an element is to have
>> it visible to begin with and then hide it with script. And that is the
>
> We've been over this. Obviously I am not going to adopt that
> approach.
I didn't say you had to. I am simply telling you there is a potentially
fatal flaw in the approach.
> But I did make it work for your cell phone didn't I?
I will test it tomorrow, but as it is written, it appears it should work
there.
> And Opera 6, NetFront, etc. What's left?
> [snip]
>
>> Since you changed your test, does that mean you agree with my original
>> assessment that a test for gEBI was inadequate to know whether to write
>> the style element or not?
>>
>
> Not really. I still say nothing supports one and not the other.
And I promptly told of you a browser that supports one and not the
other. I simply can't name it because I honestly don't know the "Name"
of it.
> I never said it was wrong, just over-cautious. I left its addition as
> an exercise and ended up doing it myself with this revision.
Do you honestly think that someone that asked how to do this could
*possibly* know how to make it better without even being able to write
the original?
> Looks pretty bullet-proof now.
Nothing is "bullet-proof" on the Web. I can see at least five places
that the code can still fail but it is all irrelevant as you will simply
reply with the - so far standard - defense of "I don't know of anywhere
it won't work so it must work everywhere".
> I can see no real world benefit in using your method, but I do see a detriment.
I didn't expect you to.
> It will add the prospect of content flash and document re-flow during
> page load, which is quite unpleasant.
That I agree with.
> And if you want anybody to take your suggestions seriously, you need
> to adjust your attitude.
That is a joke, right?
David Mark
> Nothing is "bullet-proof" on the Web. I can see at least five places
> that the code can still fail but it is all irrelevant as you will simply
Utter nonsense. That would be rougly every other line. If your HTML
has the wrong ID syntax for questions (or no ID), that could cause a
problem, but that would hardly be the fault of the code. Sure, you
could test for that before slicing up the id to make it friendlier to
coders. I wasn't publishing an API with this example.
I guess if you run out of disk space on your PC while running the
script, that could cause unexpected results. Same for a connection
failure during the download, a power outage, etc.
Richard Cornford
> On Jul 29, 7:20 pm, Richard Cornford wrote:
>> David Mark wrote:
<snip>
>>> I don't use it.
>>
>> Maybe you don't, but a pragmatic approach might say that if
>> you want consistent behaviour on IE versions <= 5 (as 6+ is
>> fine with 'pointer') then the fact that standard CSS
>> implementations are required to handle the unrecognised
>> property value in a particular way give you an inexpensive
>> means of achieving that consistency without breaking
>> anything.
>
> What's wrong with using IE conditional comments to handle this?
Probably nothing in this context.
<snip>
> I suddenly realized that none of my apps are affected by
> this problem. I don't write inline style blocks, I write
> (or append) link elements and the only ones that hide
> anything for scripts are screen- only. Embedded Opera uses
> the handheld style sheet and my handheld styles don't hide
> anything of this sort (eg popup menus.) Does NetFront also
> support handheld styles?
Is a PDA with a 600x800, 24 bit color display going to use a 'handheld'
style sheet just because it can be held in the hand. And without being
presented with any actual handheld style sheet might a mobile phone not
decide to use a screen media style sheet as its second choice?
Looking at the handheld style sheet definitions they seem to be aimed at
monochrome, and text matrix displays in addition to small screens. While
actual mobile phone and PDA browsers are full-color, pixel graphic
displays and they usually have quite good (visual) CSS support.
<snip>
>> ... so Opera 6 may be with us in one form or another for a
>> little while to come.
>
> Then I'm even more pleased about the above epiphany.
<snip>
>>> Regardless, what is that one used for?
>>
>> PDAs and mobile phones
>
> Which should support handheld styles, but I know some don't
> (hopefully not the same ones that have the problematic
> display behavior.)
>
> [snip]
>
>> You could, but if the test were applied to the elements that
>> were to be hidden (as the probably should be) it would be
>> easier to just set their - display - properties directly
>> on the element's style object and forget about adding style
>> elements.
>
> Easier yes, but still there is the issue of hidden content flash
> during load.
>
<snip>
>> That is the inference. You are inferring that the existence
>> of the - getElementById - method of the document implies the
>> ability to override a STYLE element applied CSS rule by
>> assigning to the - display -
>
> Not exactly. I am writing the style sheet to hide the elements
> only if I am going to run the script to show the elements. The
> other issue has nothing to do with my logic (which is why it
> remains an issue.)
Are you saying that this instance is not object inference because you
personally were not making the inference that what you were doing as a
result of the test was an approvers thing to be doing as a result of the
test?
Assuming that your theory about the handling of the media rule is
correct and a browser on a mobile phone will disregard a screen style
sheet (even though your are not explicitly presenting it with a handheld
style sheet to use it its place), what have you now done on browsers
embedded in (or just installed on) mobile phones that are capable of the
dynamic display manipulation. They pass your tests and the LINK element
is written out. Because of the media specified they ignore it, but still
go on to initialise the script that will switch the display value. The
elements then start off visible, and disappears on the user's first
click (as the display property switches from the empty string to
'none'), and then reappears on the user's next click, toggling form then
on. That sounds like a very unintuitive (indeed rather bizarre) user
interface design.
Richard.
Richard Cornford
> Richard Cornford said the following on 7/29/2007 7:20 PM:
>> David Mark wrote:
>>> And I think it is NetFront.
>>
>> It is.
>>
>>> Regardless, what is that one used for?
>>
>> PDAs and mobile phones
>
> Richard, how do, or can, you identify NetFront?
If the documentation won't tell me (and often it won't) I run a cut-down
version of my DOM scanning script on it and pock around to see if the
Brower has the characteristics of NetFront versions that are documented.
> I have a cell phone with a browser that has no splash/startup
> screen, the Manufacturer can't/won't tell me what browser it is,
E-mail me with a usable reply address and I will see what can be done
about identifying it. (I don't what to do it in public because the
information exposed would end up being used by some fool to make an
object inference script to identify NetFront).
> and the UA string is identical to my IE7 UA string with
> the exception of the .NET parts of it.
And IE 7's UA string only includes .NET if you install .NET.
Richard.
Richard Cornford
<snip>
> ... the inference that what you were doing as a result of the
> test was an approvers thing to be doing as a result of the test?
That was intended to be 'appropriate'.
Richard.
David Mark
wrote:
>
[snip]
> Is a PDA with a 600x800, 24 bit color display going to use a 'handheld'
> style sheet just because it can be held in the hand. And without being
Some do. Some don't. I do know that Opera Mini does as that is what
I use to test handheld styles.
> presented with any actual handheld style sheet might a mobile phone not
> decide to use a screen media style sheet as its second choice?
I always present a handheld style.
>
> Looking at the handheld style sheet definitions they seem to be aimed at
> monochrome, and text matrix displays in addition to small screens. While
Not entirely. I move floated sidebars to display below the content,
show "skip to navigation" links that would otherwise be hidden by the
main (media="all") style sheet, tighten up margins, display popup
menus inline, etc.
> actual mobile phone and PDA browsers are full-color, pixel graphic
> displays and they usually have quite good (visual) CSS support.
Sure, but what works on a large screen is not usually optimal for the
small.
[snip]
>
> Are you saying that this instance is not object inference because you
> personally were not making the inference that what you were doing as a
> result of the test was an approvers thing to be doing as a result of the
> test?
Somewhat. I would describe the previous shortfall, which is not dealt
with as a known gap in the design logic. The design does not infer
that gEBI => dynamic display properties. The only way to make this
clear is with a comment in the code, which I should have included.
[snip]
> Assuming that your theory about the handling of the media rule is
> correct and a browser on a mobile phone will disregard a screen style
> sheet (even though your are not explicitly presenting it with a handheld
> style sheet to use it its place), what have
Okay. I should have noted that a handheld style sheet is a good idea
for use with this example (or any page for that matter.) Regardless,
some PDA's will ignore the handheld rules and use screen rules, but
not Opera 6 and hopefully not netFront.
you now done on browsers
> embedded in (or just installed on) mobile phones that are capable of the
> dynamic display manipulation. They pass your tests and the LINK element
> is written out. Because of the media specified they ignore it, but still
> go on to initialise the script that will switch the display value. The
> elements then start off visible, and disappears on the user's first
> click (as the display property switches from the empty string to
> 'none')
No, in this case, it would be the opposite effect. The first click
would show it (and it is already shown of course) and the next would
hide it. Not good either way.
A better idea than switching the inline display style would be to
switch class names. I changed the style sheet to:
#questions dd {display:none}
#questions dd.shown {display:block}
And changed the line that set the style property to:
if (el) el.className = (el.className == '')?'shown':''
, and then reappears on the user's next click, toggling form then
> on. That sounds like a very unintuitive (indeed rather bizarre) user
> interface design.
It would be indeed. The odd thing is that Opera's handheld simulator
in Opera 9 did not work as you would expect. It wrote the style
sheet, changed the display styles on clicks (just confirmed with an
alert), but did not hide the answers. So there was a small gap in the
revision's logic and my testing was foiled by what would seem to be a
bug in Opera's Small Screen view. I never ran into that one before as
I never hide or show elements when handheld rules are in effect (eg
popup menu activators are hidden and their menus are displayed
inline.) Regardless, that works for me and is perfectly semantic as
the questions are linked to the answers' anchors.
I thought for a moment that Opera 9's Small Screen view was emulating
Opera 6's handheld behavior (with the limited DOM support), but that
can't be the case as the style sheet wouldn't be written (assuming the
test we discussed previously is valid for Opera 6.)
David Mark
[snip]
I suddenly realized that there is an even better solution that does
not write a style tag and does not cause any hidden content to flash
on load.
I also added the test for the correct ID syntax and allowed for
questions to be ordered in any way (they don't have to be sequential
either.) The former test allows for additional links to be included
within the questions element (#dummy in the example.)
The idea for this one came from Richard's suggestion that the
visibility property will work in the odd cases where display will
not. Apparently document re-flow is the problem for the affected
agents. The solution allows for the adoption of the "hikk method"
without the unwanted visual side effects (what I was trying to avoid
all along.)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>FAQ</title>
<script type="text/javascript">
function showAnswer() {
var id = this.id;
if (id && id.length > 1) { // only needed if id is programmatically
changed after the page load
var el = document.getElementById('a' + id.substring(1));
if (el) el.style.display = (el.style.display ==
'none')?'block':'none'
}
}
if (document.getElementById && document.getElementsByTagName) {
var h = document.getElementsByTagName('html');
if (h && h.length && h[0].style && typeof(h[0].style.visibility) ==
'string') { // agent is likely to support visibility updates
document.write('<style type="text/css">#questions
{visibility:hidden}<\/style>');
window.onload = function() {
var el = document.getElementById('questions');
if (el && el.style) {
var links = el.getElementsByTagName('a');
var a, id;
for (var i = links.length - 1; i >= 0; i--)
if (links[i].id) {
var id = links[i].id.match(/^q(\d+)/);
if (id && id.length > 1) {
a = document.getElementById('a' + id[1]);
if (a && a.style && typeof(a.style.display) == 'string') { //
agent is likely to support display updates, but no problem otherwise
links[i].onclick = showAnswer;
links[i].href = '#a' + id[1]; // probably
not needed at this point (could just be '#'.) It is nice that it
always scrolls the full answer into view.
links[i].tabIndex = 0;
a.style.display = 'none'
}
}
}
el.style.visibility = 'visible'
}
}
}
}
</script>
</head>
<body>
<dl id="questions">
<dt><a id="q2">Q. Why am I here?</a></dt>
<dd id="a2">A. I don't know what to tell you.</dd>
<dt><a id="q1">Q. Why are you here?</a></dt>
<dd id="a1">A. <a href="#dummy">Don't you know?</a></dd>
</dl>
</body>
</html>
David Mark
> On Jul 30, 6:33 pm, David Mark <dmark.cins...@gmail.com> wrote:
> [snip]
>
> I suddenly realized that there is an even better solution that does
> not write a style tag and does not cause any
That should read: "a media-specific style tag." And more to the
point, one that uses display:none.
Randy Webb
> On Jul 30, 2:31 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>
>> Nothing is "bullet-proof" on the Web. I can see at least five places
>> that the code can still fail but it is all irrelevant as you will simply
>
> Utter nonsense.
What is "utter nonsense" is your belief that anything on the Web is
"bullet-proof" and your re-write of the code in question is simple proof
of that notwithstanding the fthree I still see that it can fail.
> That would be rougly every other line.
I will narrow it down for you. The re-write has it down to 3 lines. And
those three lines are in the onload function. And bare in mind that this
thread has become more about feature detection than it ever will be
about hiding/showing text.
Note also that I said "can fail" and not "will fail". All three lines
fall into the "what if the UA doesn't support what you are trying to do"
category and is more of a mental exercise than anything else. Although I
can tell you that the browser in my cell phone does not support dynamic
onclicks and tabIndex. It handles them fine if code in the HTML though.
Thomas 'PointedEars' Lahn
> <script type="text/javascript">
> if (document.getElementById) document.write(
Your feature test is flawed at best.
http://pointedears.de/scripts/test/whatami#inference
> '<style type="text/
> css">div.question div {display:none} div.question a
> {cursor:pointer;text-decoration:underline;color:blue}</style>');
^^
1. ETAGOs need to be escaped in HTML script elements, or they end
prematurely:
document.write("...<\/...");
(In XHTML, all ambiguous markup items within real markup
elements have to be escaped, or marked as CDATA, else
it is an XML syntax error.)
2. The above triggers the Netscape Run-Length Bug.
3. The above is not required as the targeted UAs usually also support
scripting style properties on-load the document, and the rules are
not that complex that they cannot be emulated with scripting
style properties.
> [...]
> window.onload = windowLoad;
Needlessly proprietary approach. The (X)HTML body element provides a
standards compliant and well-supported `onload' event handler attribute:
<body onload="windowLoad()">
...
</body>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Thomas 'PointedEars' Lahn
> David Mark wrote:
>> On Jul 22, 9:13 pm, Richard Cornford wrote:
>>> David Mark wrote:
>>>> Except your CSS is invalid!
>>> That is very questionable. The CSS specs mandate the
>>> handling of unrecognised property names and values
>>> (they are to be ignored in all cases, which IE fails
>>> to do) and so the question arises as to why it is
>>> necessary to mandate the handling of unrecognised
>>> properties and values if a notion of validity is
>>> attached that precludes their appearing in the first
>>> place.
>> According to the w3c validator and the error consoles of
>> various browsers, it is invalid.
>
> Not unless you can establish that the concept of validity attaches to
> the use of unrecognised property names or value. If the concept
> attaches then why does the specification mandate the handling of
> unrecognised property names and values, as they would be precluded in
> any 'valid' source? The behaviour of w3c 'validator' is not, in itself,
> sufficient to indicate that the concept of validity can be applied here.
The specification includes that provision so that parsing would not fail
entirely on unknown syntax, properties and property values, which do not
need to be proprietary for that; it is not sanctioning the use of the
former. But that discussion belongs in another newsgroup.
David Mark
wrote:
[snip]
> Your feature test is flawed at best.
We went over all of that.
[snip]
> ^^
> 1. ETAGOs need to be escaped in HTML script elements, or they end
Typo. I think you are responding to the only post that had that
error.
[snip]
>
> 2. The above triggers the Netscape Run-Length Bug.
What does? And in what version of Netscape? The later revisions were
tested in at least two versions of Netscape (as well as six other
browsers and a cell phone.)
>
> 3. The above is not required as the targeted UAs usually also support
> scripting style properties on-load the document, and the rules are
> not that complex that they cannot be emulated with scripting
> style properties.
I have no idea what that means. But you may wish to keep reading the
thread as the example has been discussed to death and revised five or
six times.
>
> > [...]
> > window.onload = windowLoad;
>
> Needlessly proprietary approach. The (X)HTML body element provides a
> standards compliant and well-supported `onload' event handler attribute:
That line is in the head of the document. The body element doesn't
exist at that point.
>
> <body onload="windowLoad()">
I never use inline event attributes. That was a topic of another
recent thread about unobtrusive scripting.
> PointedEars
> --
> var bugRiddenCrashPronePieceOfJunk = (
> navigator.userAgent.indexOf('MSIE 5') != -1
> && navigator.userAgent.indexOf('Mac') != -1
> ) // Plone, register_function.js:16
What is this from?
David Mark
[snip]
>
> I will narrow it down for you. The re-write has it down to 3 lines. And
> those three lines are in the onload function. And bare in mind that this
> thread has become more about feature detection than it ever will be
> about hiding/showing text.
No kidding.
>
> Note also that I said "can fail" and not "will fail". All three lines
I suppose virtually anything "can fail."
> fall into the "what if the UA doesn't support what you are trying to do"
> category and is more of a mental exercise than anything else. Although I
I'm pretty sure I know what you are driving at. Like if gEBTN is an
empty placeholder and returns null instead of an array. Or if the
style property of an element is not an object, etc. Okay, but I am
not adding any more bloat to what was originally supposed to be a
simple example. I think my last description of it was "pretty bullet-
proof", which doesn't mean 100% guaranteed to work in every browser
and device that has come out since 1995.
> can tell you that the browser in my cell phone does not support dynamic
> onclicks and tabIndex. It handles them fine if code in the HTML though.
It also does not support updating display properties, so the answers
appear from the start and all should be well. You did mention that
your version of an earlier example worked on your phone for just this
reason.
And bear in mind that I stated a while back that I wouldn't recommend
doing this with a simple FAQ in the first place. Furthermore, I don't
recommend showing/hiding elements at all when handheld style rules are
in effect. I explained how to achieve this with the more appropriate
example of popup menu lists a few posts back.
Randy Webb
> On Jul 31, 4:33 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
<snip>
>> can tell you that the browser in my cell phone does not support dynamic
>> onclicks and tabIndex. It handles them fine if code in the HTML though.
>
> It also does not support updating display properties, so the answers
> appear from the start and all should be well. You did mention that
> your version of an earlier example worked on your phone for just this
> reason.
It was more of a mental note than anything else. Not a lot to do with
the particular script at hand. I didn't find out it doesn't support
dynamic onclicks until I was working on something for work today and
tested it and discovered it wouldn't add them. That is when I started
testing some more to see what it did and didn't support.
Thomas 'PointedEars' Lahn
> On Jul 31, 9:30 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote: [snip]
Could you *please* at least try to retain context?
[Context restored]
>>> '<style type="text/ css">div.question div {display:none}
>>> div.question a
>>> {cursor:pointer;text-decoration:underline;color:blue}</style>');
>>
>> 2. The above triggers the Netscape Run-Length Bug.
>
> What does? And in what version of Netscape? The later revisions
> were tested in at least two versions of Netscape (as well as six
> other browsers and a cell phone.)
The NRLB has been spotted in all Netscape 4.x versions. Since it is
kind of a heisenbug (not reproducible, probably due to a caching issue),
you are not likely to encounter it when you are looking for it. You
will, however, encounter it at least once in the script's lifetime. It
does exist.
The NRLB is (AFAIK) as follows: (At least) Netscape 4.x cannot handle
dynamically written code in the `head' element, reason unknown.
Maybe one of the other regulars can explain it in more detail. I had
only heard of it in de.comp.lang.javascript, tested it, and saw it
confirmed several times. So I avoid to trigger it again, and recommend
so. Especially when using style includes that Netscape 4.x does not
support makes it unnecessary in the first place:
<link rel="stylesheet" href="!ns4.css" type="text/css"
media="screen">
>> 3. The above is not required as the targeted UAs usually also
>> support scripting style properties on-load the document, and the
>> rules are not that complex that they cannot be emulated with
>> scripting style properties.
>
> I have no idea what that means. But you may wish to keep reading the
> thread as the example has been discussed to death and revised five
> or six times.
I am talking about the CSS rules that you include with scripting above.
That could be facilitated if you simply set the style on each fitting
element through interation. However, when I think about it, if NN4 was
a target browser, which does not support that approach, the above
proposition would be reasonable instead.
>>> [...] window.onload = windowLoad;
>> Needlessly proprietary approach. The (X)HTML body element provides
>> a standards compliant and well-supported `onload' event handler
>> attribute:
>
> That line is in the head of the document. The body element doesn't
> exist at that point.
Non sequitur.
>> <body onload="windowLoad()">
>
> I never use inline event attributes. That was a topic of another
> recent thread about unobtrusive scripting.
So you are *deliberately* making your code *not interoperable* by
insisting on using *proprietary* features where a *well-supported*
*standards-compliant* alternative exists? I think that is to be called
ignorant incompentence.
>> [...]
Don't quote name signatures unless you refer to it, please.
>> --
>> var bugRiddenCrashPronePieceOfJunk = (
>> navigator.userAgent.indexOf('MSIE 5') != -1
>> && navigator.userAgent.indexOf('Mac') != -1
>> ) // Plone, register_function.js:16
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> What is this from?
Read the Source, Luke.
PointedEars€
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not the
best source of advice on designing systems that use javascript.
-- Richard Cornford, <f806at$ail$1$8300...@news.demon.co.uk>
Randy Webb
> David Mark wrote:
>> On Jul 31, 9:30 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>> wrote: [snip]
>
> Could you *please* at least try to retain context?
Are you really that stupid? After you complained about context you
didn't even restore the full context.
> [Context restored]
[full Context restored]
if (document.getElementById) document.write('<style type="text/
css">div.question div {display:none} div.question a
{cursor:pointer;text-decoration:underline;color:blue}</style>');
>>>> '<style type="text/ css">div.question div {display:none}
>>>> div.question a
>>>> {cursor:pointer;text-decoration:underline;color:blue}</style>');
>>>
>>> 2. The above triggers the Netscape Run-Length Bug.
>>
>> What does? And in what version of Netscape? The later revisions
>> were tested in at least two versions of Netscape (as well as six
>> other browsers and a cell phone.)
>
> The NRLB has been spotted in all Netscape 4.x versions. Since it is
> kind of a heisenbug (not reproducible, probably due to a caching issue),
> you are not likely to encounter it when you are looking for it. You
> will, however, encounter it at least once in the script's lifetime. It
> does exist.
And it won't be encountered by trying to write that style element as
NN4.xx series browsers will never execute the document.write statement.
Try reading the code again.
> The NRLB is (AFAIK) as follows: (At least) Netscape 4.x cannot handle
> dynamically written code in the `head' element, reason unknown.
Look again and you will note that Netscape4.x series browsers will
*never* execute the document.write in question since it is wrapped in an
if(document.getElementById) { test and since NN4 doesn't support that
feature it will *never* execute it and thus never trigger the NRLB.
> Maybe one of the other regulars can explain it in more detail. I had
> only heard of it in de.comp.lang.javascript, tested it, and saw it
> confirmed several times. So I avoid to trigger it again, and recommend
> so. Especially when using style includes that Netscape 4.x does not
> support makes it unnecessary in the first place:
>
> <link rel="stylesheet" href="!ns4.css" type="text/css"
> media="screen">
There is nothing to "explain" as it will never come into play. Perhaps
you should go back to de.comp.lang.javascript and have them explain to
you why the above code would *not* trigger the NRLB bug in a 10 year old
browser.
>>> 3. The above is not required as the targeted UAs usually also
>>> support scripting style properties on-load the document, and the
>>> rules are not that complex that they cannot be emulated with
>>> scripting style properties.
>>
>> I have no idea what that means. But you may wish to keep reading the
>> thread as the example has been discussed to death and revised five
>> or six times.
>
> I am talking about the CSS rules that you include with scripting above.
> That could be facilitated if you simply set the style on each fitting
> element through interation. However, when I think about it, if NN4 was
> a target browser, which does not support that approach, the above
> proposition would be reasonable instead.
You are referring to what has already been covered - along with the
pitfalls - of alternative approaches. Had you read and understood the
entire thread you would realize that.
>>>> [...] window.onload = windowLoad;
>>> Needlessly proprietary approach. The (X)HTML body element provides
>>> a standards compliant and well-supported `onload' event handler
>>> attribute:
>>
>> That line is in the head of the document. The body element doesn't
>> exist at that point.
>
> Non sequitur.
It is very relevant.
>>> <body onload="windowLoad()">
>>
>> I never use inline event attributes. That was a topic of another
>> recent thread about unobtrusive scripting.
>
> So you are *deliberately* making your code *not interoperable* by
> insisting on using *proprietary* features where a *well-supported*
> *standards-compliant* alternative exists? I think that is to be called
> ignorant incompentence.
What is ignorant incompetence is your belief that you have added
anything of value to this thread other than the amusement of people who
know better.
BTW, can you name one UA less than 5 years old that does not support
window.onload that supports <body onload=? If you can, great. If you
can't, then you are just babbling nonsense.
>>> [...]
>
> Don't quote name signatures unless you refer to it, please.
Ummm, yooooohooooo, moron, he asked a specific question about your
signature and as such it is the *only* way to "retain context" is by
quoting it.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 8/1/2007 8:06 AM:
>> David Mark wrote:
>>> On Jul 31, 9:30 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>>> wrote: [snip]
>> Could you *please* at least try to retain context?
>
True, my bad.
>> [Context restored]
>
> [full Context restored]
>
> if (document.getElementById) document.write('<style type="text/
> css">div.question div {display:none} div.question a
> {cursor:pointer;text-decoration:underline;color:blue}</style>');
>
>>>>> '<style type="text/ css">div.question div {display:none}
>>>>> div.question a
>>>>> {cursor:pointer;text-decoration:underline;color:blue}</style>');
>>>> 2. The above triggers the Netscape Run-Length Bug.
>>> What does? And in what version of Netscape? The later revisions
>>> were tested in at least two versions of Netscape (as well as six
>>> other browsers and a cell phone.)
>> The NRLB has been spotted in all Netscape 4.x versions. Since it is
>> kind of a heisenbug (not reproducible, probably due to a caching issue),
>> you are not likely to encounter it when you are looking for it. You
>> will, however, encounter it at least once in the script's lifetime. It
>> does exist.
>
> And it won't be encountered by trying to write that style element as
> NN4.xx series browsers will never execute the document.write statement.
Most certainly. (See? *I* don't have a problem to admit when I'm wrong.)
> Try reading the code again.
[x] done
>> Maybe one of the other regulars can explain it in more detail. I had
>> only heard of it in de.comp.lang.javascript, tested it, and saw it
>> confirmed several times. So I avoid to trigger it again, and recommend
>> so. Especially when using style includes that Netscape 4.x does not
>> support makes it unnecessary in the first place:
>>
>> <link rel="stylesheet" href="!ns4.css" type="text/css"
>> media="screen">
>
> There is nothing to "explain" as it will never come into play. Perhaps
> you should go back to de.comp.lang.javascript and have them explain to
> you why the above code would *not* trigger the NRLB bug in a 10 year old
> browser.
Where I saw it, the object test was not included, because the object did
not yet exist at that time. Still I think mentioning the style include
was not a complete waste.
>>>> 3. The above is not required as the targeted UAs usually also
>>>> support scripting style properties on-load the document, and the
>>>> rules are not that complex that they cannot be emulated with
>>>> scripting style properties.
>>> I have no idea what that means. But you may wish to keep reading the
>>> thread as the example has been discussed to death and revised five
>>> or six times.
>> I am talking about the CSS rules that you include with scripting above.
>> That could be facilitated if you simply set the style on each fitting
>> element through interation. However, when I think about it, if NN4 was
>> a target browser, which does not support that approach, the above
>> proposition would be reasonable instead.
>
> You are referring to what has already been covered - along with the
> pitfalls - of alternative approaches. Had you read and understood the
> entire thread you would realize that.
Again, if duplicates bother you, just leave Usenet.
>>>>> [...] window.onload = windowLoad;
>>>> Needlessly proprietary approach. The (X)HTML body element provides
>>>> a standards compliant and well-supported `onload' event handler
>>>> attribute:
>>> That line is in the head of the document. The body element doesn't
>>> exist at that point.
>> Non sequitur.
>
> It is very relevant.
Granted, it is relevant in the sense that `window.onload' is error-prone
because of that. However, the statement that it is in the head of the
document constitutes no reasoning for not using the `onload' event
handler attribute of the `body' element. Because, when the `load' event
fires for the `body' element, the `body' element exists.
>>>> [...]
>> Don't quote name signatures unless you refer to it, please.
>
> Ummm, yooooohooooo, moron, he asked a specific question about your
> signature and as such it is the *only* way to "retain context" is by
> quoting it.
The name was not part of the message signature, and he did not refer to
the name. So quoting it was uncalled for.