[Mono-osx] [MonoMac] Adding WebKit DOM interfaces

[Miguel de Icaza]

> OK, here is an updated patch.  I've added some DomCss* classes as well 
> as DomDocument (incomplete), etc.  Interfaces are laid out in webkit.cs 
> by the depth of inheritance, then in (roughly) alphabetical order.

Thanks!

> I've also added WebKit/DomNodeList.cs in which the generated class is 
> extended with indexer and implements IEnumerable<DomNode>, so foreach 
> constructs are possible now on DomNodeLists.

Nice, I'll take a look at it.

> I have very little experience in C# generics, so someone will need to 
> guide me while I'm adding more support for IEnumerable.  Do I need to 
> copy-paste the code replacing the type name or there's a better method 
> using generics and/or inheritance?

We should examine this on a case-by-case basis.

> Also, I need some advice on property naming.  Is it desirable to reduce 
> bloat by converting some names like `DomNode.NodeName' to just 
> `DomNode.Name' or it is better to keep things as-is for transparency? 
> At the opposite side, is it desirable to expand `BgColor' to 
> `BackgroundColor' or better keep the original name too?  Is it OK to 
> provide aliases to support both names--short and long?

I would follow the System.Xml.XmlNode pattern and use "Name" in this
case.   You might also want to add some indexers, like XmlNode does.

As for BgColor vs BackgroundColor, we should follow the Design
Guidelines, so let us use BackgroundColor.

Aliases are a bad idea for three reasons: (a) from a style point of view
it is just bad, it means that we as architects of the binding did not
make up our mind and instead of coming up with a solution, offered two;
(b) the binding would not bubble-up calls if two methods match the same
selector, or the results might be random;   (c) If we do it by "hand" by
wrapping one on the other, the inheritance setup only works with one of
the names, not both. 

Miguel