[EMAIL PROTECTED] wrote:
> I wonder what are the advantages of using bytecode compiler and then an
> interpreter for Javascript when you always have to interpreter the
> Javascript source code from the pages.
It's both a design and a speed issue. The design issue is that it's easily
implemented with a bison generated parser:), the speed issue is that it's
faster if you execute code more than once (which happens if you have a
single "onMouseMove" somewhere on a page). There is no speed
penalty due to the compiling really even *if* code is executed only
once (like, for example, <SCRIPT> code)
> >The Document Object Model I'm implementing is closely based on the
> >one of the Microsoft Internet Explorer, because it is much more flexible
> >than that of NS (that's what M$ calls "Dynamic HTML").
>
> I'm not sure if this would make more sense, but how about following the
> actual W3C DOM specification?
That's just a subset of the MSIE one, too.
> Do you plan to support proper keyboard navigation as defined in HTML 4
> spec, ie, honouring ACCESSKEY tag attributes, form LABEL tags and link and
> form fields TABINDEX tag attribute? AFAIK, only IE4+ does this but this is
> very important to make Web pages fully controlable by keyboard.
Hm, good point, I never thought about that before. But it's easily
implemented as the form object are actual MUI objects, and MUI takes care
of such issues.
> Does that mean that Voyager will warn about banners with embedded images
> from other sites than the one of the current page?
Currently, I'm working with a database (for example, *.ad.doubleclick.net),
but this "general rule" is nice as well (although it would, for example,
break yahoo.com)
> Another topic: what about supporting HTTP and FTP resume for downloads?
Erm. This isn't done yet, and I admit that I'm procrastinating it for
some internal reasons.
Olli
--
� Oliver Wagner <[EMAIL PROTECTED]>
� http://www.vapor.com
� finger [EMAIL PROTECTED]
