Re: Clarifying group scope and objectives

On Tue, Dec 4, 2012 at 10: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."
>

Yes, precisely.  I would add to that that the community we want is rich and
competitive - in other words, we want to create a "home" for this kind of
thing where people can find prollyfills, evaluate them, link to similar
ones, fork, cross-pollenate ideas, etc...



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

Yes and yes - though I believe we have pretty good agreement now that these
will be x- prefixed for future/forward compatibility and potentially have
some url binding to their implementation as well.


> * Changed semantics of existing tags - e.g. re-use the obsolete <font> tag
> to describe a font-face to be used in the document
>

I've not considered this before, but my initial opinion on that/my vote
would probably be no.


> * Changed sematics of existing attributes - e.g. allow "style" tags to be
> specified using SASS/Less
>
>
Not  entirely sure what you mean there - you say attributes, but then
mention tags.  If you are suggesting that type might indicate proposed new
types, then I would vote yes - though probably those should exist in an x-
space as well and potentially have the link to their implementation on the
tag as well for the same reasons.



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

Yes to all of the above IMO.


>
> 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
>
>
This is one of the areas that I am personally most excited about as it is
one of the hardest to fill and where we could use this idea almost more
than anywhere else (probably because of the difficulty in filling this area
tends to develop more or less completely within the group and tends to take
a long time).  CSS has numerous "natural extension points" which can be
prefixed: pseudo selectors, properties, functions and @ rules... Beyond
that - I'm not entirely sure.



> DOM
> * Extending node objects - e.g. being able to use a wrapped <canvas> as an
> <img>
>
>
I think so... not entirely sure about the particular example without seeing
a proposal, but in general - DOM, yes.


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

Generally speaking, I think yes.  A better early target IMO would be to
target the component pieces that might make those sorts of prollyfills
easier to develop and standardize aspects of a toolchain -- for example --
coffeescript is a transpiled language and preprocessed, that is an
increasingly common thing that generally involves a similar set of steps --
making it simpler to do those sorts of things would be a bigger win IMO and
easier to sell.


>
>
> 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?
>
>
We haven't discussed that, but I've thought about it in the past...
potentially even for things that _could_ in theory be preprocessed - so I'm
not entirely opposed to it.


> 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?
>
>
I disagree that they are not practical on the whole - many of them actually
are and, interestingly, they tend to only get more practical the wider they
are adopted as js engines get faster and faster and the more people you
have looking at similar problems the easier it is to find efficiencies.


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



-- 
Brian Kardell :: @briankardell :: hitchjs.com