change CSS class

T

Thomas 'PointedEars' Lahn

Garrett said:
Thomas said:
Garrett said:
Garrett Smith wrote:
kangax wrote:
Thomas 'PointedEars' Lahn wrote:
[...]
Example
That was the wrong example, try again:-
<!doctype html>
Not Valid.

True, but does trigger standards mode in the browsers tested (and that
has been discussed here).

Red herring.
Is that scorn or are you trying to discuss the use of |in| in host object?

I am just fascinated that although it has been discussed to death you still
use it.
Regarding the use of |in| with host object, I mentioned the "false
positive" edge case using "99999" in document.styleSheets in IE, nearly
1 month ago. I have been looking for more cases that fail. Such failure
cases would give more weight to the argument of |in| being inappropriate
for host objects.

Proof by (bad) example. The probability that there are 100'000 stylesheets
in a single document and that this needs to be tested is close to 0.
if(typeof rules != "undefined") {
Given that we are talking host objects, `rules' may store any value at this
point. The test is insufficient.
document.write("<pre>rules[0].selectorText: " + rules[0].selectorText
+ "<" + "/pre>");
Smart people use "<\/" to hide ETAGO delimiters from SGML(-ish) parsers
since about the turn of the century.

It is a little easier to do it with a backslash.

It is also more efficient, easier legible, and easier to maintain.
Certainly much easier than arguing about it.

I don't know exactly what kind of fallacy this is, but it is one.
Either way would work, though.

Red herring.
document.write("<p>assign rules[0].selectorText = 'body'...</p>");
try {
rules[0].selectorText = "body";
Nobody tried (or would even attempt trying) to modify `selectorText' but
you. You were willing to concede that point in
<yet one hour 22 minutes
later you are starting this again. What the heck is wrong with you?

I have noticed you have a tendency to blame others for not understanding
what you do not understand.

Ad hominem fallacy.
In this case, you seem to not understand is why I am testing assigning
to selectorText. The reason I am doing that is because I am curious as
to how browsers would handle that.

It is a waste of time trying to do things that are not supposed to work.


PointedEars
 
S

seani

It is a waste of time trying to do things that are not supposed to work.

Really?

I'd expect, in that case, that there are no browsers that exhibit
unexpected or apparently non-deterministic behaviour when they
encounter incorrectly formed DHTML/JS?

Thank God, for instance, that IE in particular doesn't have a history
of jinking and twisting itself into a heap in an attempt to
accommodate and render any old shite rather than flagging an error,
leaving bewildered developers in it's wake.

Oh, hang on, I meant to say exactly the opposite.
 
T

Thomas 'PointedEars' Lahn

seani said:

Yes, really.
I'd expect, in that case, that there are no browsers that exhibit
unexpected or apparently non-deterministic behaviour when they
encounter incorrectly formed DHTML/JS?

Ignoratio elenchi.
Thank God, for instance, that IE in particular doesn't have a history
of jinking and twisting itself into a heap in an attempt to
accommodate and render any old shite rather than flagging an error,
leaving bewildered developers in it's wake.

Oh, hang on, I meant to say exactly the opposite.

Yes, in your second "argument" you are referring to things here that are
*supposed to work* but don't (in MSHTML-based UAs). Those need to be
tested, of course.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,102
Messages
2,570,645
Members
47,245
Latest member
ShannonEat

Latest Threads

Top