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 18:01:19 +0000
To: Robin Berjon <robin@berjon.com>
Cc: public-coremob@w3.org
Message-ID: <C0B3AD7B79674845A379AED2163C77FC@marcosc.com>

On Wednesday, February 29, 2012 at 5:06 PM, Robin Berjon wrote:

> On Feb 29, 2012, at 16:38 , Marcos Caceres wrote:
> > On Wednesday, February 29, 2012 at 2:37 PM, Robin Berjon wrote:
> > > 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?).
> I don't think anyone would have noticed if you hadn't brought it up.

Shheesshh… you ask for a review and when you get one…  :(

> > > > 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.
> Still stylistic!

I'm reviewing the style. It's as important as anything else.    
> > > 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).  
> It looks to me like you're using UA detection when you should be using feature detection (I don't know what "iScroll" does).

No, Chrome may support touchEvents, but I want to know if you are "on an iPad". It doesn't help me to know if touchEvents are supported because you may be using a Desktop browser with a mouse and keyboard (hence the experience would suck for you if I gave you the iScroll enabled version).   
> Feature detection is itself a feature. It may be architectural but you can point to a spec and say "this doesn't have feature detection".

The use case is: how do I find out what input/interaction mode the user is using? iPads don't have mouses, so I know 100% they are touching.  
> > > > 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?
> It is taking the problem to the responsible WG. That's what we do when we see a gap. Says so in the charter.

Right, but why not go straight there? What does this group provide us that we currently don't get from the relevant groups. (I'm not being argumentative here: I think there is real value in this group and the community we are forming, so I want us to detail how we are going to rock it!).   
> > How will this group avoid isolating itself and creating an Us vs Them situation?  
> Cf. previous comment about brains, knowledge, experience, etc.
Ok, lets make sure we get the right people from each WG in there… like the Chairs from HTML, CSS, WebApps etc. (I know Artb and Chaals are already on the list!)   
> > > 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
> That might be a problem when we get to Ring 2 or so. For previous rings, certainly for ring 0, I would expect that if you don't understand why developers need a given feature then you've never written a web app that works on a mobile device :)
I don't know anything about the rings things yet, sorry.   
> Either way, right now we don't have demands. JFDI dictates that we cross that bridge when we get there. Right now the first order of business is setting up the work-mode rules and pushing a Ring 0 document out. Problems will be dealt with as they happen.

Ok, obviously there have been discussions behind the scenes about pushing out rings or whatever… for those of us not in the know, can you articulate what you are about to JF-Do? What is this Ring 0 document? It was not in the charter and I've not seen anything on the mailing list?… bah, I never get the memo :(   
> > 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).  
> This effort isn't mobile-centric, it is simply scoped to mobile.
heh :)    
> As in solving the problems that developers have in a mobile context. It's simpler than solving all the problems that developers have, and naturally the mobile world has its specificities.

I agree. I've not done much mobile development - but what little I've done did encounter "challanges" and I'm keen to share those given the opportunity.    
> As the charter says in its very first sentence we want "a compelling platform for the *development* of modern mobile web applications". So if it's not a problem that developers have, I don't think we're interested. Conversely, if it's a problem that developers have the custodians of the platform will be interested. QED.
> There is no elephant in the room. This is a project of web hackers for web hackers by web hackers. Our mode of failure is very different from that of traditional mobile industry boondoggles ;)
Ok, I hope so… but I do see a lot of ex-[Favorite Failed Mobile Industry Initiatives] participants on the CG participant list (I include myself here!). So it's natural that people will ask "not this, again?! (face-palm!)". Hope we can do it differently and learnt from previous mistakes.  

So, lets JFDI already! :)  
Received on Wednesday, 29 February 2012 18:02:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:44 UTC