On Oct 25, 2009, at 2:36 PM, Alexander Cohen wrote:
On Oct 25, 2009, at 5:23 PM, Maciej Stachowiak wrote:
On Oct 25, 2009, at 2:01 PM, Alexander Cohen wrote:
In the events of a tag, i needed to add checks to see what type of
script was being called. A lot if not all of the time, we will
usually find a "javascript:" in the event code so i can also look
there for my defined scripting language and call into the right
code.
Attribute event listeners do not usually have "javascript:" in
them. Here is an example from Google's home page:
<a href="http://images.google.com/imghp?hl=en&tab=wi";
onclick=gbar.qs(this) class=gb1>Images</a>
Notice that the onclick value doesn't start with javascript:. You
are probably thinking of javascript: URLs in links, like this:
<a href="javascript:callSomething()">
You could invent a new URL scheme that runs your scripting language
instead of JavaScript, but I don't think there is anything you can
do about onclick handlers, unless you're willing to break
compatibility with existing Web content.
You're right. But this does give an opportunity for my scripting
language to get through since executing mine as javascript will
probably result in an error. I can definitely catch that and check
for another language.
I think that would be fragile, especially if polyglot or near-polyglot
programs are possible. Unfortunately, inline event listeners were
never designed with the idea of multiple scripting languages in mind.
Fortunately, you can add event listeners just fine using code in a
<script> element, so you don't lose much by not supporting them for a
new scripting language.
Just by curiosity, would it be bad to do something like this (notice
the "newscriptinglang:" in the onload ):
<a href="http://images.google.com/imghp?hl=en&tab=wi";
onclick=newscriptinglang:gbar.qs(this) class=gb1>Images</a
That onclick handler is a valid JavaScript program,
"newscriptlanglang:" is interpreted as a goto label. Whether there is
Web content out there accidentally doing that, I don't know.
If you really want to come up with something, then I think your best
bet would be to declare the scripting language for event listeners
using an explicit mechanism. One possible way is to define a meta
keyword so you could say <meta name="event-listener-language"
content="application/x-fooscript">. That has the downside of being
global for the whole document, so you would not be able to mix inline
event listeners in both languages. It has the benefit that you won't
misinterpret any existing Web content, but the downside that Web pages
using the new scripting language may fail in mysterious ways (instead
of just not running their scripts).
Regards,
Maceij
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
