Re: A bigger group...

Regarding issue number 4. I think having a good parser around is a current
necessity.

However. the principal reason we need to parse CSS is because browser
implementations are allowed to discard unused or unrecognized attributes,
selectors and rules.

While we can build a robust parser and though the effort required to reach
a level were browsers can report complete original-state stylesheet
information is not insignificant, I believe it's a worthwhile endeavor to
work towards a stricter recommendation of what styling information should
be preserved by browsers, regardless on whether it's natively useful to
them.

Not only would this greatly simplify CSS prolyfill implementations, but the
resulting code would also be more efficient.


On Tue, Mar 12, 2013 at 12:17 PM, Brian Kardell <bkardell@gmail.com> wrote:

> Our group has been growing, so I'd like to welcome new members and make
> sure that everyone is aware of what we've been doing and try to encourage
> help...
>
> 1) We would like to collect any examples of prollyfills in the wild.  A
> few are listed in the wiki and some more have been discussed on the list
> itself.  Know of one?  Let us know.
>
> 2) Promote the ideas - if you see something that could be prollyfilled,
> suggest/submit it - mention it in lists, blogs, twitter, etc.
>
> 3) Web-IDL project - in order to get native implementation and have an
> increasingly robust draft, we're going to need to provide Web-IDL.  Web-IDL
> is pretty complicated to get right and it's not the way most of us think
> about things - yet it does provide some important things when we are
> discussing/considering standards.  To this end, we have a project to make
> it easier to work with Web-IDL, generate stubs, etc... A lot of work has
> been done on this, very much of it contributed by Marcos.  There are
> currently 30 open issues and it's not where we want it to be yet.
> https://github.com/extensibleweb/webidl.js Any help on that would be
> awesome.
>
> 4) Collecting ideas about common tools where there are cross-cutting
> problems and gaps in prollyfilling.  For example:  Currently  you have to
> parse CSS in order to prollyfill anything in CSS - seems like one very
> robust parser and definition of a good generic/usable OM would be really
> sensible.  Others?
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>