mjs at apple.com
Sun Oct 25 16:09:46 PDT 2009
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
>>> there for my defined scripting language and call into the right
>> 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>
>> You could invent a new URL scheme that runs your scripting language
>> 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
> 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
"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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev