- From: Marcos Caceres <w3c@marcosc.com>
- Date: Thu, 23 Jan 2014 07:57:57 +1000
- To: Jo Rabin <jo@linguafranca.org>
- Cc: "SULLIVAN, BRYAN L" <bs3131@att.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, Web and Mobile IG <public-web-mobile@w3.org>
- Message-ID: <CAAwChxNsAJ2g+uO4iVL-U8dJABZfkD_6oqrxM0PHP4CxbO0J5w@mail.gmail.com>
On Wednesday, January 22, 2014, Jo Rabin <jo@linguafranca.org> wrote: > Coremob didn’t have any profiles, it had a set of use cases derived from > an assessment of the most popular non Web apps and went on to produce a > list of features that were missing from the Web platform to be able to > implement similar apps using Web technology. It was a “competitive > analysis”. It would have been quite a sensible profile, but wasn’t, because > too many of the features required of the Web were not standardised. Things being standardized doesn't matter as much as things being interoperable - as you can't have a standard without interop. However, if you mean that the Web is/was simply missing too much functionality when compared to native apps (and devs really need whatever that missing stuff is to make apps/experiences people want to use), that might make sense. I think we are primarily gathered here to work out the above, fwiw. > > The requirement to be able to write a Web application that has a certain > level of functionality, performance and presentational quality in some > required demographic Sure... > is not currently satisfied at a reasonable cost and to a reasonable > degree of simplicity by the current standardisation approach. Can you please expand on this a bit or give an example? I'm not really getting this bit. What can we do different when standardizing stuff? > My own view is that having profiles would help this. There’s no reason to > suppose that they have to be arbitrary. > > Yes, everything needs to be maintained. Sure. But that evidently rarely happens as things that rely on profiles have a tendency to fail or become rapidly obsoleted (or blindly demand blanket support for things that no one uses). We can try to make a profile as a thought experiment if people like and we can see how it would succeed or fail. We can also drag up some past experiments at doing profiles. However, let's not go crazy with this - we have waaaaay more important things to do than discussing specs about specs. > > On 22 Jan 2014, at 20:33, SULLIVAN, BRYAN L <bs3131@att.com <javascript:;>> > wrote: > > > (Patrick wrote) > > On 22/01/2014 20:00, SULLIVAN, BRYAN L wrote: > >> <bryan> The existence of this IG is a reflection on the need for > >> contextual (e.g. mobile, or TV) focus on use cases, techniques, and > >> technologies that are most relevant in that context. > > > > Is it not possible to discuss use cases, techniques and technologies, > > but without making our own "and this is the level of support we will > > require" statement? We may as well set up an arbitrary scoring system a > > la html5test.com? > > > > <bryan> That is certainly possible, the question is whether it is > adequate. The answer will depend upon your opinion and role in the market. > > > >> We do gain by > >> creating these silly lists, because we are in the real world > >> evaluating devices every day per priorities, and *someone* has to do > >> that. > > > > In what sense? Do you mean "should I bother making my site work in this > > browser, on this device, even though it falls short of CoreMob v.1.3.1 > > which is what our org has set as the lowest expected level of adherence"? > > > > <bryan> Re "should I bother", yes that is one takeaway from an > assessment. For example, if I as a developer for a specific type of app > depend upon HTML5 video, drag & drop, or any other specific feature, I will > decide whether to target a specific browser or set of devices based upon > that support. Once TTWF has established a queryable database of W3C test > results, and the database grows / is populated by the normal processes of > device certification (occurring all the time around the world), developers > will be able to directly assess whether a browser/device meets their needs. > At that point, outside of W3C stakeholders will be able to create test > suite profiles that validate the features that they care about most, and > ignore the rest. Thus the "profile" exercise at that point can become > supplemental to W3C, as it *could* be now, but we have preferred (as with > CoreMob) to engage W3C members directly in that assessment of priorities. > > > >> If it's not W3C, from its view above the contextual fray, then > >> it will be GSMA or some other organization (WAC.next?). These orgs > >> *do* "get" the Web, and continually pressure vendors to extend and > >> solidify it per real-world priorities. > > > > But rather than pressuring to reach a certain arbitrary profile (as in > > "you must support the letter of the standard as it was on this > > particular date") of technologies, should the pressure not be driven by > > use cases and by whatever the latest development of a particular aspect > > of the standard is instead? Unless we plan on keeping the profiles > > continually updated to reflect the very latest developments (and then > > start numbering them, as otherwise a browser that "satisfies" CoreMob > > one day may all of a sudden not satisfy it). > > > > <bryan> Every assessment of priorities will grow stale unless it is > maintained. That's why I earlier said that a "one and done" approach to > CoreMob was inadequate and ultimately unhelpful. Just like the Mobile Web > Best Practices, Mobile Web Applications Best Practices, Mobile OK, and > other earlier work of W3C. It needs to be a living effort, or becomes a > historical anecdote quickly. > > > > P > > -- > > Patrick H. Lauke > > ______________________________________________________________ > > re·dux (adj.): brought back; returned. used postpositively > > [latin : re-, re- + dux, leader; see duke.] > > > > www.splintered.co.uk | www.photographia.co.uk > > http://redux.deviantart.com | http://flickr.com/photos/redux/ > > ______________________________________________________________ > > twitter: @patrick_h_lauke | skype: patrick_h_lauke > > ______________________________________________________________ > > > > >
Received on Wednesday, 22 January 2014 21:58:28 UTC