On Tue, Jun 5, 2012 at 12:14 PM, Bertrand Delacretaz <[email protected]> wrote: > My first goal would be to get a browser map, and leave the door open > for linking that to devices when/if that happens. I think we're on the > same wavelength here (though this project's name might not be fully > representative then ;-)
Ok, I think a decent next step for me would be to develop a Google Doc which lists browser features that could be tracked via tests. At this point I feel comfortable with the plumbing of Detector that I think it can be used as an example for other similar libraries. Now I can take a a critical look at what it tracks. This could form the basis of a standard. I'll use the default Modernizr tests as the base but work in r0 of Ringmark [1] and some of the Can I Use tests [2]. I'm sure there's a lot of overlap. I'd love to explicitly track ARIA support too. I think the trick is to a) find a small set of tests that won't bog down a browser and b) identify those tests that make sense to save to a profile on disk. Something like pixel density would be awesome to test & keep on disk but it doesn't track to a UA well. With Ringmark now contributed to the W3C Core Mobile group that might prove to be an interesting way to standardize both features tracked and code used. I should have something to share in two weeks or so. Then interested parties can throw darts at it. By the way, I'm probably making an assumption that tests should be organized into core & per-session like I have w/ Detector [3]. [1] - http://www.rng.io/ [2] - http://tests.caniuse.com/ [3] - https://github.com/dmolsen/Detector/wiki/Detector-Test-Tutorial -- http://dmolsen.com
