- From: Niels Leenheer <info@html5test.com>
- Date: Thu, 24 Oct 2013 00:58:05 +0200
- To: Tobie Langel <tobie@w3.org>
- Cc: Ronald Mansveld <ronald@ronaldmansveld.nl>, "<public-webplatform-tests@w3.org>" <public-webplatform-tests@w3.org>
Hi Tobie, This is great! I do have some issues I would like to see incorporated or changed, but overall I think this should work very well. On a quick glance I noticed the following things: 1) It might be nice to be able to store other headers with the UA string for test. This would allow a more accurate identification in the future 2) For browser identification of features I�d like to add a type, so it is possible to quickly see if the result is for mobile, tablet, desktop or other types of devices. 3) For browser identification of features I�d also like to be able to make os and device optional. I�ll have some more time to look at it tomorrow. Cheers, Niels html5test.com On 24 Oct 2013, at 00:14, Tobie Langel <tobie@w3.org> wrote: > Hi, > > Pushed the first (unfinished) draft of a "counter" proposal[1]. I did this for two reasons: > > 1) it's a lot harder to come up with a coherent proposal than to open 25 issues against someone else's, > 2) I was under the impressions that I wasn't able to convey the overall organization I had in mind either through the mailing list or through the bug tracker. > > The goal of this proposal isn't to replace Ronald's but to understand better the different perspectives so we can move towards consensus. > > Right now it focuses mainly on: > > - defining the UA part, > - establishing a distinction between raw data (Test results) and interpreted data (Feature Support), > - removing the url proxying. > > In retrospect, I think that the main issues I have with Ronald's proposal have to do with the excessive (and unnecessary) use of identifiers and the use of test related terminology to describe what is essentially feature support info. > > It is probable that I will end up with a two leveled proposal: > > 1. UA string - test case - spec - test result (raw data) > 2. UA object - Feature Support - Feature (interpreted data) > > Where moving from one level to the other requires either code transformation (UA parsing) or interpretation. > > Comments welcomed. > > --tobie > --- > [1]: http://tobie.github.io/webplatform-browser-compat >
Received on Wednesday, 23 October 2013 22:58:29 UTC