https://bugzilla.wikimedia.org/show_bug.cgi?id=40033
--- Comment #4 from Krinkle <[email protected]> 2012-09-11 16:11:23 UTC --- "target" is basically just a disarmed version of isMobileFriendly (since boolean options are evil by design[1], target = mobile === isMobileFriendly = true). The implementation Trevor describes sounds pretty straight forward and clean, I like it. However until we give it a bit more thought I'm still a bit on the fence with this. Especially with: * dependencies * inline mw.loader.using calls * cross-wiki dependencies * registry of "targets" (freeform? registry? hook?) * not to mention cross-source (cross-wiki) loading and using. There is a big can of worms packed in a grid of pandora boxes being tickled here. We need to step back and really look at the bigger picture here. I haven't spend as much time on mobile as I'd like, but I have observed so far and feel that there is a mind set in mobile right now that is leaning on wanting too specific treatment that when given into as-is we will regret, doesn't scale and is encouraging bad design. A module isn't just a bunch of CSS and visually-related javascript. There is a lot of logic in modules these days. Take modules like 'jquery.byteLength' and 'jquery.colorUtil' for instance. Those need to be registered without anything fancy and available everywhere. And that should be the default for each and every module. If a module is skin-specific then it needs to implement its components skin-specific as well, its that simple. It can choose to provide a fallback for unknown skins or it can decide to only load in known skins. That's all already possible. Some modules would have to be fixed to get a uniform design that is better everywhere or it may need skin- or browser-specific sub components. Note that skin-specific module components are only loaded in the skin needed, this does not bloat output or response size. Call me extreme, but modules that rely on hover (for example) may be shot on sight with questions asked later. That is not acceptable, anywhere. We can completely disregard "mobile" from that (very valid) user interface problem. The few characters in the stylesheet addressing ":hover" are unlikely a problem as the bulk of hover-type interaction is the declarations inside the rule (not the selector). For example the actions menu in MediaWiki can be triggered by hover, and alternatively on focus or click. The styles for this come at no cost because the styles are shared (e.g. x:hover { .. } -> x:hover, x.opened, x:focus { .. }). Even if one could or would optimize on that, I'd say don't (in order to keep related things together for ease of maintenance) and perhaps it can even become significant in the (far, potential) future (e.g. detection where the finger is hovering close over the screen - nothing better than getting new functionality for free when an app is correctly designed in the past). Mobile isn't a single tangible environment, it is a combination of factors (device orientation, screen dimension, user input method, browser software, device component APIs (cam, mic, filesytem, location services, ..)), that define it together. They are factors on their own and different subsets of those apply to other environments as well. We need to make sure we properly cover or drop out for those factors as needed. And an "environment", "target" or "canDoMobile" parameter is imho not the solution for this, not by a long shot. Here's a quick list of factors that we as front-end developers can miss when developing code that ideally would support all of the below. Could lead to covering for cases separately (mouse-mode, touch-mode), or implementing some cases and properly avoiding others (eg. touch-only) or by some universal implementation that works on both (e.g. a simple UI button or logic code like jQuery.Callbacks): Availability and/or convenience of: * a mouse * touch * keyboard (e.g. keyboard shortcuts are impossible or unpleasant on iOS devices, though copy/paste exists native) * audio/video input * location services * device orientation * window orientation & size (most mobile devices only support maximized windows) * device resolution * which version is implemented of the specification of HTML, CSS and/or JS - and bugs they introduced when doing so - in other words any version of any browser ever developed that as of writing does not support the latest standards completely (old IE, old Firefox, old mobile browsers, bugs in newer IE..., bugs in old IE) What I'm getting at is that there are so many things (listed above) we now know about the web and how it is used, that we all have learned to take care of, such as * compatibility with IE6 and other old browsers (feature-detection, polyfill, give up etc.) * usability * accessibility (keyboard access, touch access, mouse access) * semantics (screen readers) * etc. "mobile" does not belong in this list, but the individual factors that apply there do. And just to hypothesize a bit, say we do have a "target: mobile" property we can set. What would that even mean? What mobile devices, browsers and versions? What are the requirements to make it "mobile-able"? Assuming we won't implement a "target" for certain versions of IE or for being "accessibility proof", we shouldn't for "mobile" either. As with all factors, we develop the best we can. And when stuff fails, we patch it to detect the previously unanticipated case and work around it by adding support or changing the code to not get there in those cases. We do so for IE6 and accessibility too. And even at those we're not 100% there. [1] off-topic: * http://www.jroller.com/alexRuiz/entry/boolean_arguments_can_be_evil * http://brixomatic.wordpress.com/2010/02/24/boolean-harmful/ -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
