Menu
Community /Pin to ProfileBookmark
@PeterPan_321Jul 10.2015 — #
I appreciate that, and being new to the responsive design methodology I may be overthinking it. But I swear my post was the result of observations. Here was the problem I saw that made my concerned:
When someone clicks an email button on my site, I'll typically use javascript to open my php based email form in a new window, and often open that window to a fixed size whose width is 640. It just makes for a nice form. Of course the same screen on safari, on an i-phone 4 simply openes up to the full screen size, which I believe is also 640 wide. This is when i realized that a font that looks just fine on a 640 wide window opened on a large desktop screen becomes too small to read on an i-phone with the same pixel width.
Do you see my issue? The @media rules are nice, but since there is no accounting for the size of a pixel, they really don't help you scale as I would like to scale. Can you suggest some other way? Is there a way to detect the actual device? I see the @media rules include a "handheld" parameter, but apparently its deprecated and shouldn't be used.@PeterPan_321Jul 10.2015 — #
I believe you... not only by looking at the limited tools available, but by looking at several modern websites. I understand that you have to reduce content and scale both fonts and graphics for a mobil device, but with desktop screens so dense and large, it bothers me to see a huge page filled with just a few huge circles and headlines. Where is all the newspaper like summaries and links to full pages packed with content? Don't get me started! :-)
But two things I discovered today (like i said I'm now to responsive design!), which seemed to help me do a LOT without even using the @media rules. First, I now have a better understanding of how I can specify font sizes in percentages, and how they work relative to their parents. I didn't even realize I could scale graphics too this way (DUH!!!). And also, I learned that if I create my body style with a font-size specified as a percentage of viewport width, like this...
It now helps everything scale very nicely. I'm sure I'll still need the @media screen rules some, as I'm still finding their behavior (and lak of expected behavior) very confusing. And, I'll definitely need to give up on the idea of one size fits all web pages. But I think with a few tweaks now, I will be able to make a lot of pages a lot more multi-size friendly!
Thanks for listening man, and thanks for all the help.!@PeterPan_321Jul 12.2015 — #Thanks for the continued advise! Let me comment on these items one by one, and I'll understand if I'm starting t be a pest here...
Yes... I wrestle with that somewhat. Having been working on some websites since Netscape 4 (and the same version of IE), I always strove to use universal elements, ignoring a lot of what I felt was "snobby" advise to just move on and forget the old browsers. My feeling was that since my audience was much more "home" user and a much less "corporate" user, and knowing how slow I have always been to upgrade anything (I still have some XP machines here!), I always try to be backward compatible. For that reason, yes... I'm going to need some media queries very soon, and a much better understanding about how fallbacks work (and why they sometimes don't). But in this case, since my main interest here is making some screens more mobile compatible, I'm hoping it is safe to assume that mobile devices are likely to be a bit more current, at least when it comes to newer CSS options. Tell me... is it OK to have two identical properties in the came style, so that the second will only activate if the first fails, like this...
Obviously font family is already capable of falling back. But what about coaxing the font-size like that?
Well what I was getting at is that mobile web surfing was a totally unexpected event in the evolution of some of my early sites which got quite huge. Previously screen resolutions and display area kept increasing, Allowing me to squeeze more and more content on each page. Then suddenly it was like stepping back into the days of 640 x 480 VGA monitors. So forming good compromises is not just a matter of screen formatting anymore... I have to leave out content now, which pretty much infers detecting device capabilities and re-directing to the most ideal page for the device. A huge undertaking, especially for sites that are more artistic and hobby oriented than business, which I've been just adding and adding too for a dozen years (!). But whatever I do, I can see that my task will be easier if I better understand the tools.
You seem to be telling me though that this isn't necessarily the case. You say media rules can...
Well first, go back to my original dilemma, which is that 640 pixels on a Mobil device is way different from 640 pixels on an old fashioned VGA screen. If all I have is constructs like...
That isn't going to help me properly size text at all. I became hopeful because it seems there is a 'resolution' property that can somehow determine the DPI of a screen, so maybe with that I can make some calculations about text sizes that really reflect the actual visual experience, rather than deciding styles based on pixels (which don't really mean anything).
Second, I have to confess that I honestly just don't "get" how media rules work. It seems to me that I've tried some examples based on pages at the W3C schools and others, and so far it seems like my results are the opposite of what I'd expect. Without boring you with some of my failed examples, maybe you can either point me to some GOOD tutorials, or maybe its time to go out and buy and old fashioned "O-Reilly" book with one of those animals on the cover. :-) Seems that there are tons of tutorials, but most leave out very critical information... like (a) if three media rules all turn out "true", which one overrides the rest? is it a case of the last rule overrides the previous, a case of the first rule causing the remaining ones to be ignored (like HTML5 video media formats), or is it (gasp!) browser dependent. I also seem to be having a hard time understanding in a rule like this...
Does this infer that ALL widths 320 and less satisfy the rule? Confusing!@PeterPan_321Jul 13.2015 — #
So I suppose that infers that it would be near impossible to use any deterministic approach to creating a "ruler" app, because you could never guarantee an inch is even remotely near an inch. Not that i want a ruler app, but it does seem odd to me.@PeterPan_321Jul 13.2015 — #
OK good... so I can depend on that, and you say that works for media rules too. So from a top down perspective, each CSS style that is valid is accepted, and overrides any previous ones, except when you use a specific style, as with a "class" attribute on an individual element. Got it, and thanks. Thats what I was hoping for and I'm glad its NOT browser dependent. Because I can test anything except the all important "all browsers and browser versions on all OS and machines/monitors).
I appreciate you letting me know in advance that I'm embarking on a strategy thats probably doomed to fail, or at least not cover all the bases. One thing that was screwing me up here royally was all the mis-information posted on line about the max width of my i-phone4. In so many places I saw it posted as 640. Once I made a test page with some scripting to display the actual viewport width and height (http://pixyland.org/private/resTest.html ) then I could planly see the truth, which is 320 (surprisingly, reloading the page in landscape orientation displays the same width, and only the height changes) . So for that etst I just did this...
and it did just what I wanted... made the text bigger on the small iphone screen. So now I can look on line for a set of media rules to fit most popular sizes, and finally be on my way to creating responsive designs. Thanks again! And i still wouldn't mind any good online references you might pass along! :-)@PeterPan_321Jul 14.2015 — #One thing I'd like to add to my last response... My media rules would not work at all on my i-phone until I added "meta data" lines like the below. This is one of the reasons I'd really like to see a GOOD and COMPLETE tutorial on the subject. How many other smart phones or mobile devices require secret additions like this to make media rules work?
@PeterPan_321Jul 14.2015 — #Thanks again[B][B][COLOR=red] jedaisoul[/COLOR] [/B][/B] , and big OOPS on my use of the "//" comment line!
The only question remaining really, is without the VIEWPORT meta tag, do the @media rules specifying "width" have any predictable meaning at all? And by the way, not that I'm in a position to judge yet, but everything I've read dso far seems to say I should avoid "max-[B]device[/B]-width" in favor of using the browser window, which I guess is just "max-width". When would YOU say one is better than the other?
By the way... new discovery! I don't know how reliable it is, but in Firefox if you view a page after hitting CTRL-SHIFT-M, it seems to let you view the current page as a mobil device would, and it seems to let you select from quite a few devices! If the simulation is even 90% reliable, it will be a BIG help as I retrofit old pages!@PeterPan_321Jul 15.2015 — #By the way, I do like your idea of having specific breakpoints which then generate specific widths. It does help cut down the number of cases to deal with. Of course for what its worth, on implementing this I realized that to support IE8 and below, I had to resort to one of those conditional style sheets, in which I just put in a body width of 95%.
But anyway, there's been the usual necessary hair pulling and late night cursing getting started, but I'm really happy with the way things are going. Thanks again for all the help! @PeterPan_321Jul 18.2015 — #
Question... I didn't pay too much attention to your setting a style for the <html> tag, both because I felt it was very recent (so maybe not so backward compatible), and because I wasn't sure I needed it. But recently I read about the convenient sizing units called 'rems" (ems referenced to the html properties instead of the nearest relative". This seemed like a great idea. Though its also pretty recent, its easy to fall back by preceding it with something more compatible, asi in...
Then it dawned on me... this whole notion you explained about styles being applied or altered in a top down manner no longer makes sense when I think about defining styles for the <html> tag. Since styles, whether linked or embedded or whatever must appear in a page AFTER the <html> tag, how can it ever get applied to the current page?@PeterPan_321Jul 18.2015 — #
One of my problems (or maybe its a good thing ? ) is that what most developers call "not new" still seems WAY new to me in the grand scheme of things. but....
Its not a matter of comfort, but a desire to make use of "rems" instead of just "ems". As I understand it, rems are sized relative to the <html> tag, not an added container. This is why I'm confused... how can you style the html tag, if the styling MUST come AFTER the <html> tag on the page. Isn't styling all "top down"?@PeterPan_321Jul 20.2015 — #My bad... its not styling the html tag that's new, but I think applying "font-size" to it started with CS3. But, maybe I can still rely on "rems" based on the notion that all "root" font-sizes are supposed to be about the same? I'm probably over-thinking this.
Detecting screen size in real world measurements
I have at least one very huge “old school” design website which I’d like to make a little more mobile friendly. By a “little” more, I mean I’m trying to avoid rebuilding everything and having completely separate mobile and desktop sites. Thats probably not even do-able, but I’d like to try. In several experiments I’ve already seen that if I simply change the body font-size % style, a lot of pages could be made fairly universal with just a few tweaks. But two rubs… first, I can’t detect page size until the page has been loaded. I think I can solve that with one dummy “landing” page, which could then make some tweaks in subsequent pages being loaded. But then the bigger question, just what is page size anyway?
What I’m getting at is, pixel size (which I can get through DOM properties) doesn’t mean anything anymore. Mobil devices have gotten so hi-res, the pixel density is comparable to a desktop monitor. What I really need to know, besides pixel size, is how big the screen actually is. If I know its 800 pixels wide, that means nothing. If I know that 800 pixels equals 2.5 inches, NOW I can make some useful calculations. But is there a reliable way (other then a lookup table for every device) to know how big the screen really is? Inches, centimeters, doesn’t matter… as long as its a real measurment, I can use it.
Sign in
to post a comment22 Comments(s) ↴
0
@PeterPan_321Jul 10.2015 — #Hi,
How are you going to know from the physical size of the screen what angular dimension that is at any given time?
I therefore suggest that you simply use responsive design techniques based on a "standard" pixel density viewed from a "standard" distance, and let the smartphone manufacturers worry about how they represent that on their devices! ?[/QUOTE]
I appreciate that, and being new to the responsive design methodology I may be overthinking it. But I swear my post was the result of observations. Here was the problem I saw that made my concerned:
When someone clicks an email button on my site, I'll typically use javascript to open my php based email form in a new window, and often open that window to a fixed size whose width is 640. It just makes for a nice form. Of course the same screen on safari, on an i-phone 4 simply openes up to the full screen size, which I believe is also 640 wide. This is when i realized that a font that looks just fine on a 640 wide window opened on a large desktop screen becomes too small to read on an i-phone with the same pixel width.
Do you see my issue? The @media rules are nice, but since there is no accounting for the size of a pixel, they really don't help you scale as I would like to scale. Can you suggest some other way? Is there a way to detect the actual device? I see the @media rules include a "handheld" parameter, but apparently its deprecated and shouldn't be used.
0
@PeterPan_321Jul 10.2015 — #Well, I do not have an answer, except that designing for each and every mobile device out there has been tried. I think it was called "adaptive design" (or some such). Fact is, it did not work, and never could. E.g. How do you allow for devices that have not been made yet??? The life of the average mobile seems fleetingly short, and you are just making a rod for your own back trying to do the impossible.
On second thoughts, have you tried sizing things in EMs instead of PXs? I dislike the EM but it should re-size better...
Oh, and part of the problem is your use of a fixed width element 640px wide in the first place. How is that ever going to work on a 320x480px screen? It isn't. So don't do it! ?[/QUOTE]
I believe you... not only by looking at the limited tools available, but by looking at several modern websites. I understand that you have to reduce content and scale both fonts and graphics for a mobil device, but with desktop screens so dense and large, it bothers me to see a huge page filled with just a few huge circles and headlines. Where is all the newspaper like summaries and links to full pages packed with content? Don't get me started! :-)
But two things I discovered today (like i said I'm now to responsive design!), which seemed to help me do a LOT without even using the @media rules. First, I now have a better understanding of how I can specify font sizes in percentages, and how they work relative to their parents. I didn't even realize I could scale graphics too this way (DUH!!!). And also, I learned that if I create my body style with a font-size specified as a percentage of viewport width, like this...
[CODE]body {
font-size: 3vw;
font-family : "Comic Sans MS", "ChalkboardSE-Bold", "Times New Roman", Times, serif;
font-weight : bold;
text-align: center;
background-color: #33cc99;
} [/CODE]It now helps everything scale very nicely. I'm sure I'll still need the @media screen rules some, as I'm still finding their behavior (and lak of expected behavior) very confusing. And, I'll definitely need to give up on the idea of one size fits all web pages. But I think with a few tweaks now, I will be able to make a lot of pages a lot more multi-size friendly!
Thanks for listening man, and thanks for all the help.!
0
@PeterPan_321Jul 12.2015 — #Thanks for the continued advise! Let me comment on these items one by one, and I'll understand if I'm starting t be a pest here...Glad to be of assistance, just a few comments:
1. Do you realise that vw units are CSS3 specific and have no fall-back for legacy browsers (including IE8 and below)? Backward compatibility is less important now than it used to be, and minor display discrepancies are acceptable, but I suspect this could lead to major display errors on such browsers.
[/QUOTE]
Yes... I wrestle with that somewhat. Having been working on some websites since Netscape 4 (and the same version of IE), I always strove to use universal elements, ignoring a lot of what I felt was "snobby" advise to just move on and forget the old browsers. My feeling was that since my audience was much more "home" user and a much less "corporate" user, and knowing how slow I have always been to upgrade anything (I still have some XP machines here!), I always try to be backward compatible. For that reason, yes... I'm going to need some media queries very soon, and a much better understanding about how fallbacks work (and why they sometimes don't). But in this case, since my main interest here is making some screens more mobile compatible, I'm hoping it is safe to assume that mobile devices are likely to be a bit more current, at least when it comes to newer CSS options. Tell me... is it OK to have two identical properties in the came style, so that the second will only activate if the first fails, like this...
[CODE] <style>
body {
font-size: 20pt;
font-size: 3vw;
font-family : "Comic Sans MS", "ChalkboardSE-Bold", "Times New Roman", Times, serif;
}
</style>
[/CODE]Obviously font family is already capable of falling back. But what about coaxing the font-size like that?
2. I'm not sure what you mean by [I]"I'll definitely need to give up on the idea of one size fits all web pages"[/I]. I suspect that you are confusing fluid design techniques with responsive ones. Yes, fluid design techniques (even with vw units) cannot make a complex web page fit screens from 320px wide to full HD (and larger). That is what media queries are all about. They enable you to:
[/QUOTE]
Well what I was getting at is that mobile web surfing was a totally unexpected event in the evolution of some of my early sites which got quite huge. Previously screen resolutions and display area kept increasing, Allowing me to squeeze more and more content on each page. Then suddenly it was like stepping back into the days of 640 x 480 VGA monitors. So forming good compromises is not just a matter of screen formatting anymore... I have to leave out content now, which pretty much infers detecting device capabilities and re-directing to the most ideal page for the device. A huge undertaking, especially for sites that are more artistic and hobby oriented than business, which I've been just adding and adding too for a dozen years (!). But whatever I do, I can see that my task will be easier if I better understand the tools.
You seem to be telling me though that this isn't necessarily the case. You say media rules can...
a) Reformat the layout in ways that simple fluid design cannot do.
b) Add, amend and delete content to suit the media.
So full page content (displayable on a large screen) can be reduced to an epitome on small screen devices, without having to develop the web pages separately.
[/QUOTE]
Well first, go back to my original dilemma, which is that 640 pixels on a Mobil device is way different from 640 pixels on an old fashioned VGA screen. If all I have is constructs like...
[CODE]@media screen and (max-width: 640px) { ... }[/CODE]That isn't going to help me properly size text at all. I became hopeful because it seems there is a 'resolution' property that can somehow determine the DPI of a screen, so maybe with that I can make some calculations about text sizes that really reflect the actual visual experience, rather than deciding styles based on pixels (which don't really mean anything).
Second, I have to confess that I honestly just don't "get" how media rules work. It seems to me that I've tried some examples based on pages at the W3C schools and others, and so far it seems like my results are the opposite of what I'd expect. Without boring you with some of my failed examples, maybe you can either point me to some GOOD tutorials, or maybe its time to go out and buy and old fashioned "O-Reilly" book with one of those animals on the cover. :-) Seems that there are tons of tutorials, but most leave out very critical information... like (a) if three media rules all turn out "true", which one overrides the rest? is it a case of the last rule overrides the previous, a case of the first rule causing the remaining ones to be ignored (like HTML5 video media formats), or is it (gasp!) browser dependent. I also seem to be having a hard time understanding in a rule like this...
[CODE] @media screen and (max-width: 320px) { ... }
[/CODE]Does this infer that ALL widths 320 and less satisfy the rule? Confusing!
0
@PeterPan_321Jul 13.2015 — #Pixel dimensions tell you what percentage of the available screen height will be taken usually doesn't know the actual dimensions of the screen, just the number of pixels.Zoom Google map to fit the world, on any screen.Screen size detect physical dimensions of your display in inches. Screen size is computed based on CSS 1" size in pixels and might be inaccurate.Different devices can have a similar screen resolution, yet entirely different physical ....
[/QUOTE]
So I suppose that infers that it would be near impossible to use any deterministic approach to creating a "ruler" app, because you could never guarantee an inch is even remotely near an inch. Not that i want a ruler app, but it does seem odd to me.
0
@PeterPan_321Jul 13.2015 — #
1. Settings are applied top down, with the later ones overriding earlier ones. So in your example, if both font-size settings are understood by the browser, font-size will be set to 3vw.
[/QUOTE]
OK good... so I can depend on that, and you say that works for media rules too. So from a top down perspective, each CSS style that is valid is accepted, and overrides any previous ones, except when you use a specific style, as with a "class" attribute on an individual element. Got it, and thanks. Thats what I was hoping for and I'm glad its NOT browser dependent. Because I can test anything except the all important "all browsers and browser versions on all OS and machines/monitors).
My answer to this remains the same. The actual physical size of the text display is not your concern, for the very good reasons:
1. It is the angular dimension that is key, not the physical size of the text. E.g. Text 2 centimeter high on a screen held 20cm from the eye is the same "size" (to you) as text 4 centimeter high on a screen held 40cm from the eye, which is the same "size" as text 30 centimeter high on a screen 3m from the eye.
2. The size of text that a reader may find comfortable varies (often with age and infirmity).
Since you have no way of knowing how far away the screen is fron any given user's eyes, nor their age or infirmity, any attempt at second-guessing this is futile. Also:
3. Facilities exist in mobiles and PCs to allow the user to scale the text to suit their needs anyway!
4. Knowing the device or window width is useful in that it allows the content to fit the available width, thus minimising (or eliminating) the need for horizontal scrolling whilst reading text etc. I.e. You are trying to use it for the wrong reasons.
[/QUOTE]
I appreciate you letting me know in advance that I'm embarking on a strategy thats probably doomed to fail, or at least not cover all the bases. One thing that was screwing me up here royally was all the mis-information posted on line about the max width of my i-phone4. In so many places I saw it posted as 640. Once I made a test page with some scripting to display the actual viewport width and height (
[CODE]
body {
font-size: 3vw;
font-family : "Comic Sans MS", "ChalkboardSE-Bold", "Times New Roman", Times, serif;
font-weight : bold;
text-align: center;
background-color: #33cc99;
}
@media screen and (max-width: 320px) {
body {
font-size: 200%;
background-color: lightblue; // so I'll know for sure
}
[/CODE] and it did just what I wanted... made the text bigger on the small iphone screen. So now I can look on line for a set of media rules to fit most popular sizes, and finally be on my way to creating responsive designs. Thanks again! And i still wouldn't mind any good online references you might pass along! :-)
0
@PeterPan_321Jul 14.2015 — #One thing I'd like to add to my last response... My media rules would not work at all on my i-phone until I added "meta data" lines like the below. This is one of the reasons I'd really like to see a GOOD and COMPLETE tutorial on the subject. How many other smart phones or mobile devices require secret additions like this to make media rules work?[CODE]
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=1"/>
[/CODE]0
@PeterPan_321Jul 14.2015 — #Thanks againThe only question remaining really, is without the VIEWPORT meta tag, do the @media rules specifying "width" have any predictable meaning at all? And by the way, not that I'm in a position to judge yet, but everything I've read dso far seems to say I should avoid "max-[B]device[/B]-width" in favor of using the browser window, which I guess is just "max-width". When would YOU say one is better than the other?
By the way... new discovery! I don't know how reliable it is, but in Firefox if you view a page after hitting CTRL-SHIFT-M, it seems to let you view the current page as a mobil device would, and it seems to let you select from quite a few devices! If the simulation is even 90% reliable, it will be a BIG help as I retrofit old pages!
0
@PeterPan_321Jul 15.2015 — #But anyway, there's been the usual necessary hair pulling and late night cursing getting started, but I'm really happy with the way things are going. Thanks again for all the help!
0
@PeterPan_321Jul 18.2015 — #... I use roughly the following:
<i>
</i>/* default */
html {
width: 100%;
} <br/>
body {
width: 960px;
margin: 0 auto;
}
/* media queries */
@media screen and (max-width: 960px) {
body {
width: 800px;
}
}
@media screen and (max-width:800px) {
body {
width: 640px;
}
}
@media screen and (max-width: 640px) {
body {
width: 480px;
}
}
@media screen and (max-device-width: 480px) {
body {
/* smartphone */
width:100%
}
.[/QUOTE]
Question... I didn't pay too much attention to your setting a style for the <html> tag, both because I felt it was very recent (so maybe not so backward compatible), and because I wasn't sure I needed it. But recently I read about the convenient sizing units called 'rems" (ems referenced to the html properties instead of the nearest relative". This seemed like a great idea. Though its also pretty recent, its easy to fall back by preceding it with something more compatible, asi in...
[CODE]<style>
p, ul, ol, li {
font-size: 1em;
font-size: .65rem;
}
</style>[/CODE]Then it dawned on me... this whole notion you explained about styles being applied or altered in a top down manner no longer makes sense when I think about defining styles for the <html> tag. Since styles, whether linked or embedded or whatever must appear in a page AFTER the <html> tag, how can it ever get applied to the current page?
0
@PeterPan_321Jul 18.2015 — #Styling the HTML tag is not new. It has, however, been little used for whatever reason. Similarly the ability to set the width of the BODY element to less (or more) than the viewport is often overlooked.
[/QUOTE]
One of my problems (or maybe its a good thing ? ) is that what most developers call "not new" still seems WAY new to me in the grand scheme of things. but....
If you feel more comfortable with it, substitute BODY for HTML, and an ID "container" for BODY. The effect is the same, but it introduces an entirely unnecessary third element to achieve what can be done with HTML and BODY alone!
[/QUOTE]
Its not a matter of comfort, but a desire to make use of "rems" instead of just "ems". As I understand it, rems are sized relative to the <html> tag, not an added container. This is why I'm confused... how can you style the html tag, if the styling MUST come AFTER the <html> tag on the page. Isn't styling all "top down"?
0
@PeterPan_321Jul 20.2015 — #