Talk:Comparison of layout engines (DOM)
From Wikipedia, the free encyclopedia
 |
This article was nominated for deletion on 31 March 2006. The result of the discussion was No consensus. |
[edit] JavaScriptCore or WebCore
Shouldn't JavaScriptCore be listed instead of WebCore? IIRC, WebKit contains WebCore and JavaScriptCore, the later being used for javascript stuff like DOM.
- DOM is not a subset of JavaScript. They are two different things. --minghong 03:22, 9 August 2005 (UTC)
[edit] Bugs in Trident (resolved)
According to this table Trident supports getAttribute(), but in my experience it does not. Even though it says it do. The following will fail:
if ( elem.getAttribute ) {
// Trident says "yes"
foo = elem.getAttribute('bar')
alert(foo) // Null on MSIE, works with Gecko and Presto
}
--itpastorn 10:24, 10 July 2005 (UTC)
IE's getAttribute returns the corresponding DOM object instead of the string value of the attribute.
For example, given <div onclick="foo()"> and node is a reference to the div element:
node.getAttribute('onclick') is equivalent to node.onclick, which is:
function anonymous() {
foo();
}
It should have returned the string "foo()".
Another example: node.getAttribute('style') should return the style attribute in string form, but instead returns the style object.
The same thing applies to setAttribute.
--202.3.172.129 07:40, 14 July 2005 (UTC)
No one else has had anything to say in this matter and user 202.3.172.129 took upon himself to edit the article. I have corrected the bg-color and with this it seems that this case is closed. Special thanks to 202.3.172.129.
--itpastorn 10:17, 3 August 2005 (UTC)
[edit] Size
Wow, this thing is massive! I don't know wikipedia guidelines for table stuff, but I think it'd be smaller if the table didn't redefine backgrounds, etc. for every element. It also (at least in firefox) is very inconsistent with the border lines... IMacWin95 19:44, 29 June 2006 (UTC)
- I agree. It seems that's why there are templates for other articles of this series. The inconsistencies in Firefox are due to inconsistencies what Browsers do with 'gray' (or 'grey'?) instead of rgb hex values, imho. That could be solved if we set border="0" on the tables or use hex values. Problem is: If hex, which one? I think the CSS article looks great in this respect (it doesn't use templates, though), we should copy the style (so no border). Grey 22:15, 29 June 2006 (UTC)
- Applied templates to the tables, got the size down by around 100K. The article could still definitely benefit from being split into sections on separate pages, though. RainbowCrane 19:20, 2 August 2006 (UTC)
I understand some people balking at the length of this article, but some topics are long and detailed and I think it is better to keep them unified, rather than split up due to general concerns about download speeds, attention spans etc. I salute those who provide this extraordinary level of detail in articles such as this, and the one on the comparison of web browsers. I don't understand why someone would want to delete this article. Robin Whittle 23:49, 1 November 2006 (UTC)
[edit] Style
As you may have noticed, I changed the look of this page. This has the simple reason that some FF user changed the look of the divider lines without changing the look of the general table borders. As noted above in "Size" I suggested to remove the border and that's what I did now (I left all additional styling information in place, though, for easy revertion), because IE/FF/Opera all seem to have different opinions of what "gray" is exactly. I've also added missing divider lines for the other sections (before this, only the "Core (Fundamental)" section had those). I hope the style is decent for all. Well, all except IE users, at least. They don't seem to be able to see the divider lines at all. I have nothing to do with that though: I merely copied the way the other lines were done and changed the look.Grey 23:32, 5 August 2006 (UTC)
Now, let me ask a question: Is there something wrong with my eyes, or is "No" suddenly yellowish instead of red in all articles of the series? I haven't found anything to cause this, so please explain it to me if you can. This isn't browser-related, though, as it shows up the same in IE, FF and Opera and has shown in the past. Weird. Grey 23:32, 5 August 2006 (UTC)
[edit] Interface HTMLScriptElement -> text -> Presto -> Incorrect
Can someone check if it is still "Incorrect" with latest version of Presto (Opera)?
- Yes it is. Even tested with 9.10 (build 8629). Not speaking of the usefulness (this behaviour definitely is useful) it is still not per standard. There is an easy workaround though... just use
firstChild.data. --Grey 04:22, 2 November 2006 (UTC)
[edit] Don't Rv My Edits
This is a gigantic article, so it's going to take me a long to time to clean it up, feel free too help me out, but don't rv my edits, I can't do everything in one eay........100110100 04:08, 13 November 2006 (UTC)
[edit] Error in Interface Attr -> specified
Gecko does not treat this property per spec. See Mozilla bug 199959. --liorean 07:32, 20 January 2007 (UTC)
- Since the bug report is a source, we could change that to "incorrect" and reference the bug report in a footnote, if I am not mistaken. It also says that IE is incorrect, too and that Safari supports this. You can go ahead and do it yourself, or I'll do it for you if it doesn't get done in a few days. --Grey 23:15, 20 January 2007 (UTC)
[edit] DOM CSS properties missing
I just saw that CSS2Properties is pointed to the comparison page for CSS. However, that page doesn't really address the DOM part of it such as that IE uses .styleFloat instead of .cssFloat. --liorean 00:27, 17 April 2007 (UTC)
[edit] IE DOES NOT support DOM 1
While working on a script, I got an error with IE's handling of the HTMLSelectElement's add() method. After looking through this table, I saw other instances where IE did not support DOM 1 attributes, yet it is listed at the top as supporting DOM 1. Please fix this omission. 72.66.125.57 02:33, 26 April 2007 (UTC)
[edit] Fact checking needed for my Webcore additions
I added a bunch of data from http://webkit.org/docs/namespaces.html but I'm not sure if that is data from the latest trunk (I suspect that it is) or if it is from the latest release. Also there is no way to tell based on that what version the features were implemented in. Also I put Yes if the method or property exists in the interface class but that doesn't guarantee that it works.
I also did rowspan instead of individual {{no}} templates if the interface didn't exist at all
I tried figuring it out from the source code of the release versions but that was just way too much work.
-- Gudeldar 17:45, 6 August 2007 (UTC)
[edit] Trident and the "no" answers
I'm asking here first before I change this. However, since I've noticed that Gecko's inconsistencies can be footnoted for bug reports, why can't Trident's "different namings" be documented as well? A couple of examples for "no" where "incorrect" is probably more appropriate:
Interface StyleSheet => DOM2 => ownerNode, Trident's implementation: [1] Trident also, incorrectly, supports Interface CSSStyleSheet [2]
This one is just plain wrong however. Trident does indeed support Interface styleSheetList and returns Interface styleSheet which can be access via Interface DocumentStyle (or document.styleSheets[key] )just like Moz/Gecko. Interface StyleSheet => DOM2 => styleSheets, Trident's implementation: [3]
I came across this when I was developing a dynamic stylesheet wrapper and found this page as a decent source. However, I continue to be forced to reference MSDN for Trident's different naming structure because it simply says "no" here. So is this an "ok" to edit and display correctly?
--MAKevin (talk) 18:29, 27 November 2007 (UTC)
- Feel free to correct any inconsistencies you might notice. I'm also in favor of documenting the incorrect implementations with footnotes. Which of the {{no}} or {{partial}} template is used is not important I think.--Fenring (talk) 19:06, 27 November 2007 (UTC)
- It seems like we're currently missing an explanation of what "incorrect" etc. mean. On this page, a property can only be marked as "yes, partial or incorrect" if it is principally supported by the engine (i.e. non-undefined and in case of a method, callable). If the naming is different then it can only be marked as a "no" but footnotes with alternatives are more than welcome. If you find any such properties for Gecko (or any other engine), feel free to change them to "no" as well, though I cannot see any such case at the moment. --Grey (talk) 13:44, 28 November 2007 (UTC)
