Re: Script for Hiding/Un-Hiding Text On Click

On Jul 29, 7:20 pm, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
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 *** 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 *** 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 *** 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="style***"
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?

.