I am new to forum and mobile development so I hope that you can let me solve my problem.
I have created a website and bought a responsive template. On mobile phones, website looks different than I expected. I aim to fix not for all mobile phones but mostly for samsung and iphones.
With this resolution, it is OK for iphone 5 and samsung galasxy s3/4 but when it comes to 360 * 640 samsung galaxy s5, iphone 6 375* 667, iphone 6plus 414*736, I can not change the position of h1.navbar-brand_main1 a and h1.navbar-brand_main2 a.
I tried to add like above a media query for 360 but it did not work.
Do you have a link to the site in question so we can see what the problem is. If you have created a good RWD (responsive web design) then generally you don’t need to get specific with devices.
Note that you rarely want to move things using relative positioning because that doesn’t move the element at all. It moves the element visually but not physically and the element always occupies the same space in the flow that it did before it was shifted.
If indeed you do need a media query for larger devices then that will need to go before the 320px media query in the html.
@media screen and (max-width:480px){
/* stuff here */
}
@media screen and (max-width:320px){
/* stuff here */
}
Generally though I’m not a fan of preset media queries and media queries should be based on the needs of the design and not at the width that you expect a device to be. Chasing device widths is impossible because there are so many. Just ensure your layout can shrink and grow and you collect all devices automatically.
I’m new myself, so forgive me if I am wrong, but I read somewhere that when your write the media queries like that, a device of 300px will take the values from both of the media queries (unless you want this), and so it should be like this:
/* General stuff here */
@media screen and (min-width:481px)
/* Desktop Laptop Tablet */
{
/* stuff here */
}
@media screen and (min-width:321px) and (max-width:480px)
/* Phablets */
{
/* stuff here */
}
@media screen and (max-width:320px)
/* Phones */
{
/* stuff here */
}
Only rules that cascade downwards of course, which is why you start larger and work smaller when using max-width or the reverse when using min-width.
CSS is a cascading language and its usually best to make use of the cascade to save on duplicating code so you want styles to cascade into your media queries to save on repeating yourself.
No need for mixing in min and max width on the same rule or separating whole chunks of code as most of the time you are simply modifying the existing layout a little each time depending on the breakpoint (which should be based on the design and not really device dependent). Chasing devices is a thing of the past as no one knows how many devices there are these days. Just concentrate on the design and throw in a media query when the design calls for it.
I tend to add media queries under the blocks of code that they refers to so that I have the common code for that element all together rather than hunting through the stylesheet to find a media query for it. It results n a few more media queries than keeping them at the end but makes maintenance much easier. Especially when basing media queries on the design because they almost become element queries as its usually only one element at a time that you need to adjust rather than creating a whole new site at each breakpoint.
That logo is awkwardly coded and uses magic numbers to make thngs more complicated.
I would do it like this.
.logo-box-main {
text-align:center;
}
.navbar-brand_main1, .navbar-brand_main2, .logo-box-main a {
float:none;
display:inline-block;
vertical-align:middle;
margin:20px 0;
}
h1.navbar-brand_main2 a {
position:static;
}
h1.navbar-brand_main1 a {
float:none;
margin:0;
}
a.logo-box-main-a {
margin:20px 100px;
}
@media screen and (max-width:720px) {
a.logo-box-main-a {
margin:20px 50px
}
}
@media screen and (max-width:580px) {
.navbar-brand_main1, .navbar-brand_main2, .logo-box-main a {
display:block;
float:none;
margin:10px auto;
}
}
The above code is over-rides so just add that whole block at the end of the css. Once you are happy with it then you can integrate it properly into the original rules if you want.
That section will now scale up and down nicely in all devices.
I added that code as you suggested at the end of the css. I checked on Samsung Galaxy S3 Mini and on Samsung Galaxy Core Prime. It looked OK. I am not sure how it looks with iphones and ipad but I also checked it against http://quirktools.com/screenfly/ . it seems that on many phones it is badly positioned.
Do you think that it is shown actual views of phones or should I avoid that webpage?
I also add my css link and piece of main page code which gives me trouble. Moreover, I know it is a bit long but I would be grateful if you could assist me how it can be improved.
Not until now; interesting. I was aware of the new tags <article> <section> etc. But did not know the rules had changed for <h1> tags. The way I have been doing it was correct for pre-html5, but this throws up more questions on how I structure headers in future. Not taking this off topic here though.
HTML5 basically is a lot less strict on a lot of things. For me, I’m glad they allow it. I’m glad we get some freedom. It’s up to us as developers to not abuse it.
For a recent page I made, it was a one-page-nav sorta thing. Multiple sections. An h1 per section just made sense there. Being used to HTML4.01, it’s very odd seeing a loose structure…but it’s nice.
If you do any work in aria (screen readers), having those multiple headers just makes everything SO MUCH NICER.
There are currently no known implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers. Therefore the outline algorithm cannot be relied upon to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure.
I take that to mean don’t use multiple h1s.
html5 just complicated the heading structure too much so that most people don’t have a clue and you end up with tag soup again (like the 2 h1s in the op’s post on the same line).
I understand that it might be good to have a structure where an article may have a h1 heading and so you might need more than one. However I think that misses the point that the page you arrive on has a main topic and that should be the h1 and even though the articles contained may all need h1s they are still a sub of the main page.
Just because it makes it more complicated doesn’t mean that it’s still not useful. I use them when I have multiple sectins per page, where each section SHOULD have a header to denote the section.
Unless you have multiple key parts to the page (that makes sense) I do agree that it should probably not be used (as it doesn’t make sense).
All in all, it just gives more flexibility if you understand what you’re doing.
Being “old school” I think of H tags as being similar to outline headings.
Seeing as there is H1 to H6 and that of all the many papers I wrote in college I never went more than 4 deep, it seems 6 levels is more than adequate to express content relationships.
Of course if I was trying to game Google I might want to have “blue widgets” in several H1 tags (but no more than 2-3 % ) so Google would know that “hey! blue widgets are important! Rank me up”
) so Google would know that “hey! blue widgets are important! Rank me up”