W3C home > Mailing lists > Public > public-coremob@w3.org > February 2012

Re: Charter [via Core Mobile Web Platform Community Group]

From: Marcos Caceres <w3c@marcosc.com>
Date: Wed, 29 Feb 2012 15:38:15 +0000
To: Robin Berjon <robin@berjon.com>
Cc: Tobie Langel <tobie@fb.com>, public-coremob@w3.org
Message-ID: <F71CF0B951CE4BAF8A117135F831C54A@marcosc.com>



On Wednesday, February 29, 2012 at 2:37 PM, Robin Berjon wrote:

> Hi Marcos,
>  
> thanks for your feedback!
>  
> On Feb 29, 2012, at 12:31 , Marcos Caceres wrote:
> > > The goal of the Core Mobile Web Platform Community Group (CG) is to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern mobile web applications.
> >  
> >  
> > Please drop the word "modern". It applies to all web applications ("modern" is about as meaningful as "native" :) ).  
>  
>  
> I would rather keep stylistic changes to a minimal since that's just busy work — this is not a normative document. This is stylistic, the point being that we're not building atop ISINDEX.
Right, but it sets a bad precedence from the start by using divisive language (modern vs ???… are we "modern" yet?).  
> > > In order to achieve this mission, the CG will bring developers, equipment manufacturers, browser vendors, operators and other relevant members of the industry together to:
> >  
> >  
> > will bring -> brings together  
>  
> Charters are aspirational :) Stylistic.
Given that ~80 people are already on the list, this goal has already been achieved to a degree.   
> > > Agree on core features developers can depend on.
> >  
> > I would add "Research and" to the start of the above. Also, I think it should be defined in terms of "use cases", not features.  
>  
>  
> No, developers may have use cases but they depend on features. Features are what interoperability is built with. And features are what we will be referencing. We can come up with use cases for other groups to create features with, but that's another aspect.

Ok, here is some code I recently had to use (sorry, my email program strips white space :( ):

 var isiPad = navigator.userAgent.match(/iPad/i) !== null;
 var tocWrapper = $('#tocwrapper');  
 if(isiPad && tocWrapper){  
var tocHeight  = tocWrapper.height();  
if(tocHeight > 560){
tocWrapper.css({height: "560px"});
var tocScroll = new iScroll('tocwrapper', {vScrollbar: true});
}else{
tocWrapper.css({height: tocHeight})  
}
  }


What feature did I use? Which working group am I going to complain to?  

There is no "W3C iPad detection" feature, AFAIK :)  

The point is that some things are identified best at features and others as use cases… I needed to detect an iPad because I needed to add touch enabled scrolling, but only for the iPad (and not for Desktop).  

> > > These will be defined by reference to a variety of other specifications from the W3C and other standards bodies.
> >  
> > This seems kinda wrong… the problem, in my experience, is that there are gaps in the standards landscape itself to do certain things *as well as* in the specs.  
>  
> The idea is that where there are gaps and we think it's a problem, we start cutting off pieces from the fingers of the relevant working group members until the situation is addressed.
How is this different than taking the problem directly to the working group responsible? How will this group avoid isolating itself and creating an Us vs Them situation?    
> > > Compile related conformance test suites.
> >  
> >  
> > Compile is confusing… maybe say "create"?  
>  
> I see what you mean but I'm not convinced it's all that confusing. In some cases we may create but in others we'll gather them from other sources. I think compile is correct even if some people think of it as a development operation.
Ok, I see what you mean by compile… maybe "Create and gather".   
> > > The CG will develop a series of specifications which combine core features from web standard specifications by the W3C and other standards bodies. Multiple levels of the specification will be published and each successive level will build on the previous one by adding new features.
> >  
> >  
> > I think it is premature to make the above assumption about how the group will create standards. We should first outline what the problems are, then come up with the most appropriate way to solve those problems.  
>  
> We could also backtrack a little further and agree on whether the URI to a Recommendation identifies the HTML document that contains it or whether it concerns the abstract Platonic Recommendation from a Group itself.
Yes, I agree. We probably should do that. Can you add it to the charter as the first work item? …. ;)
>  
> This is not an academic research group; our goal is to JFDI. We don't have a platform because vendors cherry-pick or don't do some things in the same ways. We define one. Then, since we can't do all at once and things evolve, we do it again.
I'm all for JFDI, but see it from the opposite side: "who the f*** are you to come in here with your demands?" The controlling powers of the HTML/Web Platform make it clear that they won't listen to anyone without a well presented, well researched, set of use cases:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

So sure, JFDI all you want... but do it right and be respectful to the custodians for the platform or this is dead in the water (like Artb pointed out, the elephant in the room is: "how is this different from previous doomed mobile centric efforts?" … the answer could be, we are going to do it "right"… as in follow the WHATWG process when making demands for changes to the platform).  
> > > High-quality, comprehensive and automated test suites are important interoperability drivers. The CG will compile accompanying test suites for each specification it releases.
> >  
> >  
> > How will the CG assess "high-quality"?  
>  
> Using our brains, knowledge, experience, that sort of tool.
I see there are some good QA people already signed up. Perhaps an evaluation of the rings would be in order.   
> > > Chair puts a question.
> > > Chair endeavors to make decisions by consensus but is empowered to make decisions even where there are objections.
> > > Chair has responsibility to ensure that all questions put to the group, all decisions, and all objections are publicly documented.
> > > People who have material new information may request the Chair reopen a question.
> >  
> >  
> >  
> > Editor lacking from the decision policy?  
>  
> As usual, editors can decide everything that the group does not :) That's just anti-bikeshedding common sense.  
WFM.  

--  
Marcos Caceres
Received on Wednesday, 29 February 2012 15:38:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC