- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 29 Feb 2012 18:06:13 +0100
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: public-coremob@w3.org
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. >>> 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! >> 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). 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". >>> 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. > How will this group avoid isolating itself and creating an Us vs Them situation? Cf. previous comment about brains, knowledge, experience, etc. >> 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? …. ;) Knock yourself out! :) http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html >> 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 :) 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. > 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. 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. 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 ;) -- Robin Berjon - http://berjon.com/ - @robinberjon Coming up soon: I'm teaching a W3C online course on Mobile Web Apps http://www.w3devcampus.com/writing-great-web-applications-for-mobile/
Received on Wednesday, 29 February 2012 17:06:54 UTC