Clarifying group scope and objectives

Hello all,

In order to get a handle on things myself - and to help sell the message to
those outside the discussion - I've come up with a tentative list (below)
of concrete things that we might mean when talking about web extensions.
Please discuss with a view to categorizing the items as "yes, this is
exactly what we are about", "might be something we look at in the future"
or "outside of our goals" - or any other labels you might like.

When thinking up this list I used this as my idea of what the groups
objectives are: "To help third-party developers to shape future web
standards by creating working implementations of new ideas, used in the
wild, without requiring native support. To provide the resources, support
and community neccessary for this work. To evangelize this process, and to
advocate for successful implementations to be adopted as web standards. To
lobby standards groups and browser manufacturers to include APIs and
features that make the work possible."

This may or may not match what the group believes its objectives are, and
I'd welcome any corrections.

[Aside: I don't know to what extent it is practical/possible to prollyfill
the things below. While the discussion and initial efforts should be
directed at practical goals, I believe that some of the items match the
long-term goals of the group.]

The examples given are just made up and not likely to be good ideas.

HTML/Markup
* New tags - e.g. <tree>, <node>, <leaf> to represent tree structures
* New attributes - e.g. a "mirror" attribute on an <a> tag giving an
alternative source for the target document
* Changed semantics of existing tags - e.g. re-use the obsolete <font> tag
to describe a font-face to be used in the document
* Changed sematics of existing attributes - e.g. allow "style" tags to be
specified using SASS/Less

ECMAScript
* New APIs - e.g. cryptography, compression, internationalization, etc.
* Extensions - e.g. adding methods to CanvasRenderingContext2D to support
new drawing operations
* Alternatives to existing APIs - e.g. An API for manipulating markup
documents that isn't the DOM API
* New events - e.g. GPSLocationChanged
* New triggers for old events - e.g.

CSS
* New properties - e.g. "animation: url(/sample.anim);" to animate the
element based on an animation defined in an external file.
* New selectors - e.g. a way to match text nodes
* New options for existing rules - e.g. "position: screen;" to place an
item relative to the physical display screen

DOM
* Extending node objects - e.g. being able to use a wrapped <canvas> as an
<img>

CONTENT
* Creating handlers for content types - e.g. "text/coffeescript" or
"audio/mpeg"
* Creating handlers for URIs - e.g. sip: or smtp:


I also have a question about methods. Where it is not possible to implement
a proposal using browser JS APIs or preprocessing, would the group support
the use of e.g. Chrome/Firefox extensions, proxy servers (like a local
nodejs server running on the end users machine) or other such things?

They are clearly not practical for wide end-user adoption but could serve
as proof-of-concepts. Perhaps they could also be used to demonstrate to
browser vendors the usefulness of the missing features that preventing them
being done as prollyfills?

Anyway, thats quite enough of my ideas. What do you guys think about all of
this?

Cheers,
Mat Scales