Event Handling via CSS
c.janard...@gmail.com
I have seen sites using css attribute like "hover" to make dynamic
websites.
In some sites most elements don't have direct event handlers like
'mouseover', 'mouseout' etc attached to html elements. Instead they
use CSS. Could any one you give me some idea about invoking
JavaScript event handlers via css for CSS attributes like "hover"?
E.g: In hp.com, tabs like 'Support & Drivers' or 'Shop for Products'
are <a> HTML elements which don't have any event handlers directly
attached to them. Still they modify the DOM on mouseover/out. I
believe they are done via CSS. Could any body of you please give me
some guidance regarding this ?
Thanks in Advance,
Janardhan
Erwin Moller
Hi,
You do not define JavaScript eventhandlers in your CSS declaration.
You should add them via JavaScript.
The hover behaviour you mentioned is something that is fully defined in
CSS. (Just google for 'hover css')
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Thomas 'PointedEars' Lahn
terminology, which hinder understanding.
c.janard...@gmail.com wrote:
> I have seen sites using css attribute like "hover" to make dynamic
> websites.
Those are pseudo-classes, not attributes:
<http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes>
> In some sites most elements don't have direct event handlers like
> 'mouseover', 'mouseout' etc attached to html elements. Instead they
> use CSS. Could any one you give me some idea about invoking
> JavaScript event handlers via css for CSS attributes like "hover"?
`mouseover', `mouseout' etc. are _not_ "event handlers", those are event
types. There is also no such thing as "JavaScript event handlers". And
even if there were, you could not "invoke" them "via css"; CSS is merely
a formatting language.
<http://www.w3.org/Style/CSS/>
When the user or a program does something in a user agent, an event
occurs. That may create an event object to propagate the event in the
document tree.
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow>
<http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-flow>
It may also, rather independently of the DOM, trigger a style sheet selector
that uses a dynamic pseudo-class.
DOM implementations provide internal event-handlers so that code may
handle these events. Event-handlers call one or more event-listeners; the
latter can be added with implementations that implement specified interfaces.
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener>
<http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-listeners>
HTML elements provide event-handler attributes which value is supposed to be
code written in a scripting language that is executed when the event occurs.
<http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.3>
(Here event-handler attributes are called "events"; watch the date of this
Specification and don't let yourself be confused by this.)
DOM objects may provide proprietary event-handler properties which value is
supposed to be (a reference to) a callable object that contains the code to
be executed on event. If such a DOM object represents an element in the
document, then that element does not need to have one of the aforementioned
event-handler attributes specified, provided there is an event-handler
property for that attribute.
There are also proprietary events and corresponding event-handler properties
that have no corresponding event-handler attribute in Valid markup, e.g.
<https://developer.mozilla.org/en/DOM/element#Event_Handlers>
(Noticed that there has been no mentioning of JavaScript until here? For
these features are independent of a programming language.)
Now, DOM implementations also provide properties that implement interfaces
of CSS-related APIs:
<http://www.w3.org/TR/DOM-Level-2-Style/css.html>
You can use these properties to manipulate style sheets, e.g.
element.style.display = "none";
to prevent an the element that is represented by the object `element' refers
to from being rendered.
However, you only need to do this for user agents that do not support the
corresponding CSS property, or pseudo-class for the element in question, or
CSS at all.
> E.g: In hp.com, tabs like 'Support & Drivers' or 'Shop for Products'
> are <a> HTML elements which don't have any event handlers directly
> attached to them. Still they modify the DOM on mouseover/out.
If anything, they would modify the document tree; the DOM is a *model*, an
API instead, and usually not modified by an application using it. (In fact,
it is strongly recommended against trying to modify a DOM implementation on
the fly; the objects provided are *host* *objects*, not, e.g. ECMAScript
native objects.)
> I believe they are done via CSS.
The content is styled with CSS, but I presume the content is exchanged with
the IXMLHTTPRequest API (XHR, also known as AJAX -- Asynchronous JavaScript
and XML).
<https://developer.mozilla.org/en/AJAX>
Of course, this doesn't work where XHR support is unavailable, and it can
cause considerable delays if XHR support is available but there is small
bandwidth or the display device is a mobile one.
In fact, the whole HP website is not exactly a showcase of good Web
authoring. Starts with
<http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.hp.com%2F%23Support>
| 105 Errors, 15 warnings
<http://jigsaw.w3.org/css-validator/validator?profile=css3&warning=2&uri=http%3A%2F%2Fwww.hp.com%2F%23Support>
| Sorry! We found the following errors (6)
and ends with their using jQuery from which you should stay far away at
least at this point of its development. (Search the archives. JFTR:
I have very fast Internet access here, and a reasonably fast CPU, OS, and
browser[1]; yet switching from one section to the other through mouseover
takes about half a second! Talk about code efficiency ...)
> Could any body of you please give me some guidance regarding this ?
[x] done
HTH
PointedEars
___________
[1] Cable Internet access, 15000 kbps downstream top;
Pentium M 740, 1 GB RAM;
Debian GNU/Linux lenny/testing/unstable/experimental,
Linux 2.6.28.8-20090322.180402, 1 GB Swap;
KDE 3.5.9.dfsg.1-6, Firefox/Iceweasel 3.0.6
SAM
After the other answers you can go to a site that uses and demosntrates
this "css-event"
<http://www.cssplay.co.uk/menus/index.html>
fun : <http://www.cssplay.co.uk/menu/streaker>
panoramic scroller :
<http://www.cssplay.co.uk/menu/scroller>
--
sm
Erwin Moller
> You appear to have acquired a number of misconceptions and false
> terminology, which hinder understanding.
>
> c.janard...@gmail.com wrote:
>> I have seen sites using css attribute like "hover" to make dynamic
>> websites.
>
> Those are pseudo-classes, not attributes:
>
> <http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes>
>
>> In some sites most elements don't have direct event handlers like
>> 'mouseover', 'mouseout' etc attached to html elements. Instead they
>> use CSS. Could any one you give me some idea about invoking
>> JavaScript event handlers via css for CSS attributes like "hover"?
>
> `mouseover', `mouseout' etc. are _not_ "event handlers", those are event
> types. There is also no such thing as "JavaScript event handlers". And
> even if there were, you could not "invoke" them "via css"; CSS is merely
> a formatting language.
Hi Thomas,
The part 'There is also no such thing as "JavaScript event handlers".'
was a surprise to me.
I always thought of this matter in oversimplified terms, like: "the
browser can generate an event of a certain type that can invoke a
certainJavaScript event handler."
Oversimplified view I see now. :-)
Clear posting. :-)
<snipped good explanation to spare bandwidth>
c.janard...@gmail.com
wrote:
> You appear to have acquired a number of misconceptions and false
> terminology, which hinder understanding.
>
> > I have seen sites using css attribute like "hover" to make dynamic
> > websites.
>
> Those are pseudo-classes, not attributes:
>
> <http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes>
>
> > In some sites most elements don't have direct event handlers like
> > 'mouseover', 'mouseout' etc attached to html elements. Instead they
> > use CSS. Could any one you give me some idea about invoking
> > JavaScript event handlers via css for CSS attributes like "hover"?
>
> `mouseover', `mouseout' etc. are _not_ "event handlers", those are event
> types. There is also no such thing as "JavaScript event handlers". And
> even if there were, you could not "invoke" them "via css"; CSS is merely
> a formatting language.
>
> <http://www.w3.org/Style/CSS/>
>
> When the user or a program does something in a user agent, an event
> occurs. That may create an event object to propagate the event in the
> document tree.
>
> <http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow>
>
> It may also, rather independently of the DOM, trigger a style sheet selector
> that uses a dynamic pseudo-class.
>
> DOM implementations provide internal event-handlers so that code may
> handle these events. Event-handlers call one or more event-listeners; the
> latter can be added with implementations that implement specified interfaces.
>
> <http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener>
> | 105 Errors, 15 warnings
>
> <http://jigsaw.w3.org/css-validator/validator?profile=css3&warning=2&u...>
> | Sorry! We found the following errors (6)
>
> and ends with their using jQuery from which you should stay far away at
> least at this point of its development. (Search the archives. JFTR:
> I have very fast Internet access here, and a reasonably fast CPU, OS, and
> browser[1]; yet switching from one section to the other through mouseover
> takes about half a second! Talk about code efficiency ...)
>
> > Could any body of you please give me some guidance regarding this ?
>
> [x] done
>
> HTH
>
> PointedEars
> ___________
> [1] Cable Internet access, 15000 kbps downstream top;
> Pentium M 740, 1 GB RAM;
> Debian GNU/Linux lenny/testing/unstable/experimental,
> Linux 2.6.28.8-20090322.180402, 1 GB Swap;
> KDE 3.5.9.dfsg.1-6, Firefox/Iceweasel 3.0.6
Hi,
Thanks for sharing valuable information, I need to get the pseudo-
classes(.hover .active etc) attached to elements via CSS. I got the
DOM nodelist using
var nodelist = document.getElementsByTagName('*'). Is there any way
that i could get pseudo-class for each element(nodelist[0]).
I found one way in getting hover as below:
var rule = window.document.styleSheets[0].cssRules[0];
rule.selectorText;but this eats up the process Speed if website have
multiple CSS files.
Could you please help in getting pseudo-class using the nodelist.
Thanks in Advance.
Janardhan
Thomas 'PointedEars' Lahn
> Now, DOM implementations also provide properties that implement interfaces
> of CSS-related APIs:
>
> <http://www.w3.org/TR/DOM-Level-2-Style/css.html>
>
> You can use these properties to manipulate style sheets, e.g.
>
> element.style.display = "none";
>
> to prevent an the element that is represented by the object `element' refers
> to from being rendered.
>
> However, you only need to do this for user agents that do not support the
> corresponding CSS property, or pseudo-class for the element in question, or
> CSS at all.
In the last case, it does not work no matter how you do it, of course. If
CSS is not supported, you cannot trigger it with scripting as well. So you
can ignore this particular case. (However, previous UAs that do not support
CSS really, may support CSS-like properties. For example, Netscape 4.x does
support a `visibility' property for certain elements: element.visibility =
"hide".)
PointedEars
Thomas 'PointedEars' Lahn
> [snipped full quote]
> Thanks for sharing valuable information,
Thank you for trimming quotes to the relevant minimum next time. I (and
everybody else) know what a wrote.
<http://jibbering.com/faq/#posting>
> I need to get the pseudo-classes(.hover .active etc)
The pseudo-classes are `:hover' and `:active', respectively. The colon
distinguishes them against "normal" classes which start with a dot in the
stylesheet (`.foobar').
> attached to elements via CSS.
To format `a' elements in the document so that their text color turns red
when the pointer is placed on it:
a:hover {
color: red;
}
(Selectors with greater specificity not considered, of course. See also
<http://www.w3.org/QA/Tips/color>.)
Plain CSS is off-topic here, though.
> I got the DOM nodelist using
> var nodelist = document.getElementsByTagName('*'). Is there any way
> that i could get pseudo-class for each element(nodelist[0]).
Yes, theoretically you could use the document.styleSheets collection and
find out if a selector in a stylesheet using a dynamic pseudo-class applies
to the element in question.
However, you are still going about this the wrong way; CSS has nothing to do
with DOM events. What are you trying to do anyway, and why?
PointedEars
Roger
wrote:
> You appear to have acquired a number of misconceptions and false
> terminology, which hinder understanding.
>
> > I have seen sites using css attribute like "hover" to make dynamic
> > websites.
>
> Those are pseudo-classes, not attributes:
>
> <http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes>
>
> > In some sites most elements don't have direct event handlers like
> > 'mouseover', 'mouseout' etc attached to html elements. Instead they
> > use CSS. Could any one you give me some idea about invoking
> > JavaScript event handlers via css for CSS attributes like "hover"?
>
> `mouseover', `mouseout' etc. are _not_ "event handlers", those are event
> types. There is also no such thing as "JavaScript event handlers". And
> even if there were, you could not "invoke" them "via css"; CSS is merely
> a formatting language.
>
> <http://www.w3.org/Style/CSS/>
>
> When the user or a program does something in a user agent, an event
> occurs. That may create an event object to propagate the event in the
> document tree.
>
> <http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow>
>
> It may also, rather independently of the DOM, trigger a style sheet selector
> that uses a dynamic pseudo-class.
>
> DOM implementations provide internal event-handlers so that code may
> handle these events. Event-handlers call one or more event-listeners; the
> latter can be added with implementations that implement specified interfaces.
>
> <http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener>
> | 105 Errors, 15 warnings
>
> <http://jigsaw.w3.org/css-validator/validator?profile=css3&warning=2&u...>
> | Sorry! We found the following errors (6)
>
> and ends with their usingjQueryfrom which you should stay farawayat
> least at this point of its development.
Or ever as they will never learn. I actually posted a message (under
a pseudonym of course) to their forum once:
http://groups.google.com/group/jquery-en/msg/473e3de5293e34f8
Banned immediately for stating that jQuery uses browser sniffing.
Probably fired their moderator too. :)
More evidence that they are terminally stuck in the year 2000 and
there is no hope for their plug-in system:
http://groups.google.com/group/jquery-en/browse_thread/thread/896ad397997595d9
Development group is nuts too:
http://groups.google.com/group/jquery-dev/browse_thread/thread/102a0e11ce86fdad
Sure, use jQuery with XHTML. It blows up real good.
Damn, banned again. Two messages, two groups, two bans. Has to make
you wonder why they are so scared of criticism and why they would try
to shield their users from relevant issues. Doesn't really bode well
for the future and past and present versions are obviously out of the
question.
Speaking of the future, I think most of the "supported browsers" have
QSA now.
This is Sizzle:
if ( document.querySelectorAll ) (function(){
var oldSizzle = Sizzle, div = document.createElement("div");
div.innerHTML = "<p class='TEST'></p>";
// Safari can't handle uppercase or unicode characters when
// in quirks mode.
if ( div.querySelectorAll && div.querySelectorAll(".TEST").length ===
0 ) {
return;
}
Sizzle = function(query, context, extra, seed){
context = context || document;
// Only use querySelectorAll on non-XML documents
// (ID selectors don't work in non-HTML documents)
if ( !seed && context.nodeType === 9 && !isXML(context) ) {
try {
return makeArray( context.querySelectorAll(query), extra );
Note. No steak.
} catch(e){}
}
return oldSizzle(query, context, extra, seed);
};
Sizzle.find = oldSizzle.find;
Sizzle.filter = oldSizzle.filter;
Sizzle.selectors = oldSizzle.selectors;
Sizzle.matches = oldSizzle.matches;
})();
I recognize *that* pattern. Now if people can figure out that
"chaining" is just:
return this;
...nobody will feel compelled to rely on jQuery's Script of the Month
Club again.
David Mark
[snip]
>
> Or ever as they will never learn. I actually posted a message (under
> a pseudonym of course) to their forum once:
Oops, posted this under the same alias. Dear moderator, please don't
ban "Roger"; he's a good guy!
Garrett Smith
Funny. I can go to the jQuery development groups and criticize jQuery
but I don't get banned.
I'm not overly friendly there. I hold some contempt for the effect
jQuery has had on my industry and also get annoyed when posters do not
include examples.
But I'm not calling people idiots and buffoons, either. I wonder if that
might have something to do with it.
Garrett
Thomas 'PointedEars' Lahn
> On Apr 21, 10:54 am, Roger wrote:
>> Or ever as they will never learn. I actually posted a message (under
>> a pseudonym of course) to their forum once:
>
> Oops, posted this under the same alias. Dear moderator, please don't
> ban "Roger"; he's a good guy!
Either I don't get the joke (and the whole "Roger" thing at all) or you need
to be told: there is no moderator here.
PointedEars
David Mark
> David Mark wrote:
> > On Apr 21, 10:54 am, Roger <roger.gilre...@gmail.com> wrote:
>
> > [snip]
>
> >> Or ever as they will never learn. I actually posted a message (under
> >> a pseudonym of course) to their forum once:
>
> > Oops, posted this under the same alias. Dear moderator, please don't
> > ban "Roger"; he's a good guy!
>
> Funny. I can go to the jQuery development groups and criticize jQuery
> but I don't get banned.
That is queer.
>
> I'm not overly friendly there. I hold some contempt for the effect
> jQuery has had on my industry and also get annoyed when posters do not
> include examples.
>
> But I'm not calling people idiots and buffoons, either. I wonder if that
> might have something to do with it.
Is that supposed to be a joke? "Roger" didn't call anyone anything.
You really should refrain from knee-jerk reactions.
David Mark
wrote:
The whole thing is this. jQuery devotees often decry the fact that
criticism is posted here, rather than in the jQuery forums.
Obviously, the experiment would have been biased had I attempted to
post under my real name (considering that I am the one that originally
exposed jQuery as intellectually bankrupt, not to mention that they
aped my code in their latest release.)
So, I posted a couple of sentences in reply to a person who wanted to
combine jQuery 1.2x and MooTools. (!) Just said it used browser
sniffing. Here's the response:
http://groups.google.com/group/jquery-en/msg/3ee975bc6332133e
"1.3 has no browser sniffing at all. That said, I don't see how
browser sniffing relates whatsoever to two libraries both functioning
on the same page."
I'm sure he can't see how two distinct blobs of browser sniffing in
the same document would be a nightmare.
Of course 1.3x has browser sniffing. It's full of it and history
shows that it would still be sniffing the *UA string* if not for my
input. For some reason they are pissed off about that and so are
their users. (?)
I suppose some people can go over there and discuss code they've never
read (or remotely influenced) without getting banned. I guess Resig's
feelings are what matters most. Don't cry for him though as he has
only himself to blame (in every conceivable way.)
David Mark
>
> > Development group is nuts too:
>
> reason...
LOL. A *very* good reason. Resig would never let me in that group.
Would have biased the results for sure. :)
>
> In response to "please keep discussions on track and civil":
> "Nice sentiment. Do you own the place? If so, you are a really lousy
> moderator (especially since you don't follow the discussions
> closely.)"
Who are you talking to?
>
> "I dare you to ban me (would be your loss.)"
And wouldn't you know? He actually *did* (despite the public
outcry.) Supposed to outgrow taking dares by five.
>
> About future enhancements plans for jQuery:
> "Then everybody can upgrade your monolithic mess again?
> Is this project a long-running practical joke are are you really
> serious?"
>
> For an expert, your understanding of frameworks seems flabby. XHTML
Did you mean "expert?" Flabby? As in fat?
> served as application/xhtml+xml is not a reality in the web right now
Thanks for that nugget, "Ricardo." You guys do operate with blinders
on, don't you? Of all of the library authors on the planet (quite a
few these days), you picked the *one* who has actually published an
XHTML compatible library. So much for luck.
> for lack of support. jQuery is aimed at development of real websites.
See, that is where you are wrong. For an "expert", your understanding
seems acutely anorexic. I remember you as the one who recommended
using an htmlFor attribute in markup to work around jQuery's idiotic
attr method. For God's sake.
> If that's not your game just forget it.
Of course, the entire point was that Resig didn't realize what you
just tried to say. jQuery cannot run in an XHTML DOM. Of course, it
isn't too hot with HTML either. Or XML for that matter. It's pretty
much a train wreck in any language which is unsurprising given the
conductors.
Garrett Smith
Right.
Mootools does a lot of modification to host and built-in objects'
prototypes. It is not recommended to run that library with other
libraries in the same page.
In rereading your post on the jQuery list, I agree 100%.
Garrett
David Mark
Outstanding point (which I somehow neglected.) Neither of those
scripts filters for-in loops.
>
> In rereading your post on the jQuery list, I agree 100%.
I think we agree on most points, but the communication breaks down
occasionally. It is good that you are lending a hand over there (I
assume you are telling people how to do things properly, which
typically excludes jQuery.) Hopefully they won't ban you for that.
In any event, I think it is too late for them to survive as anything
but a curiosity.
David Mark
You missed that one.
>
> > Did you mean "expert?" Flabby? As in fat?
>
> from wordnet.princeton.edu: (out of condition; not strong or robust;
> incapable of exertion or endurance). foda-se.
Doesn't really matter, does it?
>
> > > served as application/xhtml+xml is not a reality in the web right now
>
> > Thanks for that nugget, "Ricardo." You guys do operate with blinders
> > on, don't you? Of all of the library authors on the planet (quite a
> > few these days), you picked the *one* who has actually published an
> > XHTML compatible library. So much for luck.
>
> Interesting, where do I find it? Given that something between 40-70%
> of all browsers out there (IE) don't support yet, I guess it's only
> useful in controlled environments, right?
Where can you find what? If you are referring to My Library, then you
are beyond help. Ask your fellow jQuery mavens. God knows they've
seen it. And it is obviously for (X)HTML.
>
> > See, that is where you are wrong. For an "expert", your understanding
> > seems acutely anorexic. I remember you as the one who recommended
> > using an htmlFor attribute in markup to work around jQuery's idiotic
> > attr method. For God's sake.
>
> I never said I'm an expert, I'm not. I wouldn't be surprised to know
> you've been coding in javascript longer than I've been around.
So you are a kid? That explains a lot.
> And I
> never recommended using an htmlFor attribute as a workaround to
> anything:http://groups.google.com/group/jquery-en/browse_thread/thread/f2cff39...
Yes, you did. Though it is clear that you don't really know what you
are saying.
http://groups.google.com/group/jquery-en/msg/71bb5cd00535689f
>
> I can state that the attr() method has a flaw without cursing someone
> or something, "unexpected" is what I said. Do you have tourette's or
> something?
Who cursed you? Are you delusional?
>
>
>
> > Of course, the entire point was that Resig didn't realize what you
> > just tried to say. jQuery cannot run in an XHTML DOM. Of course, it
> > isn't too hot with HTML either. Or XML for that matter. It's pretty
> > much a train wreck in any language which is unsurprising given the
> > conductors.
>
> right! jQuery can't run in XHTML served as application/xhtml+xml. It's
And how it is a good thing that the author of the script doesn't know
that? Everything he says is wrong, even when talking about his own
script.
> made to run on current web technology, which is XHTML served as text/
> html, that responds for the vast majority of living websites.
XHTML served as HTML is not "current web technology", nor is jQuery
designed in any way to work with such a scheme. As with most of it,
it works by coincidence in some agents and configurations.
>
> About not being "too hot" with HTML, that's a personal opinion.
No, it isn't an opinion. It is a fact. I suggest you search the
archive for "jQuery." Just read the last few weeks or so.
> A
> great deal of web developers will disagree with you, I guess we're all
> stupid for that.
Ignorant would be more kind (though that doesn't always apply.)
> jQuery doesn't claim to handle XML either, wherever
> it fits it's passed to the browser to take care of it.
That is either meaningless or completely untrue. I can't decide
which.
>
> So, who did you say can't take criticism anyway? I realized joining a
> conversation with you with opposite opinions was asking for trouble,
You seem to have everything backwards.
> but I didn't know it would come so fast and so low. Please refrain
> from answering this if you can't keep a decent level of conversation,
> I'm sure everyone will appreciate it.
>
What a moron.
David Mark
> On 22 abr, 12:54, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > > Interesting, where do I find it? Given that something between 40-70%
> > > of all browsers out there (IE) don't support yet, I guess it's only
> > > useful in controlled environments, right?
>
> > Where can you find what? If you are referring to My Library, then you
> > are beyond help. Ask your fellow jQuery mavens. God knows they've
> > seen it. And it is obviously for (X)HTML.
>
I certainly don't want anybody who can't find it on their own to
bother me about it. :)
See my posts regarding it in the archive. I gave you the name.
>
>
>
> > > And I
> > > never recommended using an htmlFor attribute as a workaround to
> > > anything:http://groups.google.com/group/jquery-en/browse_thread/thread/f2cff39...
>
> > Yes, you did. Though it is clear that you don't really know what you
> > are saying.
>
> >http://groups.google.com/group/jquery-en/msg/71bb5cd00535689f
>
> I'm not actually a native English speaker, but despite that the
> meaning of "being invalid" is quite clear to me, and I don't see a
> single word of encouragement in that message.
You wrote a wrong answer and it indicates that you are vaguely aware
of an issue, but regard it as browser magic, rather than a flaw in
jQuery. It is a common situation as jQuery creates lots of cross-
browser complications, which are invariably blamed on defective
browsers. This sort of thinking can be found in the forums, the
documentation, blog entries, books, etc. It keeps the myth of
jQuery's "simplification" alive.
See the - attr - method (something you should have done a long time
ago.) Then realize that jQuery did not "fix" Javascript and it does
not simplify cross-browser scripting. You are ten years behind the
rest of the world and won't move forward until you realize these
facts.
>
>
>
> > > made to run on current web technology, which is XHTML served as text/
> > > html, that responds for the vast majority of living websites.
>
> > XHTML served as HTML is not "current web technology", nor is jQuery
> > designed in any way to work with such a scheme. As with most of it,
> > it works by coincidence in some agents and configurations.
>
> What is 'current web technology' by your understanding then? I don't
> see any major website running on anything else, please enlighten me.
I'm not sure what you consider a "major website", but I will concede
that many Websites, of all shapes and sizes, are serving XHTML
(usually of the transitional and invalid variety) as HTML, pinning all
of their cross-browser hopes on error correction. They do this
because documents are copied from one hopelessly backwards developer
to the next.
Transitional XHTML was popular around the turn of the century as
developers thought it would be more "standard" or "future-proof" to
move to XHTML (and strict XHTML was too confining to transition
existing tag soup sites.) Ten years later, long after XHTML was
declared DOA for the Web, people are using it for new sites and
including scripts that could never hope to work with properly served
XHTML. In other words, if the XHTML future ever comes, all of their
documents will be DOA.
You indicated earlier that you thought the widespread adoption of
jQuery was an indication of its usefulness, as if you couldn't believe
the majority of Web developers are incompetent and prone to very bad
decisions. Do you feel the same way about the widespread adoption of
faux XHTML?
Gregor Kofler
> On 23 abr, 02:41, David Mark <dmark.cins...@gmail.com> wrote:
>> I certainly don't want anybody who can't find it on their own to
>> bother me about it. :)
>>
>> See my posts regarding it in the archive. I gave you the name.
>
> interested, so we can learn from the best.
http://lmgtfy.com/?q=david+mark+my+library
But then: Since you are unable to enter simple search terms into
<your_favourite_search_engine>, I'm pretty sure that you're lacking any
competence to assess the code quality David's (or any other JS) library.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Matthias Reuter
> On 23 abr, 02:41, David Mark <dmark.cins...@gmail.com> wrote:
>>
>> I certainly don't want anybody who can't find it on their own to
>> bother me about it. :)
>>
>> See my posts regarding it in the archive. I gave you the name.
>
> Don't be shy, please post a link to Your Library whenever someone is
> interested, so we can learn from the best.
I think you did not catch the name of David's library. It's called "My
Library". So searching for "My Library" and "David Mark" might help.
Matt
David Mark
> On 23 abr, 02:41, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > bother me about it. :)
>
> > See my posts regarding it in the archive. I gave you the name.
>
> interested, so we can learn from the best.
Um, see above.
>
> Better yet if would open-source it so that we can start moving towards
> better reliable cross-browser Javascript all around. I bet it's not
Many are already there (and have been there for years), but you can't
bottle this stuff for general use. You've really got no choice but to
read and learn. :( Javascript is not a Nintendo game.
> that much of a sales hit, is it? You'd benefit much more from the
> attention attracted than you'd ever get any other way. It's already
> listed as open-source/freeware on a lot of google results :)
What are you talking about? For one, it isn't for sale at this time
(disregard the note in the source.) For two, I have long since
renounced the project as a waste of time. And I thought you couldn't
find it. (?)
>
> > I'm not sure what you consider a "major website", but I will concede
> > that many Websites, of all shapes and sizes, are serving XHTML
> > (usually of the transitional and invalid variety) as HTML, pinning all
> > of their cross-browser hopes on error correction. They do this
> > because documents are copied from one hopelessly backwards developer
> > to the next.
>
> So you finally admit that XHTML is only part of the future, "if it
> ever comes". Good. Maybe now you can accept that jQuery is useful for
> today's web, "broken" as it is.
Once again, you have it backwards. The Web is broken (beyond belief)
because of junk like jQuery. Why do you think it "supports" Opera 9,
but not 8? It is a hindrance, not a helper. It can turn the simplest
operation into a nightmare, even if you run an IE-only Intranet. (!)
Meanwhile, real cross-browser scripts keep rolling along, as they have
since the turn of the century.
> It's moving towards being future-proof
> and environment-independent as I see and it will probably reach that
> state, if it does, before Your Library reaches 100 users.
What is moving towards future-proof and environment-independent?
jQuery? They can't even figure out IE6, ten years after it was
released. I'd say it is not moving at all and is hemmed in by its
inherently flawed design anyway.
As for your puerile swipe at my library, I suggest you do your
homework on the project. And why do the "major library" zealots
always want to change the subject? Can't you defend the criticisms
leveled at *your* library? In your case, I suppose that goes without
saying.
>
> > Transitional XHTML was popular around the turn of the century as
> > developers thought it would be more "standard" or "future-proof" to
> > move to XHTML (and strict XHTML was too confining to transition
> > existing tag soup sites.) Ten years later, long after XHTML was
> > declared DOA for the Web, people are using it for new sites and
> > including scripts that could never hope to work with properly served
> > XHTML. In other words, if the XHTML future ever comes, all of their
> > documents will be DOA.
>
> Not really. Pages coded with progressive enhancement will still work,
jQuery does not enable progressive enhancement in any sense. On the
contrary, it makes it virtually impossible.
> and there's quite a bit of valid XHTML 1.0 Strict around. Any average
> professional will write valid XHTML.
Huh? There is not a lot of valid XHTML around and only a rube would
waste time with XHTML at this point (at least on the Web.)
>
> > You indicated earlier that you thought the widespread adoption of
> > jQuery was an indication of its usefulness, as if you couldn't believe
> > the majority of Web developers are incompetent and prone to very bad
> > decisions. Do you feel the same way about the widespread adoption of
> > faux XHTML?
>
> Do you mean that XHTML 1.0 is crap? What would be your suggestion? And
I mean serving XHTML as HTML is stupid.
> it's not a fair comparison, jQuery is completely "valid" javascript
> (whatever that means).
You said it. I don't know what it means either. Must be some
alternate definition of "valid" that means "very sloppy."
> I have never seen it throw an exception without
> user/third-party error being the cause in supported browsers.
Such empirical observations are worthless. And exceptions are just
the most visible way for it to fail (which it does in - for example -
various configurations of IE.)
> Writing
> invalid XHTML is a completely different matter.
Sure is! Won't do anything but display an error when served as XML
(as it should be.) Yet most transitional XHTML documents on the Web
*are* invalid and feature scripts that would never fly in XML parse
mode. Quite the contradiction if you think about it.
>
> Well done, no swearing this time. Here, take a cookie.
Piss off.