Re: Clarifying group scope and objectives

Responses inline.

On Dec 4, 2012, at 8:02 AM, Mat Scales <mat@wibbly.org.uk> wrote:

> 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."

Very well put. In fact I'd say this needs to be on the prollyfill.org site in some way.

> 
> 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

I'd be interested in this for selfish reasons. I have a project named Peggy.js that is a parser and I've got notes laying around on how to build a visualizer for it to ease development of grammars. This is exactly what I had thought of but ditched because I couldn't find an existing solution.

> * 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

I'd caution any idea that starts with "Change". The standards bodies are generally offended when that effect happens. The normal response is "don't break the web".

> 
> ECMAScript
> * New APIs - e.g. cryptography, compression, internationalization, etc.

Totally interested as this kind of stuff has affected my work life a number of times. However most of this is runtime stuff (except i18n). APIs I think are probably out there somewhere in draft I'd imagine but if not they should be.

> * 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

Sounds interesting - CSS is an easy target and many prollyfills will come for CSS.

> 
> 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?

IMO: Maybe. I was once interested in the idea of downloadable locally runnable web apps. But as soon as "data" is involved the ideas start to diminish.

> 
> 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

Glad to have you on board.

Clint

Received on Tuesday, 4 December 2012 16:08:16 UTC