Been looking around a bit lately. This thing looks interesting, in part because it's so light. It may be possible to only load all the jQ stuffz for desktops, and just handle phones with this thingy.
http://css-tricks.com/enquire-js-media-query-callbacks-in-javascript/
http://wickynilliams.github.com/enquire.js/
What would be totally cool is if it could be tweaked to set php conditionals on the basis of media queries. That would be getting in to awesome power territory. ;D
Oh check this for scary. :D
On my current pet guinea pig, just playing around with loading one only mobile css sheet for teh fonez, and a standard sheet for t'others, with an extra sheet only called if the default variant is not set. These are for layout variants, not colour variants.
/me haz done colour variants to death innit
<link rel="stylesheet" media="only screen and (max-width: 900px), only screen and (min--moz-device-pixel-ratio: 1.5) and (max-width: 1140px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (max-width: 1140px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (max-width: 1140px), only screen and (min-device-pixel-ratio: 1.5) and (max-width: 1140px)" type="text/css" href="', $settings['theme_url'], '/style_Mobile.css?116" />
<link rel="stylesheet" media="only screen and (min-width: 901px), only screen and (min--moz-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (min-width: 1141px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (min-device-pixel-ratio: 1.5) and (min-width: 1141px)" type="text/css" href="', $settings['theme_url'], '/style_Standard.css?116" />';
if ((isset($options['theme_layout'])) && ($options['theme_layout'] != 1))
echo '
<link rel="stylesheet" media="only screen and (min-width: 901px), only screen and (min--moz-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (min-width: 1141px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (min-device-pixel-ratio: 1.5) and (min-width: 1141px)" type="text/css" href="', $settings['theme_url'], '/style_' , $settings['theme_layout'] , '.css?116" />';
A nice informative, while basic (and a bit old for the speed of them webz), article on responsive design:
http://www.alistapart.com/articles/responsive-web-design/
/me thinks loadCSSFile needs a param to handle media-like <link> attributes
And maybe loadJavascriptFile too.
/me rather have a sharp stick in the eye that look at those functions again :P
I'm just playing with stuff at the moment to see what works and what doesn't. Media queries are handy, but one problem I've found is that even if you declare a separate (lighter) mobile stylesheet it is still loaded even when it's not being applied, and ditto for the other (non-mobile) stylesheet(s). So the rules will only work on a tiddly screen, but you're carrying the overhead of loading it all the time. Meh n bollux.
Basically, the problem with media queries is there's no way to grab the output of the query and use it more specifically. If the damned things detected a device capability and then presented you with an output that you could do stuff with, that would be total awesomesauce. You could use it to set PHP conditionals and all sorts of tricks. Unfortunately, they don't do that.
This looks like an interesting trick (http://stackoverflow.com/a/10756378), although frankly I'm not particualrly rapt about relying on js for this. However, if it's fast and reliable that's really all that matters. Haven't tried it yet.
Of course, but they can do that (who's they? :D). It's out of the question to load all useless files, with some criteria. Don't worry about it. If we do this, then it will work. (tm)
It's what Emanuele was saying, with loadCSSFile() adapted for media.
Ok, but exactly how are you planning to do the adaption? You lot are notorious for nobbling teh themerz. :D
/me coughs.
We were not planning it. We just found out you wants responsive design.
/me would like to gently point to the topic start date, which Ant seems to have missed. :D Oh wait... he wrote it himself.
Seriously now. Bits of status from my personal perspective: I've been looking a bit into it and for solutions for not supporting browsers. There are tradeoffs. (extra js, timeline). I haven't talked to Brad yet and I don't know anything about his mobile theme. I am not aware that he'd be on the same line of thought with you. To my knowledge, Marcus is a fan of responsive design. I asked Spuds about it Just Now (tm), and I wasn't very successful in saving my butt for it.
I have no "conclusions". Attempted road to "conclusions" from my personal perspective:
I'm willing to do this as long as you folks really want to play with this. I do think it is a better solution for web design. I also suspect (but I don't know) that it might become more understandable and appealing for designers. I just don't know if it is for us now - and that is not up to me, it's up to you.
Ant, are you sure changing structure of files for a new theme is a good thing to do for a reasonable timeline? Does Brad know your intentions? Does your work overlap or duplicate the same thing?
I don't know, please understand that, these are honest questions of someone who doesn't know the work and status of you both. Up to you lot to figure things out and what you need from the core for them.
As for "us lot". I know we're mean. (it's in the definition). But. Show what we have to adapt to (what css files), prove that it works - to convert what we have now, too -, and ignore the loading of all files - we can fix that. And, as far as timelines, interest, willingness, estimations and stuff are concerned (beta in March? O:-)), you'll have to convince SpudsMan yerself - I ain't risking it no more. ;)
;D OK. If Brad is still into finishing his stuff up that's fine. TBH I have barely looked at it. I took a few quick looks over at his test site a while back, but haven't been keeping track. I have NFI how the code behind it works or what stage it is at.
Anyway, like I said, I'm trying stuff out on my test theme. Doesn't necessarily have to be duplicated in the default for this software.
However, allowing people to decide which css files they want to call, and under which circumstances, is generally damned good practice. If you remove that it will be a step backwards. IMO. We've always had it in the past. We should keep it.
What bothers me is that we have that loadCSSFile() thing and we're not really using it. At least this... we could do. Because you load whatever .css you wish, by calling it directly in the template, but with this function you could in theory, have more flexibility... take advantage of something like 'load this for me but only if it's needed'. Or rather... 'load this for me, the version for the browser/OS/whatever I'm on'. ('load' = 'insert link to')
Ok, but TBH I have never looked at this function so have no idea what it does, or what it could be made to do. So the "in theory" flexibility may be cool, but I want to know how it will work in practice.
I just get a bit suspicious whenever you guys start saying "Oh hey we've got this awesome thing in Sources and......................" :D
LOL fair enough.
Just to note, an example.
echo '
<link rel="stylesheet" media="only screen and (max-width: 900px), only screen and (min--moz-device-pixel-ratio: 1.5) and (max-width: 1140px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (max-width: 1140px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (max-width: 1140px), only screen and (min-device-pixel-ratio: 1.5) and (max-width: 1140px)" type="text/css" href="', $settings['theme_url'], '/style_Mobile.css?116" />
<link rel="stylesheet" media="only screen and (min-width: 901px), only screen and (min--moz-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (min-width: 1141px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (min-device-pixel-ratio: 1.5) and (min-width: 1141px)" type="text/css" href="', $settings['theme_url'], '/style_Standard.css?116" />';
// If, instead of these echo '<link rel...', the template is written (lets say, this is just an example idea) as:
loadCSSFile('style_Mobile.css', array(), $context['is_mobile']);
loadCSSFile('style_Standard.css', array(), $context['is_standard']);
// all the rest here
The function could insert the media links. It already sets the bits for the browser cache to 'compose' a link to a css/js file iirc.
I assume we know what to insert and when (and it would be clearly documented for themes). A custom theme wouldn't 'need' to use the function (it can use their own direct links), but it can also make use of it, knowing it offers a couple of defaults like this 'mobile' vs 'standard'.
Once those are set, in the rest the theme can use the wanted @media ... etc.
Yes but on what basis does it make that decision?
Browser detection code.
Bad basis.
I'd think for the decision on which css to send that a browser detection would be adequate, I know its not a capabilities check, etc. but a basic your mobile or your not, and the mobile is limited to devices we are likely to care about (e.g. support with a mobile theme) anyway.
If possible I'd rather check by screen resolution, because that is what determines the layout required. It's also probably more reliable, faster, lighter on processing, and more future-proof.
It's possible through client-side code, javascript, to match screen attributes, and ask for a much more specific stylesheet. I don't know if it's worth it. It has downsides of its own.
I was more thinking something like:
loadCSSFile('style_Mobile.css', array('media' => 'only screen and (max-width: 900px), only screen and (min--moz-device-pixel-ratio: 1.5) and (max-width: 1140px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (max-width: 1140px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (max-width: 1140px), only screen and (min-device-pixel-ratio: 1.5) and (max-width: 1140px)'));
loadCSSFile('style_Standard.css', array('media' => 'only screen and (min-width: 901px), only screen and (min--moz-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (-o-min-device-pixel-ratio: 1.5/1) and (min-width: 1141px), only screen and (-webkit-min-device-pixel-ratio: 1.5) and (min-width: 1141px), only screen and (min-device-pixel-ratio: 1.5) and (min-width: 1141px)'));
Problem is with a media minimization would need to work on two files anyway, it cannot merge the two otherwise it would be useless...
Something like the above is what I was thinking would be good. We should be pretty safe on screen res and pixel ratio. Pitch ratio is unlikely increase over the current Retina displays and that, combined with practical physical size constraints, creates a defined range of sizes that any phones are likely to fit into.
Really we have to detect screen size and pixel ratio if we are going to provide a basis for building decent mobile gui's, because everything that contrains mobile gui's (in terms of presentation) is a result of the screen size.
Current opinion about the site I run:
Norv found this gem: https://twitter.com/cennydd/status/61004881011539968
Which is another point. Some people detest "mobile sites', even for forums. I've seen this sort of comment more than once.
Very true but some sites just don't work on a mobile, SMF isn't very good. Tablet is usable though.
QFTW!
And BTW: how many people are actually using a phone to type a post in a forum?
Yup. SMF 2.0.x default is crap. We will definitely do something better than that.
Lots. You'd be surprised.
I don't post too ofter with the phone, but I do, and I do use it a lot to keep up to date and do any moderation things that need to be done. I use the smf4mobile theme, although I use my own mobile detection stuffz for auto switching to the mobile theme (profile option as well). And I get the jquery mobile stuff from cdn as well, lots of sites are using that so it usually cached away.
http://www.spudsdesign.com/dialogo/index.php?topic=49.msg334#msg334
O:-)
It was just an ebook reader... O:-)
I was going to disable admin on mobile simply because wireless network sare so insceure.
BTW, this is how far I've got with my non-jQuery 1.1.x guinea pig. Works everywhere except for some of the more obscure pages. All the usual thread and PM stuff fits and works. It just uses a ['browser']['is_touchscreen'] detector thingy to switch chunks of markup, along with some css tweaks n stuff.
Oh yeah, it runs full Tiny Portal shiz too. The nutters wanted it all, so that's what they got.
Looks interesting! Much better than the current experience to browse this site on Opera Mini. :D
Yeah I thought I'd it without any jQuery, just because I was only using jQ for some fancy stuff for desktop anyway, so it was easy to do without for little buggers. Might still make some things more compact, but that will depend on who grumbles about what.
To be honest that looks better than any other I've used, including tapatalk nonsense.
Dumb *** at Android have gone and made their use of selects impossible. Can have them working perfectly on desktop but they'll be borked in Android. Beats me why the idiots don't make click on a select option work just like click on a normal link. FFS. This is back to IE6 days.
ETA: Have decided that I'm just going to load jQuery for everyone, and use it to convert the hover drops to click drops on touchscreen. Less code for me to write. Same markup as hover, very little extra css. If anyone doesn't like it, they can complain to Android. :P
Hey looky: this is what I did after I stopped grumbling about Android. ;D
BTW, this thing has been streamlined a bit more over the past month or so. I ended up using a rather nifty trick on it. Being 1.1.x, it uses the same variant changing code that most 1.1.x themes use.
I've never bothered to try and figure out why, but these codes always seem to use something that has both $settings['theme_layout'] and $options['theme_layout'] instead of just one or the other. $options['theme_layout'] is, of course, the one stored in the member's profile. $settings['theme_layout'] is just used in some places in the templates, but $options['theme_layout'] is used a lot in the templates too.
What I've done is replace most instances of $options['theme_layout'] in the templates with $settings['theme_layout']. What this does is allow calling the mobile stylesheet and markup on the basis of $settings['theme_layout'] without altering the $options['theme_layout'] that is set in profile.
This means that I can use the one theme for all, and still have auto detection of mobile (with appropriate content and presentation fed to it) while still keeping the member's preferred layout option when they log in from their regular pooter.
Works like this:
// Any layout set by user?
if (isset($options['theme_layout']))
{
($context['browser']['is_mobile']) ? ($settings['theme_layout'] = 'Mobile') : ($settings['theme_layout'] = $options['theme_layout']);
}
// If not set, or if not allowed to set
if(!isset($options['theme_layout']) || (isset($settings['allow_layout_change']) && $settings['allow_layout_change'] == 'no'))
{
// Defaults.
($context['browser']['is_mobile']) ? ($options['theme_layout'] = 'Mobile') : ($options['theme_layout'] = isset($settings['theme_layout']) ? $settings['theme_layout'] : 'Standard');
$settings['theme_layout'] = $options['theme_layout'];
}
I'm quite chuffed with it. It's more versatile than the 2.0.x/2.1/whatever theme variant system, and actually requires less code to run it, because there's bugger all in Sources apart from the mobile detection in the browser array. All I'm doing is calling the mobile stylesheet instead of the others, and using a few php ($context['browser']['is_mobile']) ? conditionals to drop unnecessary markup/js/etc on mobile, in large chunks with minimal checking.