David Mark said the following on 7/22/2007 7:36 PM:
David Mark said the following on 7/22/2007 6:20 PM:
On Jul 21, 8:18 pm, ASM <
[email protected]>
wrote:
[snip]
<snip>
#FAQ { cursor: pointer; _cursor: hand; }
Why not:
cursor
ointer;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?
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.
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.
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.
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.
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.
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:
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.
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.
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.