Remove maximum-scale=1 for better usability

[jordanlev]

I'm not sure if any of the styles actually rely on this, but I think it would be good to remove maximum-scale=1 from the "viewport" meta tag because that makes it very hard for people with poor vision to read on phones (because they can't zoom in on the text). At the very least, it would be good to put a comment in the html or somewhere in the docs explaining the benefits that leaving it in provides versus the drawbacks of making the site hard to read for people over the age of 40 :)

[deeve007]

Surely if the responsive site is built well, the font size caters for the smaller screens?
And anyone who this is a concern for, they would already be aware of this as every single framework/theme I've seen has this in the header.

[jordanlev]

@deeve007 Sometimes people don't set up the fonts to an appropriate size (or they think it's appropriate but for others it's not). Also, sometimes you want to zoom in on an image or a chart, and this prevents that as well. And I find that actually a lot of people are not aware of the drawbacks of having this in their markup -- especially people who are new to html/css and are learning. Often people use these popular frameworks as examples of how they should do their own code, so I think it's especially important that the code act as a good "role model" for the newbies.

Last but not least... even if all of your assertions are correct, what benefit does having this in there provide? Why even have it in there if it's not serving some sort of purpose? (Maybe there is a purpose which I'm not aware of though?)

[Andersos]

👍 @jordanlev

[deeve007]

I think it's superfluous, and you're asking a "starter" framework to do the decision making for the developer. Most (for better or worse) developers choose to keep that in the head of their site. If it were the other way around, I might agree with you.

And at 47, I have no trouble reading responsive sites on a 4" cellphone screen. ;)

[Andersos]

I'm speaking from personal experience from a workshop with the blind and partially sighted (http://tech.finn.no/2014/11/19/workshop-with-blindfolded-lunch/) and agree with @jordanlev. There is no reason to keep maximum-scale=1.

I don't know if you are aware but there are people around the world that have worse eyesight than you @deeve007

[alexgoldstone]

Might be useful to learn from the experience of others. The HTML5 Boilerplate project discussion regarding this topic can be seen here:

h5bp/html5-boilerplate#37

[danielytics]

@deeve007 I'm 30 and I DO have trouble reading many responsive sites on my phone and rely on zooming.

[caryhartline]

@deeve007 Making decisions for developers is something that is only a problem if the framework is adding something that a developer wants to remove(not the other way around). That is especially the case if the code is large and complicated (which is not the case here).

[deeve007]

Then a badly designed/developed responsive site perhaps?
Anyway, issue's been noted, developer can make his choice. ;)

[dmur]

@deeve007:

anyone who this is a concern for, they would already be aware of this

They're aware that screen zooming is broken. They probably have no clue why.

every single framework/theme I've seen has this in the header

This might be true if you haven't seen very many frameworks, but the status quo is not always correct.

you're asking a "starter" framework to do the decision making for the developer

Defaults matter. Plenty of inexperienced developers/designers will overlook that there's even a decision to be made.

[brandonb927]

I'm all for accessibility, but I'm also of the school of thought that this is a decision that the developer needs to make when making the choice to use Skeleton.

There is also an argument to be had about the ability to have sites/webapps respond and behave like native apps, in that they don't zoom at all.

I think a good stopgap solution, if anything, would be to note the use of maximum-scale as an HTML comment.

[jordanlev]

@brandonb927 I think a lot of people use this framework as a learning tool and a starting point, and won't necessarily question the usage of maximum-scale=1. I think a more sensible default is to keep it accessible, and then a knowledgable developer can add in maximum-scale=1 if they want -- seems to me that erring on the side of accessibility is probably better then erring on the side of "website behave like native app" (which is probably not the primary use case for a CSS framework as simple as Skeleton).

[deeve007]

While I'm of the opposite view - that the majority of developers want their site to behave like a "native app" (ie. avoid having to develop an app in addition to a website).

Someone using a framework of any kind is usually not a "beginner" developer, so I see less need of this as a learning tool than a resource for experienced devs who can make their own choices.

But as I said, I think DHG has the various views now, and can make his own choice as he sees fit.

[dmur]

@brandonb927 and @deeve007:

Discussions about the average skill level of a developer using Skeleton, or whether or not developers need to make the decision on their own, are not relevant to the issue. The issue is about whether or not the default configuration of Skeleton should be changed.

[deeve007]

I disagree. First and foremost this "framework" would have been created by Dave for his own use, but he has been generous enough to release for the use of others.

Anyway, enough said from me, it's his framework.

[dhg]

Hey ya'll - so dug into this a little this morning. I really appreciate everyone chiming in. Originally I dropped it in because I wanted to avoid awkward scaling on reorient of certain devices. I think @peteramckay did a great job of summarizing the benefits and disadvantages of the max-scale meta tag:

"TL;DR benefits of max-scale: Prevents weird resizing of elements when mobile devices change orientation.

TL;DR cons of max-scale: Prevents zooming. Hence it may impair usability for visually impaired users."

Given the pros/cons, I think the right default here is going to be lean toward accessibility and "common browser behavior" rather than "app-like behavior." While many projects might benefit from the tag, I believe the right thing to do is lean on generic browser behavior.

I just merged in fbcd84c.

I really appreciate the healthy debate and am hoping this can continue on the project to keep pushing it forward and making it better for everyone. Serious thanks to everyone involved...it's amazing to see.

This will be included in the next point release shortly (2.0.2)!