(1) Do you mean <modernizer> in the html text or createElement("modernizer")?
Those are radically different issues.
The first is up to tidy, and out of our hands.
If those tags are simply dropped, they should not be,
and we must submit a bug report to the tidy team.
As for createElement yes we should create some kind of object
for any string that comes in.
Then we'd need a way to scan through those created objects by type.
I don't know how far away we are from this general approach.

(2) Clearly <script> should not run if the type is specified and wrong; just 
like language.

(3) Sad truth is, if firefox runs some code some way then we have to do the 
same.
If it does timeout with one arg then so should we, but what is the delay?
Perhaps 1ms.
Hint: jseng_moz.cpp line 2030, the 2 forces exactly 2 args.
I think. You might have to change it to 0 for vararg then check
arg counts down the line.

(4) I was wondering about a change in the event listener.
Well I don't know if I follow all this
but if you'd like to submit something we'll have a look.

(5) Iframe, still pending, as you say,
maybe start by making the object, as we did for XMLHttpRequest,
then we can tie the writer to a native method that pretty much does what 
innerHTML does.

I even more believe, as you do your research,
that the crazy asynchronous ajax stuff is not most of our problems,
and that would be *really* hard to get right anyways;
that instead it's parts of the dom that just aren't there or aren't implemented 
properly.
Wish we could borrow an entire dom, as we did with js and tidy html,
but then of course that has its own issues.
Not under our control etc.

Karl Dahlke
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to