User talk:GreyWanderer

The ch CSS unit
Sorry about that, the test I made was wrong. Anyway, I can't find the original page I found it on, but after doing some searching I found this, bug #282126. If I read that correctly Firefox does support the ch unit, albeit incorrectly in that it uses the width of "M" instead of "0". Should this be noted somehow in the article?

As for a test case, the following should show the problem (modification of comment #7 of the above bug).  00000000000 01234567890 MMMMMMMMMMM  00000000000 01234567890 MMMMMMMMMMM --Execvator (talk) 01:27, 25 January 2008 (UTC)


 * Great test case! And more importantly, you have a source to base this on. Thanks for being considerate. I didn't want to be rude, either. I'd suggest adding a note-section "Gecko value and unit notes" along the lines of the ones already existing for Presto, WebKit and Trident. Add a note there explaining the bug and linking to the bugzilla-entry. Note that the way the "yes/no/partial/etc." values in this article are defined, this would mark "ch" for Gecko as "buggy". Grey (talk) 20:03, 25 January 2008 (UTC)


 * Ok, done. That will hopefully do. I also added a ref for the calc function in gecko and made some minor adjustments for consistency. Cheers! --Execvator (talk) 23:26, 25 January 2008 (UTC)

buggy, incorrect, useless
Hi, I was reading Talk:Comparison_of_layout_engines_(DOM) and come to the conclusion that we need "a standard" that concretize what is exactly meant by buggy, incorrect, useless. are there differences? should we bring them together? (I think so, i will do this if you haven't anthing against this!) Mabdul (talk) 06:08, 16 April 2008 (UTC)
 * on User:Mabdul is a table with a count of the different types! Mabdul (talk) 06:38, 16 April 2008 (UTC)
 * The "useless" and "almost" ones were introduced by me. I didn't feel like adding it as a category as I saw its use only for this one case. It was to show that although a property is claimed to be "supported" ("Incorrect"-ly), it can be "useless" because of those shortcomings (and "almost" signified it was usable for the most part). I know now that this was probably not the right way to do it, and if you want to do away with those two, I wouldn't mind. It was never meant to be used anywhere else yet. The "non-standard" definitely should be a "no" with a footnote. I'd think that "buggy" and "incorrect" are synonymous, as the former is exclusively used in the CSS article, while the latter is used anywhere else but there. My suggestion is moving everything over to "Incorrect". It is a more "common" word than "buggy", if buggy is a word at all. But I don't know, maybe the editors of the article think differently, since someone changed all uses of "incorrect" in the article to "buggy" at one time. --Grey (talk) 18:04, 16 April 2008 (UTC)


 * I think I will change the information to "incorrect" as you describes, because the differences don't really matter and only confuse the reader... Mabdul (talk) 18:45, 16 April 2008 (UTC)
 * Sorry if it didn't become clear, but "non-standard" is a "no" if the property is not understood on any specified interface. E.g. "opacity" on elements: In CSS and/or DOM it has no effect whatsoever in Trident. I.e. "element { opacity: 0.1 }" and "element.style.opacity = 0.1" have no effect whatsoever. That's why it should be "no". --Grey (talk) 19:38, 20 April 2008 (UTC)


 * jear you're right! i realised that i was wrong after I saw your correction... my mistake sorry Mabdul (talk) 19:46, 20 April 2008 (UTC)
 * Hi Grey. In this perspective, shouldn't "Experimental" (ie prefixed : -webkit, -moz, -o) properties be considered "no" as well ? --Fenring (talk) 17:31, 21 April 2008 (UTC)
 * Good point. I think so. Especially in cases like border-radius where implementations differ wildly from the spec. But as the specs are all subject to change I guess that doesn't mean much. --Grey (talk) 21:03, 21 April 2008 (UTC)
 * On second thought, though... it doesn't hurt leaving them their own category under the "partials", in my opinion. So I don't mind either state of affairs. --Grey (talk) 21:07, 21 April 2008 (UTC)
 * Well, it's just to be consistent. The consequence is always that the official prop is not understood. If you're in favor of the "partial" template to indicate to the reader "yet, there is a way to acheive this, if you tweak your css a bit", then trident's opacity is to be considered "experimental" too, imo. (but I think all these experimentals should be "no"s) --Fenring (talk) 11:09, 22 April 2008 (UTC)
 * Ah, be careful with the -moz stuff etc. when there IS no actual standard yet (I'm thinking -webkit-border-radius and -moz-border-radius-- they not only don't work the same as each other, but since there's really no spec yet, they're almost guaranteed not to work like the spec when it does come out), as opposed to a simple "no" on Gecko and display: inline-block with a note stating there is a similar, though not the same, -moz-inline-block/box... I would not use anything like "partial" for stuff that hasn't reached Recommendation yet. This will require more work on our end since CSS3 etc are being published in modules instead of the whole shebang like 2 and 2.1 217.166.94.1 (talk) 09:53, 8 May 2008 (UTC) (ah, me Gaviidae (talk) 10:02, 8 May 2008 (UTC))
 * So it is decided. It'll be "no" with footnotes. --Grey (talk) 17:15, 8 May 2008 (UTC)

Talk:Comparison of layout engines (Cascading Style Sheets)#Trident version numbers
mabdul 02:11, 15 April 2010 (UTC)