Our next update comes from Merlin build 7830, which includes three fixes for problems seen in the Acid2 test. First, we fixed a problem with anonymous table creation. More specifically, if a table existed within an anonymous table row, then the table row was terminated after that table. This partially fixed the problems in row 14 and beyond. Check this test case to see how your browser handles it.
Second, we fixed a problem drawing backgrounds on tables without rows, but with both width and height specified. This change fixed the rest of the problems seen in row 14 and beyond. Check this test case to see how your browser handles it.
Third, we now correctly parse SGML comments in Standards mode. I posted about this previously because at the time we weren't sure we would fix this issue. We decided to give it a go, but we're already seeing problems on several pages. We'll gather additional feedback during alpha and beta releases of Merlin and make a decision whether or not to keep this change before the final release.
Here's the updated rendering with these three fixes:
Note: Comments with a light blue background were made by the site owner.
What has happened with his
What has happened with his eyes?
Jakub, Tim posted screenshot
Jakub, Tim posted screenshot from earlier build than the one posted earlier ;) The eyes were fixed in later builds.
Indeed. There's just one
Indeed. There's just one more updated before we reach that screenshot.
We decided to give it a go,
> We decided to give it a go, but we're already seeing problems on several pages
Could you give me example URLs?
We're still doing some more
We're still doing some more work to avoid these problems. Also, we're not inclined to release a list of sites that we're "incompatible" with. Sorry.
Workarounds
If page X invokes standards mode and Opera has a problem with the comments on that page because of the new correct handling, the first thing to do is to get the page fixed, but when that's not possible or takes too long, we'll need workarounds. (If it significantly messes up the page)
One, we could force quirks mode for all pages with opera6.ini's compat mode setting. This is of course not ideal as it'd affect all pages, plus it'd affect the rendering. It'd really be a job for the much-wished-for server manger so it could be site-specific.
Two, we could use user javascript and document.childNodes for page X. We could recurse through all the nodes and nuke comments. document.childNodes will catch comments anywhere I'm pretty sure and removeChild will work directly on the document object. Whether nuking the comment nodes after the fact would fix comment problems, that'd be for you to investigate.
Three, we could use user javascript to mess up the doctype for page X and cause Opera to go into quirks mode. Thing is, I'm not sure if Opera will let you do that and it will probably throw a security fit. Plus, not sure if changing the doctype after the fact would change Opera's handling. Plus, if it did, it'd affect rendering like #1.
#2 seems like the best workaround (if it'd work) because we could create the js ourselves if needed. However, this workaround seems like it'd be perfect for browser.js for problems sites. You could even get some use out of document.createNodeIterator and the filters I think. :) However, if Opera has trouble parsing the comments, I'm not sure they'll even be available to the DOM so they can be removed.
Another option would be to have an ini option to turn off the new comment handling, but I don't think you want to do that.
Anyway, some things to look into as I'm just guessing.
Anything so Opera can move forward.
I don't know the *proper*
I don't know the *proper* way you'd detect and remove all the comments from a page with javascript, but here's my guess:
http://home.tbbs.net/shadow/html/testcases/remove-comment.html
(view source obviously)
You should be able to throw that script in a user js file, visit one of the problem sites with the current internal builds and see if removing the comments is a sufficient workaround. If not, it was worth the try.
That won't quite do it. Try
That won't quite do it. Try it out at http://www.hixie.ch/tests/evil/acid/002/opera010.html.
Even site-specific problems
Even site-specific problems won't solve this fully. For instance, what if the sites uses different DOCTYPEs? You could be breaking 50% of the pages on the site to fix 50%. Browser.js seems like a better solution, but even then, it's not entirely clear what a good fix is. Maybe some clever person can come up with a user JS that can detect if SGML comments are used on a Standards mode page and present the user with the option to ignore them.
I see now
If Opera properly handles comments, then on problem pages, the content that was *intended* by the author to be displayed will be inside the comment and deleting comments would not help as the content that was *intended* to be displayed still won't be displayed. It'd just be deleted when you delete the comment.
You'd have to examine adjacent comment node values somehow to determine if something was intended or not. Then, you'd have to extract that content and insert it in the proper place, or replace one of the comment nodes with it and you'd do all that only if document.compatMode was CSS1Compat for *specific* URIs like http://site.com/file.html (as opposed to targeting a whole domain, which might break pages that don't need fixing).
Seems more difficult, but I think I could create some comment nodes with the dom to simulate what my Opera would do if it handled comments correctly. Then, I'll try to see if I can come up with any suggestions that make sense. :)
But yes, it'd be awesome if someone clever could come up with something.
edit
> adjacent comment node values
I said 'adjacent' because I assume that when Opera handles comments correctly, it'll split up delimited comments into separate nodes. Firefox currently doesn't do that with http://www.hixie.ch/tests/evil/acid/002/opera010.html and puts it all in one comment node.
So, if it all goes in one comment node, then disregard the adjacent part.
another try
Since Firefox 1.5 beta 1 doesn't fail the comment test, I adapted my removeCommentFrom js so that it purposely makes Firefox fail this comment test.
If Opera ends up properly handling comments and it causes a problem on a page, then browser.js would need to simulate that Opera fails comment handling in certain situations for that page.
I need to create a bunch of comment test cases and test against them to improve upon it. As right now, it probably only works with the one comment test.
Just curious though. Does your build of Opera behave like Firefox with this example?
(The BEFORE_ and _END parts have nothing to do with the comment. They're just to be sure I inserted in the right place.)
We pass Hixie's test and
We pass Hixie's test and show "BEFORE__END" for your test.
Thanks
That must mean the nodeValue for the comment is different compared to Firefox or the comment is split up into different nodes.
Anyway, with my script, you should see what I'm *trying* to do. The function to get the comment nodes should be fine, you just need to fix and improve the comment value parsing part, which should be easier for you than me. (assuming if I'm even remotely on the right track)
Or, you could add a comment.ini
site.com=compat
;-) }:-)
In 9.0TP1, this user js will
In 9.0TP1, this user js will make Opera fail the comment test you showed me.
I now see why my previous attempts didn't work. Firefox keeps the -- delimiters in the comment's nodeValue. Opera does not.
Anyway, that shows that things can work. You all just have to run it through a million test cases and make sure it doesn't break one of them. ;)
If you have a list of sites I can test it on, I'll try to improve it. If not, I leave it to you.
Should we keep the
Should we keep the delimiters as Firefox? I guess we should for compatibility. Do you have a test case showing the difference?
We're actually plumb out of sites that have SGML comment problems. We know there are issues with a certain ad provider's content, but nothing else site-specific. Before 9.0P1 was released, we added error-handling for SGML comments that don't have matching open and close comment delimiters. That seemed to improve things nicely.
Should we keep the delimiters as Firefox?
I don't really see a problem with the way Opera 9.0TP1 does it; besides it not being consistent with Firefox.
However, if I was to make my workaround work in both Firefox in Opera I might have to use 2 different methods because of the inconsistency, but as for real-world situations, I myself haven't seen a problem with the inconsistency *yet*.
I guess it comes down to, "Do we need to know that a comment is delimited and should we be able to split the comment value into its delimited parts?" Having the delimiters in the nodeValue allows us to do that, but do we need to?
I say there are 2 options.
1.) Do as Firefox so we can split() the comment into parts if for some reason we wanted to.
2.) make commentnode.nodeValue stay as it is in 9.0TP1 where each part of the comment is joined and the delimiters are not included. Allow comment nodes to have childNodes when necessary where each childNode's nodeValue would be each delimited part. To see an example of how I think that'd work, see this js example. The TYPE of the childNodes would be some new type like "#comment delimited" or something. You'd want hasChildNodes() to work on the commentNode so you could tell if it was delimited and possibly a separate bool member like isDelimited.
#2 would be pretty neat, but #1 (doing it the Firefox way) allows you to do #2 manually. However for #1, if you don't wan the dilimeters in the nodeValue, you'd have to remove them yourself. The end result of implementing #2 would be ideal, but the ends don't always justify the means.
I guess I'd ask the Mozilla devs if they plan on keeping their nodeValue that way first before trying to be consistent with it.
Righto. I'll pass this
Righto. I'll pass this along to those who know more about DOM than me. ;)
:)