W3C home > Mailing lists > Public > public-webplatform@w3.org > October 2012

Missing Essentials

From: PhistucK <phistuck@gmail.com>
Date: Sat, 20 Oct 2012 11:44:40 +0200
Message-ID: <CABc02_KyKkDY67pLrOWJLjBf2b6nfxM+Yjrmig0VYxve58kdXA@mail.gmail.com>
To: public-webplatform@w3.org
I am currently going through the various articles, cleaning up content and
creating missing articles and I find a few essential things that are
missing in or from the templates (or missing templates).
This is a partial list. I will keep on posting updates when I find new

I will be glad to help set these up, of course. If this is feasible, any
guidance would be very much appreciated.

1. A template for constructors, with the ability to set a constructor as
'non constructible' (which essentially makes it an interface, rather than a
constructor, but it is still a type), for things like HTMLElement, Window
and other constructors that emit the "Illegal constructor" error message
when, for example, new Window() is entered.
Currently http://docs.webplatform.org/wiki/apis/xhr/objects/XMLHttpRequestis
using a simple text to show the constructor syntax, but there should
a unified template for constructors/interfaces.

2. The ability to specify multiple "Applies to..." values.
This is useful for the "name" property (and others, like "pathname" and
other URL decomposition properties that apply to several
objects/interfaces/classes as well), since it exists on certain HTML
elements (but not all) according to the specifications and you cannot
subclass them to an imaginary element (HTMLElementWithName ;)), because
that would just be... wrong(?).

3. More types in the return value and parameter types.
Basically, anything with the constructor template should be a type.
This arbitrary basic selection box just does not quite cut it.

4. A constructor template for DOM properties, I guess.
Example -
There is the XMLHttpRequest object -
And then there is the XMLHttpRequest Window property -
That type of the property should be XMLHttpRequest and it should be a
The current example shows var xhr = window.XMLHttpRequest, which is not how
you would really use it.
Perhaps the property page should just be removed, I am not sure.

5. Not specifying a "Subclass of" value for dom/ articles, automatically
assumes dom/Element, which is incorrect.
A lof of a dom/ articles do not talk about Element subclasses.

6. The CSSOM property template should automatically get its value(s) from
its CSS property counterpart.
If that does not happen, every value has to be updated twice - once for the
font-weight and once for fontWeight.
I doubt everyone (anyone?) will remember that.

Additional discussions -
7. I created the EventTarget API object -
However, I am pretty sure I created in the wrong place and it might even
not supposed to even exist in the documentation, since it might be just an
implementation detail of some sort (there is no EventTarget under Window
when checking with Google Chrome).
I had to create it (or something along these lines), because a lot (or more
than one, anyway) of interfaces subclass it, like Node, Document, Window.
Any suggestions?

8. Related to 1, 7 - should there be articles for the Document (not
document) and Window (not window) intefaces?
I guess there should be a dom/interfaces (maybe not only DOM ones, though)
sub topic.
HTMLElement, Document, Window and the rest of the interfaces would just go
into it.

Received on Saturday, 20 October 2012 09:45:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:32 UTC