User talk:George3

Terminology

  • Gecko rendering modes: Do we say 'Strict mode' as in DOM:document.compatMode or 'Standards compliance mode' as "View Page Info" in Mozilla (Seamonkey 1.8 and Firefox 1.5)?


Since you're tweaking those, please follow the pattern at DOM:element.addEventListener and also fix the link to point to the latest version of the document (and not to a working draft!) --Nickolay 17:06, 19 September 2006 (PDT)

Yes, I noticed the url are inconsistent and old. Will do. --George3 17:31, 19 September 2006 (PDT)
Done. - all spec. links under DOM:form. --George3 19:48, 19 September 2006 (PDT)
Thanks! --Nickolay 01:10, 22 September 2006 (PDT)

DOM reference reorg

Since you've been an active contributor updating the DOM reference, you might be interested in discussion about reorganizing it on dev-mdc (maybe you'll even take on this task ;p ): --Nickolay 01:10, 22 September 2006 (PDT)

Wiki tables

fyi, the HTML tables are preferred over wikitables here on MDC. Not a big deal, just mentioning it so that you don't spend time converting the many other HTML tables we have :) (re ) --Nickolay 21:20, 8 September 2007 (PDT)

Since when do we prefer HTML tables? I never use those. --Sheppy 21:39, 8 September 2007 (PDT)

Since dria. Most tables in the wiki are HTML. Is this no longer the case? --Nickolay 23:38, 8 September 2007 (PDT)
Hm, this is news to me. Most of them I find are wiki tables. I prefer them since they don't clutter things up with as much extra stuff. --Sheppy 07:40, 9 September 2007 (PDT)
Alright. I personally don't like them because I have hard time remembering their syntax :) -- and don't think they're much more readable.
So to sum up, are the wikitables now preferred to HTML ones? --Nickolay 09:49, 9 September 2007 (PDT)
Maybe <s>if there was</s> (edit: it exists) a "table" button in MediaWiki's edit toolbar which output a simple wikitable, more people would be reminded of/get used to the syntax? I happen to find wikitable syntax cleaner (especially since discovering that '!' & '!!' can be used in place of '|class="header"') but whatever you guys decide going forward, I'll happily adopt it for the future. I won't convert any more (Browser Feature Detection is just a "pet" page of mine). Note "Sasa Stefanovic" and the reply on dria's talk page - supports Nickolay's preference. --George3 11:20, 9 September 2007 (PDT)
Whatever sheppy says. We should settle on a preferred style - to avoid people converting the tables back and forth, but allow both kinds of tables. --Nickolay 11:59, 9 September 2007 (PDT)
I'm randomly reading recent changes, but I find the wiki table syntax hideously unreadable. HTML syntax is simple and easy to explain: a table is in a <table>, rows within it are in <tr>, and cells are delimited within rows by <td>. Add a note or two for classes like standard-table (?) and for column- and row-spanning cells and you've basically covered HTML tables completely. Formatting cells and rows is a little more complexity, but if I remember it's not really any better or worse than wiki-formatting said rows or cells is. I strongly disagree with using wiki tables, and any time I have to edit one I will be strongly disinclined to edit it; I'm more likely to edit something else so as not to have to re-grok wiki table syntax. --Waldo 15:16, 11 September 2007 (PDT)
I see your point, HTML tables have semantic reminders in the syntax whereas wikitables don't, but the trade off is that HTML tables end up being more verbose, IMHO. Also, more typing is required because you have to close the all the tags (Ok, I guess you don't have to close all of them, but if you're in the XHTML/XML mindset, instead of old HTML, you feel like you have to - and it's probably recommended. Wiki vs. HTML is like delimited flat file vs. XML. I was definitely frustrated by wikitables not too long ago, especially because the first ones I used were messes of embedding "style" and "width" which complicated understanding single pipe vs. double pipe vs. pipe at start of newline. I wish I could identify the "ah, ha!" moment which switched me over to the fan-of-wikitable camp. Maybe it was once I clearly started remembering what the cross reference was and got sick of closing tags. Also, MDC's old wikitable example was either out of date or just unnecessarily verbose. I've made a simplified version based on what's on meta.wikimedia.org but it seems some examples there omit the first "|-" when there's a table header but I choose to include it because I think it's needed if you add captions ("+") or maybe even explicit classes/styles so it's just safer to always include it. --George3 22:11, 11 September 2007 (PDT)
(Just to beat this topic into the ground, I thought this was an interesting, but not scalable (fixed # of rows), third solution; a template "frontend" for wikitables: Template:Table) --George3 09:20, 14 September 2007 (PDT)

Re: . I think that linking to another reference like this isn't the best solution. What we ought to do, I think, is come up with the list of missing concepts that the reference should document (i.e. NodeList, Node, EventListener, etc.), decide where we want to create pages about those, and create the stubs. Then link to the stubs from the TOC, and add the links to XULPlanet from the stubs. That way we'd have the set of stubs people could fill in, and once we have content on those pages, no additional work will need to be done, since they would be linked from the rest of the reference already.

If we just link to external sites, the wiki magic is less likely to happen, since it's harder to create structure, than it is to fill in stubs.

Also, for Element we probably want to just link to DOM:element for now, since it's arguably more useful than http://www.xulplanet.com/references/...f/Element.html

--Nickolay 11:59, 9 September 2007 (PDT)

(on irc, Nickolay came up with a temporary fix: redlink the properties/objects again and put the XULPlanet links immediately after them)
I don't have an opinion and I am probably not experienced enough with API documentation to move forward with the process you propose anyway and honestly, it's low on my priority list. The element link was fixed as you suggested - a link back to itself. --George3 15:20, 9 September 2007 (PDT)