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

On Feb 29, 2012, at 23:45 , Marcos Caceres wrote:
> On Wednesday, 29 February 2012 at 19:52, Robin Berjon wrote:
>> Don't get me wrong, I very much appreciate your review, and you do bring up some important points later. But we're trying to break the ancient unspeakable curse that makes every spec take five years to ship. So no offence to you but stylistic considerations are not as important as anything else, and can take a back seat while we battle our lovecraftian nemesis that is spec timing.
> I'm sorry, and here I stupidly thought we were trying to put a charter together as a community so we could agree on scope and *specs we might work* on together … as a community (I did not even know we had a proposal for a spec at all, so I didn't sign up for the timing fight?). Or have you guys already decided behind the scenes what you are going to do ahead of everyone else and how you are going to do it?  

Whoa, you seem to really want to interpret what I'm saying in a cabal manner that just isn't there... Is there a point in getting the Web platform sorted five years from now? No there isn't. Hence speed — that's all I'm saying.

> Or perhaps informing and being open with a community and with folks that want to participate is what slows everything down?

No it is not, but a full thread mostly concerned with stylistic points and conspiracy theory is :) Barring substantive concerns with the charter as stated I would kindly suggest we look at proposals for a first platform document and make *that* one be the focus of keen review.

>> Without getting into a discussion of the amount of bad practices going on here,
> I think that is kinda the point - we need to have the discussion (because they form real use cases). I'm willing to pull up my skirt and have everyone inspect my code - but not have my work dismissed as "bad practice going on here": it's an example of how an average developer does something and I'm sure it's no worst than what anyone else is doing (i.e., don't go dismissing stuff because it doesn't meet your ideals about "best practice" … it is what it is… and I'm sure you will be disappointed if you go viewing the source of other sites too).  

I'm not "dismissing" it, I just don't understand the exact problem you're trying to solve. If what you want to do is target one very specific device irrespective of the reason why and for some reason that's not possible I think you should take that up with that device's maker because it is well-acknowledged bad practice to write web code to one specific device.

>> isn't the feature you want just touchscreen-compatible positioning and overflow scrolling?
> 
> No, that doesn't work (specially on the iPad, where overflow-scroll requires a two finger gesture that *feels unnatural* and hence hardly anyone knows about it!). I want to know if you are *right now* accessing the site through an touch enabled device AND are actually touching stuff. That determines how big I make things on the screen, where I put things so you can reach them with your thumb easily and comfortably, and make sure I don't put things under your thumbs so you won't touch them accidentally. So, no, it's not as simple as you describe: the user experience and design of the site can be radically different if I know for sure that you are on "touch only" VS you are coming at this with a mouse and keyboard - plus the iPad may have a very specific way of handling touch-scrolling that may not be the same on other devices (where overflow-scrolling just works with a one finger touch… hence, iScroll.js to save the day on the iPad for me).     

Ok, sure, why not, but I still don't see what that has to do with your initial use case versus feature distinction (still seems to me you want a specific feature, perhaps a media query of sorts) or how the charter would change to accommodate this. If it's just about the feature, we don't have issue tracking set up yet but as soon as we do please file it!

>> Obviously everyone is welcome, but I wouldn't want to make that a prerequisite since a lot of the time it would be busy work for those people unless they're specifically interested in the minutiae of our work. Everyone here is of course encouraged to build up personal relationships in other groups in order to lubricate interactions!
> 
> At some point, we are going to have to take the work over to those groups. Best wine them and dine them and shower them with gifts as early as possible … or is part of strategy to "route around" the W3C WGs and lobby browser makers directly instead? That might also work. I know from previous experience that browser makers try to work very closely with large content providers, such as Facebook to make sure things always run smoothly for users: users blame the browser when stuff breaks, not the websites!       

The "strategy" is whatever works, fast. But I don't see that requiring any manner of routing around.

-- 
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 23:22:30 UTC