Responsive media queries not working

@MagicallyAug 04.2014

Hey,

So I am trying to make my portfolio website responsive for different screen resolutions. I am using media queries but they are not over-riding the native styles. I believe my syntax is correct but I will share it with you guys to see if I have done anything wrong.

[code=html]<link href=”css/responsiveIndex.css” rel=”stylesheet” type=”text/css”/>[/code]

This links to my stylesheet.

I am currently testing for a with a resolution of 1680 x 1050 which has the following media query

[code=html]@media only screen and (min-width : 1680px) { .cont_1_text { font:Helvetica, Sans-serif; font-size: 120px; color: #ffffff; }

.cont_1_text2 { font: Helvetica, Sans-serif; font-size: 50px; color: #ffffff; } }[/code]

All it needs is for the text to be scaled down a bit.
Thanks in advance to who ever can help me fix this issue.

to post a comment

CSS

24 Comments(s) _↴

@deathshadowAug 04.2014 — #1680 is not 1680 friendly -- the width used for calculation there is the available space inside the browser -- so you have to account for browser "chrome" like the window frame and the scrollbar, as well as anything else in the way.

Though you're non-condensed properties, changing font-size without resetting the line-height, massive px metric font sizes and lack of a MEDIA attribute on your CSS link [i](which done right would likely mean NOT having to say "screen only" in your media query)[/i] all raise a number of warning flags about your design.

Much less the vague classes that don't really say what the elements ARE.

@MagicallyauthorAug 04.2014 — #1680 is not 1680 friendly -- the width used for calculation there is the available space inside the browser -- so you have to account for browser "chrome" like the window frame and the scrollbar, as well as anything else in the way.

Though you're non-condensed properties, changing font-size without resetting the line-height, massive px metric font sizes and lack of a MEDIA attribute on your CSS link [i](which done right would likely mean NOT having to say "screen only" in your media query)[/i] all raise a number of warning flags about your design.

Much less the vague classes that don't really say what the elements ARE.[/QUOTE]

So you suggest? It worked perfectly well until I moved the file containing the queries into a new folder in my directory...

@jedaisoulAug 04.2014 — #The idea of responsive design is to accommodate device widths down to, say, 320px wide. And generally with a number of cut-off widths on the way. How is one media query set at 1620px going to achieve that?

@KrunalAug 04.2014 — #you can also use bootstrap js and css to make responsive portfolio.

@deathshadowAug 04.2014 — #So you suggest? It worked perfectly well until I moved the file containing the queries into a new folder in my directory...[/QUOTE]

Good rule of thumb is use 32 to 48px less for your trigger. Pretty much 32 will do the trick as that allows enough for the handful of browsers/OS that still show borders when maximized, (typically 6px each) and a scrollbar (of 16px), with 4px to 'spare'.

So trigger at 1648 instead of 1680.

Though REALLY your triggers shouldn't be in pixels in the first place, particularly that large -- it shows pixel thinking and pixel thinking is broken accessibility. Hence why you should probably be using EM's in there just as the WCAG suggests.

Moving the file probably has nothing to do with it -- before you 'moved' it, was it showing scrollbars? dimes to dollars you had no vertical scrollbar and now you do.

@Strider64Aug 04.2014 — #Here's a good site to convert from pixels to ems : http://pxtoem.com/

@deathshadowAug 04.2014 — #Here's a good site to convert from pixels to ems : http://pxtoem.com/[/QUOTE]
Too bad that relationship -- and therin the site itself -- is 100% grade A farm fresh horse manure.

Sure, some people might have 16px == 1em, but on this laptop it's 20px, on my TV it's set to 32px, on my workstation with the 2560x1440 27" display it's 24px to the EM.

There is no fixed relationship, and treating it as a fixed relationship is outright ignorant nonsense.

Same for PT; on this machine in FF 12pt == 20px, not 16.

Lands sake the fact the relationship is not fixed is [b]WHY[/b] the WCAG says to use EM in the first place! So everything auto-adjusts to user preferences. :p

@MagicallyauthorAug 05.2014 — #The idea of responsive design is to accommodate device widths down to, say, 320px wide. And generally with a number of cut-off widths on the way. How is one media query set at 1620px going to achieve that?[/QUOTE]

Cut off widths meaning? I am very new to responsive design.

@jedaisoulAug 05.2014 — #Cut off widths meaning? I am very new to responsive design.[/QUOTE]
I mean widths at which a different media statement takes over. E.g.:

CSS

<i>
 </i>@media (min-width: 800px) {
 /* settings for windows 800px and wider */
 }
 
 @media (max-width:799px) {
 /* settings for windows 640px to 799px */
 }
 
 @media (max-width:639px) {
 /* settings here for windows up to 639px */
 }
 
 @media (max-device-width:639px) {
 /* settings here for SCREENS up to 639px */
 )

This allows separate settings for:

- Windows 800px and wider.

- Windows 640px to 799px wide.

- Windows up to 639px wide.

- SCREENS up to 639px wide.

Note the difference between "max-width" and "max-device-width".

@deathshadowAug 05.2014 — #@jedaisoul, max-device-width is still window width, that's not what it means. It means don't lie about the width, which is why you'll see this META a lot:

&lt;meta
 name="viewport"
 content="width=device-width; height=device-height; initial-scale=1.0"
 /&gt;

So that mobile browsers don't lie about the browser window area.

You can test that with a max-height media query, you'll find it subtracts the address bar and any other stuff from it, which can at the right height on both Android and iOS result in a layout that constantly jumps between two layouts since when you scroll they typically hide the address bar triggering the query, which makes enough room to un-trigger the query endlessly.

Basically "device-width" is the physical resolution [i]of the window[/i], "width" is the resolution the browser feels like reporting -- which is why a LOT of 480px wide screens will without that meta report "width" as 800px. It's why a lot of 1920px or higher screens (like Apple retina) will lie about "width" and report half their actual resolution -- hence the META above to tell them to "STOP DOING THAT, WE KNOW WHAT WE'RE DOING!"

They do this because most websites are NOT designed for mobile, so they try to mash crappy designs into working... which... doesn't really work.

@deathshadowAug 05.2014 — #Oh, and a real laugh, some mobile browsers when 'lying' about width will try and figure out what the widest fixed element in the layout is, and use that as the "width" reported for media queries and "100%/auto" on top level elements. THAT can drive you nutters if you don't have the meta to tell them to not do that.

@SameershokatAug 06.2014 — #Hi guy,s and really thanks about share with me such a brilliant & fabulous Information, May you have more Excited and delicious idea,s so please share with me more information,s Because i am new user and i don,t have any idea for any thing i sure you know well what i am saying........!

thanks in advance dear,s

regard:Sameer shokat

@deathshadowAug 07.2014 — #Oops, wrong thread. nevermind.

@jedaisoulAug 07.2014 — #@ deathshadow

I quote [url=https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries]MDN[/url]:

device-width

Value: <length>

Media: visual, tactile

Accepts min/max prefixes: yes

Describes the width of the output device (meaning the entire screen or page, rather than just the rendering area, such as the document window).
[/quote]

@deathshadowAug 07.2014 — #Funny since that's not even close to what it does in the wild... at all.

Though that could be like EM being the width of a capitol M (it isn't) or EX being the x-height (it isn't)... What it's SUPPOSED to be, not what it is.

Would be painfully bad if it actually did that -- unless what it does in MEDIA isn't what it does on the viewport meta.

It's implementation issues like this that combined with the legalese makes me think the older the spec gets, the more inconsistencies like this seem to be in it.

@deathshadowAug 07.2014 — #Though, the specification says "rendering surface" -- in programmers parlance that IS the content context of the window. (At least that's how the term is used in the windows API, OpenGL and GTK). I suspect MDN misinterpreted that. (big shock)

I used to think MDN was better than W3Schools -- I'm starting to find a whole slew of glaring / misleading errors and outright crappy code that makes me start to think it's the same dance, just a different tune.

No, that's not a good thing.

It's likely just the specification not lining up with one possible interpretation of a vague "specification" -- which when it's vague, it's not actually a specification.

Which is why when I say "specification" on anything newer than HTML 4.01 Strict, I make air quotes with my fingers. The "What The **** Working Group" and their "living document" / "let's get rid of versioning" idiocy being proof enough of that.

@jedaisoulAug 07.2014 — #@ deathshadow

I agree that "width" and "height" are the [i]available[/i] width and height. Also the meta "width=device-width" and "height=device-height" have the effect you describe. But I do not see the logic of "device-width" meaning "window width" in any circumstance. Device-width is the [i]device[/i] width. Well, that is my understanding.

Also that is my experience of how it works. At least, given the code like:

<i>
 </i>@media (max-width:800px) {
 /* do A */
 }
 @media (max-width:640px) {
 /* do B */
 }
 @media (max-device-width:640px) {
 /* do C */
 }

1. A window 720px wide displayed on a PC screen width 1360px will do A.

2. A window 480px wide displayed on a PC screen width 1360px will do B.

3. A smartphone with screen width of 480px will do C.

What a smartphone/tablet with a (claimed) screen resolution of 800px may vary, but that is the fault of the manufacturer.

@deathshadowAug 10.2014 — #Think of it as a short name for "width in device pixels" instead of "width in fantasy-land scaling pixels that aren't pixels". Width ON the device instead of width OF the device. Amazing what changing one preposition can do for a meaning. The specs AND individual browser makers interpretations of them are rife with that sort of thing. For example see how <b> and <i> have semantic meanings -- it WOULD BE in professional writing, that doesn't mean it MUST BE. You swap the transitive verb...

Which is basically what px is on mobile, most of the time it's a giant lie unless you tell it NOT to lie. Width IN device pixels, width OF the device.

You'll see misinterpretations like that a lot -- especially on sites like MDN. [i]The more I read it, the more I'm souring on it as I read it, read the spec... look at the implementation... uhm, Houston?[/i]

But then everything they've done since HTML 2 has been needlessly wordy, while at the same time every version of HTML and CSS are also needlessly vague; it reeks of loophole ridden legalese, instead of actually being written by people who know what a specification is.

Rule I learned in the '80's -- Never let lawyers, marketers or artists create specifications... that's an Engineer's job... and never let an engineer implement it; that's what people with ACTUAL experience are for.

@jedaisoulAug 10.2014 — #I'm not particularly bothered by what trickery mobile makers get up to. I use the meta statement which is [i]supposed[/i] to make them behave. If they choose to persist in lying, my code will deliver a screen layout suitable for the width they report. Do with it what they will...

I'm more interested in segregating the small-screen devices, which may need a simplified display, from normal PCs and large-screen devices. The above code achieves that.

@deathshadowAug 11.2014 — #I'm more interested in segregating the small-screen devices, which may need a simplified display, from normal PCs and large-screen devices. The above code achieves that.[/QUOTE]
That really is the point - everything else is gravy. Thing is, if everything actually obeyed device width (which is coming) that last "part C" is going to fail or worse, be applied where it shouldn't.

Of course, if you have set that META, they're the same thing, so there's no reason to say device-width in the CSS in the first place.

@jedaisoulAug 12.2014 — #I do not understand your point. I haven't tested the range of browsers, but so far it seems that PC browsers distinguish between "width" and "device-width", which my code makes use of.

If you are right and future PC browsers will treat "width" the same as "device-width", my code will become redundant. But how bad is that? Many sites are littered with obsolete code that is ignored by later versions of the browsers.

@Kevin2Aug 13.2014 — #Never let lawyers, marketers or artists create specifications... that's an Engineer's job... and never let an engineer implement it; that's what people with ACTUAL experience are for.[/QUOTE]

So [B][I]that's[/I][/B] my problem. I'm a musician (trumpet & voice) AND a civil engineer. I'm royally screwed... ?

@w3responsiveAug 13.2014 — #Simply add this code, this code will enable responsive on all devices. <meta name="viewport" content="width=device-width, initial-scale=1">

@jedaisoulAug 15.2014 — #Simply add this code, this code will enable responsive on all devices. <meta name="viewport" content="width=device-width, initial-scale=1">[/QUOTE]
Oh no it doesn't! All that code does is tell mobiles not to lie about their screen dimensions, and to initialize the zoom. So it is a [i]prerequisite[/i] of a responsive display on mobiles, it does not [i]enable[/i] responsiveness on mobiles, let alone all devices.

Also in #CSS _↴

firefox divs with no height CSS block for anchor Classes & ID's; All or Only One?

Success!

Help @Magically spread the word by sharing this article on Twitter...

Tweet This

Responsive media queries not working

24 Comments(s) _↴

Also in #CSS _↴

Success!

Social

Version

Responsive media queries not working

24 Comments(s) ↴

Also in #CSS ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

24 Comments(s) _↴

Also in #CSS _↴