Hi Yogi - Jumped back in to say I downloaded 22 examples of responsive HTML5 templates.
All 22 of them used javascript. So far i have not found a single one that works without javascript.
I did find one thing of interest, but don't know if they did so by using javascript.
Somehow they are adding the page you want to visit directly to the Landing Page, so you never actually leave the Landing Page itself. I think it is done sorta like how you add a live google map in a window on the landing page.
I know you cannot have a database without having the proper type of server which allows it.
But it looks like they are somehow using a Form for entering data which is sent via e-mail, I think.
My existing website only opens whatever e-mail program the user has installed, except most now use webmail so I don't know if it works for them, or for those on toy computers.
The more I look into this, the more complex it is becoming.
I think it is ironic they use the term Mobile Friendly. There is nothing Friendly about the way mobile operates.
It's like trying to use a VW Beetle instead of a Moving Van. They are not designed for the stuff people are trying to do on them. Can you imagine trying to read War & Peace on a 1-3/8 inch wide screen? Or watching a movie like Ben Hur?
Not picking on you. I think I'll stay the course of just converting my XHTML to HTML5 first, and then see what is missing to make it viewable on Mobile. From what I've seen so far, they just make one long page so things normally beside each other on a real computer, are end to end on a mobile device. Like if you have five blocks side by side on a real computer, they are stacked up like blocks on a tiny screen. Seems a pain to read anything doing this. But then so is typing on a micro-miniature keyboard. I would love to see someone who can type 120 wpm on a flip-fone, hi hi...
Only question I have, other than calls to a server for data storage, is JS part of HTML5 so you can use some of it, like JQuery as if it were HTML?
TTUL
Gary
Mobile Friendly
Re: Mobile Friendly
I spoke too soon, just got this back from Comcast
"Anything that is processed on the client side can be used, for example: javascript, java applets, flash (without any server-side scripting), etc. What will not work is anything processed on the server, for example: CGI, PHP, Database, java servlets, perl, etc."
So it looks like I can use those JQuery. Also, if I understood a previous response from them, it is possible to use forms if they write to an existing client side html page. It uses the 'guest register' feature, but it doesn't have to be an actual guest register, that is just the name of the feature. It could be used for a wedding present list or who is bringing what to the picnic.
I just never looked into ways to use it.
So I guess now I'm going to have to learn to use JS whether I want to or not. Apparently it is the only way to select which mobile device someone is on.
As far as htaccess, I still have not heard back on whether there is a client side version for users web space.
TTUL
Gary
"Anything that is processed on the client side can be used, for example: javascript, java applets, flash (without any server-side scripting), etc. What will not work is anything processed on the server, for example: CGI, PHP, Database, java servlets, perl, etc."
So it looks like I can use those JQuery. Also, if I understood a previous response from them, it is possible to use forms if they write to an existing client side html page. It uses the 'guest register' feature, but it doesn't have to be an actual guest register, that is just the name of the feature. It could be used for a wedding present list or who is bringing what to the picnic.
I just never looked into ways to use it.
So I guess now I'm going to have to learn to use JS whether I want to or not. Apparently it is the only way to select which mobile device someone is on.
As far as htaccess, I still have not heard back on whether there is a client side version for users web space.
TTUL
Gary
Re: Mobile Friendly
Gary
I'm a little pressed for time myself today and I'll comment on your other concerns as soon as I can. For now the most urgent problem seems to have a simple solution.
I put the style in the header but it can just as well be placed in a style sheet. You can't put it inline with HTML5. It doesn't want to see the <style> tag mixed in with the body HTML.
The bit of information you seem to be missing is how to use the CSS line-height Property The example has an unformatted list on top followed by a nested list with small line spacing surrounding large spacing (complete with CSS created boxes). My code does not have the closing slash required by XHTML, but as you pointed out it's not needed in HTML5 anyway. If it makes the coding clearer to you, put it in.
I'm a little pressed for time myself today and I'll comment on your other concerns as soon as I can. For now the most urgent problem seems to have a simple solution.
I put the style in the header but it can just as well be placed in a style sheet. You can't put it inline with HTML5. It doesn't want to see the <style> tag mixed in with the body HTML.
The bit of information you seem to be missing is how to use the CSS line-height Property The example has an unformatted list on top followed by a nested list with small line spacing surrounding large spacing (complete with CSS created boxes). My code does not have the closing slash required by XHTML, but as you pointed out it's not needed in HTML5 anyway. If it makes the coding clearer to you, put it in.
Code: Select all
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="Generator" content="EditPlus®">
<title>Line Height Example</title>
<style>
ul.shortLH {
line-height: 10px;
}
ul.tallLH {
line-height: 30px;
}
ul.tallLH li{
background: red;
width: 100px;
border: solid 2px black
}
</style>
</head>
<body>
<ul>
<li>Normal Item one
<li>Normal Item two
<li>Normal Item three
</ul>
<ul class="shortLH">
<li>short Item one
<li>short Item two
<li>short Item three
<ul class="tallLH">
<li>Big one
<li>Big two
<li>Big three
</ul>
<li>short Item four
<li>short Item five
<li>short Item six
</ul>
</body>
</html>
Last edited by yogi on 08 Apr 2015, 18:16, edited 3 times in total.
Re: Mobile Friendly
By the way, you can force a line feed in an unstructured list if you use two or more <br> tags to do it. The CSS method is much cleaner and preferred however.
Code: Select all
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="Generator" content="EditPlus®">
<title>Line Height Example</title>
<style>
ul.shortLH {
line-height: 10px;
}
ul.tallLH {
line-height: 30px;
}
</style>
</head>
<body>
<ul>
<li>Normal Item one
<li>Normal Item two
<li>Normal Item three
</ul>
<ul class="shortLH">
<li>short Item one
<li>short Item two
<li>short Item three
<ul class="tallLH">
<li>Big one
<li>Big two
<li>Big three
</ul>
<li>short Item four<br><br>
<li>short Item five<br><br>
<li>short Item six
</ul>
</body>
</html>
Re: Mobile Friendly
Check out this web page: http://www.asus.com/Motherboards/MAXIMUS_VII_RANGER/
It's interesting not only because it's the next motherboard I will be buying, but it gives you some idea of what a mobile friendly web page looks like. It's just as friendly on a desktop as it is on a smart phone. I don't know if you can fit your entire web site into that kind of format, but it's something to keep in mind as an alternative to your current approach.
Now look at this here: http://www.dynamicdrive.com/style/
and here: http://www.dynamicdrive.com/
The three column template has a header, three columns of content, and a footer. Given what I've seen of your personal site, that one might be of most interest to you. It's fluid and collapsible so that it has quite a few elements to make it mobile friendly. Be assured that using templates will save you some coding time, but it's not a simple copy and paste scenario. You will need to massage the code to get exactly what you want, but at least yo won't have to come up with ideas from out of the blue.
It's interesting not only because it's the next motherboard I will be buying, but it gives you some idea of what a mobile friendly web page looks like. It's just as friendly on a desktop as it is on a smart phone. I don't know if you can fit your entire web site into that kind of format, but it's something to keep in mind as an alternative to your current approach.
Now look at this here: http://www.dynamicdrive.com/style/
and here: http://www.dynamicdrive.com/
The three column template has a header, three columns of content, and a footer. Given what I've seen of your personal site, that one might be of most interest to you. It's fluid and collapsible so that it has quite a few elements to make it mobile friendly. Be assured that using templates will save you some coding time, but it's not a simple copy and paste scenario. You will need to massage the code to get exactly what you want, but at least yo won't have to come up with ideas from out of the blue.
Re: Mobile Friendly
Hi Yogi
You don't have to respond to the rest of my drivel. I'm picking up a little bit more with each website and/or template I study.
Thank you very much, I copied the coding samples. I will experiment with them.
By the way, you cannot use </ br> in an ordered or unordered list in XHTML STRICT, not allowed. I tried that first, hi hi...
WOW, that is some motherboard. I'll bet it costs a pretty penny too!
Thank you for the links to Dynamic Drive, I checked and bookmarked them to study later, after I get off work.
Although I do need to rewrite my entire website to make it Mobile Friendly, going through the XHTML and converting to HTML5, with intent of Mobile Friendly later, is actually helping me. I have several images which needed to be resized to the display sizes, and then compacted. Although some of my images were already more compact than the compacted versions, so I used mine instead. I may have compacted them already when I redid the html4 to XHTML?
I do have some coding on my pages which will not work at all with Mobile. Something I did to control page lengths to get around a bug in XHTML, would prevent a mobile device from scrolling after the sections align vertically.
I think perhaps my personal site is a bit complicated, due to the number of categories and separate html pages. Over 45 separate html pages, not counting the 7 index pages. This would be almost too much for a mobile device to weed through. But then too, I've seen several 150 page plus or minus catalogs on-line also, which look great on cell phones, but they are written in PHP which generates the HTML pages as needed.
After inundating you with all of my other blabbering nonsense, I will keep this one short, and won't bother you again unless I have a question I could not figure out in my ongoing research into Mobile Friendly.
Depreciated codes from XHTML to HTML5 did not cause me a problem as they had an alternate code which did the same thing. Like <tt> is now just <kbd>, or at least it worked for now using local HTML test. On-line live might pose a different set of errors, hi hi...
OK, no more eye bending. Have a great day Yogi, and THANKS for all the help and links!
TTUL
Gary
You don't have to respond to the rest of my drivel. I'm picking up a little bit more with each website and/or template I study.
Thank you very much, I copied the coding samples. I will experiment with them.
By the way, you cannot use </ br> in an ordered or unordered list in XHTML STRICT, not allowed. I tried that first, hi hi...
WOW, that is some motherboard. I'll bet it costs a pretty penny too!
Thank you for the links to Dynamic Drive, I checked and bookmarked them to study later, after I get off work.
Although I do need to rewrite my entire website to make it Mobile Friendly, going through the XHTML and converting to HTML5, with intent of Mobile Friendly later, is actually helping me. I have several images which needed to be resized to the display sizes, and then compacted. Although some of my images were already more compact than the compacted versions, so I used mine instead. I may have compacted them already when I redid the html4 to XHTML?
I do have some coding on my pages which will not work at all with Mobile. Something I did to control page lengths to get around a bug in XHTML, would prevent a mobile device from scrolling after the sections align vertically.
I think perhaps my personal site is a bit complicated, due to the number of categories and separate html pages. Over 45 separate html pages, not counting the 7 index pages. This would be almost too much for a mobile device to weed through. But then too, I've seen several 150 page plus or minus catalogs on-line also, which look great on cell phones, but they are written in PHP which generates the HTML pages as needed.
After inundating you with all of my other blabbering nonsense, I will keep this one short, and won't bother you again unless I have a question I could not figure out in my ongoing research into Mobile Friendly.
Depreciated codes from XHTML to HTML5 did not cause me a problem as they had an alternate code which did the same thing. Like <tt> is now just <kbd>, or at least it worked for now using local HTML test. On-line live might pose a different set of errors, hi hi...
OK, no more eye bending. Have a great day Yogi, and THANKS for all the help and links!
TTUL
Gary
Re: Mobile Friendly
If you need an outside look at what you're doing to your web site, I'd be glad to kibitz any time.
I decided to build my own computer this time around and that motherboard is at the core of it. I just ordered all the pieces yesterday and I'm sure I'll be posting about my woes as I try to get this war machine to work. The ASUS mb is a bit under $250 which turns out to be about $100 less than the 4790k Intel processor to power it all. Yes, it's a bit extravagant. OK, very extravagant. But, if I don't spend it now my kids will fight over my fortune when I'm gone. I'm just making it easier for them.
I decided to build my own computer this time around and that motherboard is at the core of it. I just ordered all the pieces yesterday and I'm sure I'll be posting about my woes as I try to get this war machine to work. The ASUS mb is a bit under $250 which turns out to be about $100 less than the 4790k Intel processor to power it all. Yes, it's a bit extravagant. OK, very extravagant. But, if I don't spend it now my kids will fight over my fortune when I'm gone. I'm just making it easier for them.
Re: Mobile Friendly
Hi Yogi
Since I run Linux, my newest mobo, an Asus F2A85-M2 with AMD A4-6320 CPU, does not have a driver in the Linux Kernel.
I did manually install the driver for it, and forgot. So when the new kernel upgrade came along, I ended up with the black screen of death, and couldn't figure out how to get out of it. Spent four days with no solution.
Reloaded the OS and started over, using a generic video driver already in the kernel, but not the one recommended, because if I turn it on, nothing seems to work right, hi hi.
This was the second mobo I bought after the lightning took out my computers, so I didn't have time to study them before purchase.
I'm just about done getting my personal website up to HTML5, it had lots of pages and tons of images I had to resize and compress. Using the Local html5 and css3 tests, each page passed with zero errors. I'm hoping to get it uploaded to Comcast this weekend. THEN I will start on my authors website and try to get it done the Mobile Friendly way.
The version of my personal website I upload to Comcast I will Minify to see if that messes it up. But it won't use gzip or have expiration dates on the css or images. Have not figured out how to do that yet.
My personal webpage, being larger and harder, gave me a good opportunity to learn more about HTML5, although I don't like the many new restrictions they added to it. Sorta seems odd they would add restrictions while at the same time allowing for errors, hi hi...
W3C has not created a Validator Button for HTML5, but allow us to make our own, which is the last thing I did last night, now to add it to over 50 html pages. And I've got most of my personal website without their original pages as it is now. Made the links live, to force me to work on it, replacing the old stuff, but never found the time to do so.
Have a great weekend Yogi. I'll let you know when my personal website is up and running, but it won't look any different than it did in XHTML. I've not yet tried to redo it the right way, too big and too complex, and I do have a deadline to get my authors platform done or fall off the Google search engines I worked so hard to cover the first few pages on.
TTUL
Gary
Since I run Linux, my newest mobo, an Asus F2A85-M2 with AMD A4-6320 CPU, does not have a driver in the Linux Kernel.
I did manually install the driver for it, and forgot. So when the new kernel upgrade came along, I ended up with the black screen of death, and couldn't figure out how to get out of it. Spent four days with no solution.
Reloaded the OS and started over, using a generic video driver already in the kernel, but not the one recommended, because if I turn it on, nothing seems to work right, hi hi.
This was the second mobo I bought after the lightning took out my computers, so I didn't have time to study them before purchase.
I'm just about done getting my personal website up to HTML5, it had lots of pages and tons of images I had to resize and compress. Using the Local html5 and css3 tests, each page passed with zero errors. I'm hoping to get it uploaded to Comcast this weekend. THEN I will start on my authors website and try to get it done the Mobile Friendly way.
The version of my personal website I upload to Comcast I will Minify to see if that messes it up. But it won't use gzip or have expiration dates on the css or images. Have not figured out how to do that yet.
My personal webpage, being larger and harder, gave me a good opportunity to learn more about HTML5, although I don't like the many new restrictions they added to it. Sorta seems odd they would add restrictions while at the same time allowing for errors, hi hi...
W3C has not created a Validator Button for HTML5, but allow us to make our own, which is the last thing I did last night, now to add it to over 50 html pages. And I've got most of my personal website without their original pages as it is now. Made the links live, to force me to work on it, replacing the old stuff, but never found the time to do so.
Have a great weekend Yogi. I'll let you know when my personal website is up and running, but it won't look any different than it did in XHTML. I've not yet tried to redo it the right way, too big and too complex, and I do have a deadline to get my authors platform done or fall off the Google search engines I worked so hard to cover the first few pages on.
TTUL
Gary
Re: Mobile Friendly
I'm not sure what your Minify process does, but to me it means removing white space and comments so that there is not much left to read but the HTML itself. This should only serve to make it quicker to load on the server side, but my guess is it will not be a performance improvement that you can see or measure. We are talking milliseconds here.Gary wrote:The version of my personal website I upload to Comcast I will Minify to see if that messes it up. But it won't use gzip or have expiration dates on the css or images. Have not figured out how to do that yet.
Likewise, I don't recognize the complaint about gzip. Comcast already told you that they aren't running any scripts or applications on their server with the kind of account you are using. That means you are required to do the compression or decompression. i.e., using add-ons in a browser, for example.
Also, my understanding is that you can't do anything at all about the cache expiration dates. That has to be done on the server side and your ISP is the one who has to set it up. I think they already told you that they won't do it for your type of account. I've not talked to our people yet to see if they will fix it for our home page.
I can say this, however, our home page passes the Google Moble-Friendly test. It looks ugly in their simulation of what their crawler will see, but I've not been able to duplicate the ugliness on any mobile device we own. Go figure. The server side errors we are getting are from the W3C mobile-friendly test and I have some reservations about what THEY are doing. In their defense I'll admit they know what is mobile friendly, but I'm not so sure they know what is practical.
Re: Mobile Friendly
Hi Yogi
ALL VALIDATED HTML5, landing page and all pages from the index are Mobile Friendly, with a caveat.
I encountered a BUG in the W3C LIVE Validation system. A search proved it was a known bug from before 2011, and in July of 2012 they said they would have it fixed before August 1st of 2012. They must not have figured out how to fix it.
However, other folks came up with a work-around to prevent the bug from nailing you, hi hi...
The bad thing is, after everything passed the W3C local validation, I minified all 53 html pages, and all the css pages, and validated again local before uploading to Comcast. Where every page now failed, the same four errors on each page.
After studying the W3C tutorials for forming the lines in question, they were correct for XHTML and for HTML5 it said No Change in Format. The error was "No Space Between Attributes."
So I went through all 53 pages and removed the space, once again the validated locally. I did not Minify this time, since it was already close to midnight. I uploaded them and got the same error. "No Space Between Attributes." Say WHAT? I have no spaces at all in the lines they flagged.
Spent about an hour on-line using that as the search criteria. I finally found someone with the exact same lines I had pitching the same error. He figured out his problem was in one of his Meta lines, and when he changed it, his would then validate. Since I had a similar Meta line, I went through and changed all 53 pages again, but left the changes to the offending lines. It passed the local validation, but when I uploaded it, it failed the LIVE test again, only this time the error was worded different, "Missing Space Between Attributes." But the lines it showed as missing the space was NOT even an attribute line. Nevertheless, I went through all 53 pages again, changing the original four lines I removed the spaces from, back to the way they were originally.
Uploaded the documented html files to Comcast without Minifying them first. Figured I would do that this afternoon.
This morning before I did anything else, I ran through every page and link on my LIVE website, trying to find anything I may have missed, then used the Link I added with the new HTML5 logo at the bottom of my page where the XHTML logo used to be. Every Single Page passed W3C for HTML5 and CSS level 3 with NO ERRORS.
Hip Hip Hurray...
Only out of Curiosity, I ran my LIVE pages through Google Mobile Friendly LIVE test.
Index.html passed, "Congratulations, this page is Mobile-Friendly."
All seven html pages linked from the Paged Index navigation passed as Mobile-Friendly.
However, the 45 secondary pages with the left column image and float image did NOT pass.
What I have learned from this so far is I do not need expiration dates, and I do not need to Minify the html pages. Although I will anyhow. I may have to divide the left side of the page and the right side of the pages using sections to get them to be seen as Mobile Friendly.
Now, if I go to the Google Developers page and run my LIVE pages there, none of them pass, because they do not have expiration dates and are not using gzip.
Makes me wonder why their LIVE test passes the pages and their developer page test says it doesn't.
In any case, I was SURPRISED to see the "Congratulations Mobile-Friendly" appear at all on the main link test location. I hope this means their search engine will not demote me, hi hi...
FWIW: Using my wife's Schmartz-Fone to view my websites. Honestly, they viewed better in XHTML than they do in HTML5. However, some of the pages would not scroll beyond a certain point, so I went in and changed a few, so on a desktop the scroll goes way past the end of the page. There was a bug in the code which did not allow me to use page-length 100% in the CSS, so I used a fixed inch number based on a 640x480 screen resolution, which meant on 1240x1600, whatever the real resolution numbers are, many pages kept scrolling with white space at the end. Which is no biggie really. I just wish the codes W3C shows are supposed to work when used the proper way, really did.
OK, I'll quit bending your eyeballs. HTML5 passed on all, Mobile-Friendly passed on home and indexed pages, none of the rest, which I will work on fixing. Glad to see I don't need to worry about expirations and compressions.
http://home.comcast.net/~classichauslimited/
TTUL
Gary
ALL VALIDATED HTML5, landing page and all pages from the index are Mobile Friendly, with a caveat.
I encountered a BUG in the W3C LIVE Validation system. A search proved it was a known bug from before 2011, and in July of 2012 they said they would have it fixed before August 1st of 2012. They must not have figured out how to fix it.
However, other folks came up with a work-around to prevent the bug from nailing you, hi hi...
The bad thing is, after everything passed the W3C local validation, I minified all 53 html pages, and all the css pages, and validated again local before uploading to Comcast. Where every page now failed, the same four errors on each page.
After studying the W3C tutorials for forming the lines in question, they were correct for XHTML and for HTML5 it said No Change in Format. The error was "No Space Between Attributes."
So I went through all 53 pages and removed the space, once again the validated locally. I did not Minify this time, since it was already close to midnight. I uploaded them and got the same error. "No Space Between Attributes." Say WHAT? I have no spaces at all in the lines they flagged.
Spent about an hour on-line using that as the search criteria. I finally found someone with the exact same lines I had pitching the same error. He figured out his problem was in one of his Meta lines, and when he changed it, his would then validate. Since I had a similar Meta line, I went through and changed all 53 pages again, but left the changes to the offending lines. It passed the local validation, but when I uploaded it, it failed the LIVE test again, only this time the error was worded different, "Missing Space Between Attributes." But the lines it showed as missing the space was NOT even an attribute line. Nevertheless, I went through all 53 pages again, changing the original four lines I removed the spaces from, back to the way they were originally.
Uploaded the documented html files to Comcast without Minifying them first. Figured I would do that this afternoon.
This morning before I did anything else, I ran through every page and link on my LIVE website, trying to find anything I may have missed, then used the Link I added with the new HTML5 logo at the bottom of my page where the XHTML logo used to be. Every Single Page passed W3C for HTML5 and CSS level 3 with NO ERRORS.
Hip Hip Hurray...
Only out of Curiosity, I ran my LIVE pages through Google Mobile Friendly LIVE test.
Index.html passed, "Congratulations, this page is Mobile-Friendly."
All seven html pages linked from the Paged Index navigation passed as Mobile-Friendly.
However, the 45 secondary pages with the left column image and float image did NOT pass.
What I have learned from this so far is I do not need expiration dates, and I do not need to Minify the html pages. Although I will anyhow. I may have to divide the left side of the page and the right side of the pages using sections to get them to be seen as Mobile Friendly.
Now, if I go to the Google Developers page and run my LIVE pages there, none of them pass, because they do not have expiration dates and are not using gzip.
Makes me wonder why their LIVE test passes the pages and their developer page test says it doesn't.
In any case, I was SURPRISED to see the "Congratulations Mobile-Friendly" appear at all on the main link test location. I hope this means their search engine will not demote me, hi hi...
FWIW: Using my wife's Schmartz-Fone to view my websites. Honestly, they viewed better in XHTML than they do in HTML5. However, some of the pages would not scroll beyond a certain point, so I went in and changed a few, so on a desktop the scroll goes way past the end of the page. There was a bug in the code which did not allow me to use page-length 100% in the CSS, so I used a fixed inch number based on a 640x480 screen resolution, which meant on 1240x1600, whatever the real resolution numbers are, many pages kept scrolling with white space at the end. Which is no biggie really. I just wish the codes W3C shows are supposed to work when used the proper way, really did.
OK, I'll quit bending your eyeballs. HTML5 passed on all, Mobile-Friendly passed on home and indexed pages, none of the rest, which I will work on fixing. Glad to see I don't need to worry about expirations and compressions.
http://home.comcast.net/~classichauslimited/
TTUL
Gary
Re: Mobile Friendly
You are to be congratulated for your efforts and the certification reward that followed. As I read through your latest comments I was wondering how much of what you did really mattered. Your page rank depends much more on the search terms used than it does on the page layout. Disregarding that for a moment and assuming your goal was to keep your page rank unscathed, I don't see why you went more than one layer deep to become compliant. My understanding is that the search engine crawlers don't go more than one level deep into the links. Thus your home page and the links found thereon should be all you need to worry about, unless you are a perfectionist. Which obviously you are.
The space problem is a Catch 22 and made me distrust what W3C is actually doing. You absolutely need the spaces for XHTML but HTML5 doesn't care. It prefers not to have them but can live with them. Strict XHTML is a whole other story. The important question is, how does this affect your page rank? Both HTML5 and XHTML can be indexed just as easily. Mobile-friendly is another criteria that is more common sense than a set of definitions. The issue of floating objects is a good example. Mobile phones typically can't get the rendering correct when an object is floated. You get something, but maybe not what you want to show your viewers. That forces you to decide if you want a mobile-friendly web site plus an everything-else friendly web site, or do you want to follow the responsive web design Bible that Google is preaching. You can't have both.
My point is that there are many valid ways to create a web site. Some are mutually exclusive. HTML5 is an attempt to bring it all together under one roof, and you have made great strides to reach that point. Unfortunately, I think the number of browsers deployed in the wild that cannot render HTML5 properly is huge. That will all change with time and for now you did the right thing to keep your page rank in tact. Be that as it may, I doubt that all the visitors to your site will see the same thing. W3C validation notwithstanding.
The space problem is a Catch 22 and made me distrust what W3C is actually doing. You absolutely need the spaces for XHTML but HTML5 doesn't care. It prefers not to have them but can live with them. Strict XHTML is a whole other story. The important question is, how does this affect your page rank? Both HTML5 and XHTML can be indexed just as easily. Mobile-friendly is another criteria that is more common sense than a set of definitions. The issue of floating objects is a good example. Mobile phones typically can't get the rendering correct when an object is floated. You get something, but maybe not what you want to show your viewers. That forces you to decide if you want a mobile-friendly web site plus an everything-else friendly web site, or do you want to follow the responsive web design Bible that Google is preaching. You can't have both.
My point is that there are many valid ways to create a web site. Some are mutually exclusive. HTML5 is an attempt to bring it all together under one roof, and you have made great strides to reach that point. Unfortunately, I think the number of browsers deployed in the wild that cannot render HTML5 properly is huge. That will all change with time and for now you did the right thing to keep your page rank in tact. Be that as it may, I doubt that all the visitors to your site will see the same thing. W3C validation notwithstanding.
Re: Mobile Friendly
Hi Yogi - I just sat through six hours of Kindergarten Level beginners video's for HTML5/CSS trying to refresh my old failing memory banks. It helped a lot, because the teacher making the video was excellent. Just seeing the technique of HOW he built his pages taught me a lesson I wish I knew when I converted from HTML4 to XHTML. It is probably standard practice for those who ever studied writing any code in skewl. It may have been there when I first learned HTML, but if so, I missed it entirely. What am I talking about anyhow? Typing your opening AND closing Tag, and/or completing the Element before inserting the attributes. Doing this is probably normal to you, but is something I just picked up on yesterday.
Although not much has changed, I'm liking the new Tags in HTML5, and learned about the HTML5SHIV.JS so the new codes are recognized by IE and older browsers.
And this leads to the only question I have for today.
As excellent as the video's I watched were. I think the teacher omitted telling us about using a downloaded JS file.
This is what he showed to use in my HTML, it did not work.
From another website, not the video tutorial, I learned I can Link To (forget the URL) to use the JQuery elements, or I can download the JS file to a folder in my HTML file and make it a local src call.
I get almost the same directions as above, but the src is to an URL.
From these two websites I have deduced that the first example used by the teacher assumed you had the downloaded JS file in your HTML folders root, along with where index.html is stored.
There is the possibility that he placed the LINK in the Meta Data area and I missed it 6 video's earlier, hi hi...
OK, for my actual question. If I'm not using but a couple of the lines of the JS FILE, I see no reason to Download the Entire Folder to my HTML Folder. Also, using a LINK to an external source for the JS code, seems like it might slow things down or cause problems.
Can I just make a Folder in my HTML Folder for JS, like I do for GFX, and STYLE, and ONLY PUT those JS Codes I'm using, and not have the WHOLE file intact? Or does having the whole file not matter, because the index.html will only call the one file from the folder, so as not to load down the server.
I think I may have just answered my own question. When a user connects to my website, it only downloads the HTML file the user requested, which in turn ONLY uses the Image it needs from the GFX folder for said HTML file.
So I guess downloading the whole JS Folder only takes up some of my space allocation, and does not affect what the user downloads to view.
Nevertheless, can I only store the actual scripts I use, because there are hundreds I will never use. Tons of them have to do with Forms, Tables, and Making things do Fancy Stuff.
Thanks
TTUL
Gary
Although not much has changed, I'm liking the new Tags in HTML5, and learned about the HTML5SHIV.JS so the new codes are recognized by IE and older browsers.
And this leads to the only question I have for today.
As excellent as the video's I watched were. I think the teacher omitted telling us about using a downloaded JS file.
This is what he showed to use in my HTML, it did not work.
Code: Select all
<!DOCTYPE html>
<html>
<head>
<!--[if lt IE 9]>
<script
src="html5shiv.js">
</script>
<![endif]-->
<title>My first HTML5 page!</title>
</head>
I get almost the same directions as above, but the src is to an URL.
Code: Select all
<head>
<!--[if lt IE 9]>
<script
src="http://html5shiv.googlecode.com/svn/trunk/html5.js">
</script>
<![endif]-->
<title>Title</title>
</head>
There is the possibility that he placed the LINK in the Meta Data area and I missed it 6 video's earlier, hi hi...
OK, for my actual question. If I'm not using but a couple of the lines of the JS FILE, I see no reason to Download the Entire Folder to my HTML Folder. Also, using a LINK to an external source for the JS code, seems like it might slow things down or cause problems.
Can I just make a Folder in my HTML Folder for JS, like I do for GFX, and STYLE, and ONLY PUT those JS Codes I'm using, and not have the WHOLE file intact? Or does having the whole file not matter, because the index.html will only call the one file from the folder, so as not to load down the server.
I think I may have just answered my own question. When a user connects to my website, it only downloads the HTML file the user requested, which in turn ONLY uses the Image it needs from the GFX folder for said HTML file.
So I guess downloading the whole JS Folder only takes up some of my space allocation, and does not affect what the user downloads to view.
Nevertheless, can I only store the actual scripts I use, because there are hundreds I will never use. Tons of them have to do with Forms, Tables, and Making things do Fancy Stuff.
Thanks
TTUL
Gary
Re: Mobile Friendly
I see a role reversal taking place in the near future. I will become your student if you keep on learning about HTML5 as rapidly as you are. You have more of a need to know than I do, but still. I do like to keep up on things like that.
If you are a seasoned programmer you will be familiar with best practices much the same as you do in any other field. One of the things I use to write web pages is an editor with plug-ins that assist along the way. For example, the EditPlus program will write the necessary HTML tags for you and color code them. I'm not sure there is a Linux version of this editor, but I am sure there is a counterpart in the Linux repositories somewhere. I do all my writing in Windows so that I am not familiar with what is available. I do know that I'd go nuts and give up quickly if I was confined to using gedit.
One of the conventions when constructing a web site is to have often used directories at the root level; /images, /cgi-bin, and /scripts are the most common, but you may have others as well. The /scripts directory is where you would have all your local scripts and you would make reference to them in your page header:
You will note that the scripts I use here are not in the standard /scripts directory. As I explained above I don't want web crawlers poking around just any ol' place on our server, so I locked them out of the /scripts directory. Google, of course, complained about this when I ran their validator. So I made a special directory just for the likes of Google, /scripts_h. Only the java scripts needed for the web page are in the /scripts_h directory. You can put more in there, of course, but it's a waste of server storage if you do not use them. The alternative is to write the script into your web page. The last thing I would do with important scripts is depend on somebody's server to be up and available for me to use them.
To answer your specific question about the need to put the "entire file" into the /scripts directory, it depends on what HTML5SHIV.JS does. Your code example shows that you are querying to see if the browser is IE9 or less. If it is, then run the HTML5SHIV.JS script.
If HTML5SHIV.JS does everything IE9 needs all on it's own, then you don't need anything else. But, if HTML5SHIV.JS calls some of those other apparently useless files (dependencies?), then you will need them all. Unless you can find somebody to tell you how HTML5SHIV.JS works, you will need an old IE browser to test it out yourself.
I imagine the scenario to be something like this:
A browser calls for your index.html page, then your javascript determines what browser is calling it. If the browser happens to be IE9 or earlier, then images/HTML5SHIV.JS is called. As the old browser continues to read your HTML it may require HTML5SHIV.JS to use other scripts to help render the web page correctly. Those other scripts may never be used by one browser but a dozen of them might be used by other browsers. And yes, only one script at a time will be called, but there may be a need for many scripts.
The only problems I see are from folks still using Windows XP.
Everybody else will not need to have their browsers augmented with scripts you are providing. If you have limited server storage space, it might be time to tell those obsolete OS's and browsers to look elsewhere.
If you are a seasoned programmer you will be familiar with best practices much the same as you do in any other field. One of the things I use to write web pages is an editor with plug-ins that assist along the way. For example, the EditPlus program will write the necessary HTML tags for you and color code them. I'm not sure there is a Linux version of this editor, but I am sure there is a counterpart in the Linux repositories somewhere. I do all my writing in Windows so that I am not familiar with what is available. I do know that I'd go nuts and give up quickly if I was confined to using gedit.
One of the conventions when constructing a web site is to have often used directories at the root level; /images, /cgi-bin, and /scripts are the most common, but you may have others as well. The /scripts directory is where you would have all your local scripts and you would make reference to them in your page header:
Code: Select all
<script type="text/javascript" src="scripts_h/countdown.js" defer="defer"></script>
<script type="text/javascript" src="scripts_h/jquery.min.js"></script>To answer your specific question about the need to put the "entire file" into the /scripts directory, it depends on what HTML5SHIV.JS does. Your code example shows that you are querying to see if the browser is IE9 or less. If it is, then run the HTML5SHIV.JS script.
If HTML5SHIV.JS does everything IE9 needs all on it's own, then you don't need anything else. But, if HTML5SHIV.JS calls some of those other apparently useless files (dependencies?), then you will need them all. Unless you can find somebody to tell you how HTML5SHIV.JS works, you will need an old IE browser to test it out yourself.
I imagine the scenario to be something like this:
A browser calls for your index.html page, then your javascript determines what browser is calling it. If the browser happens to be IE9 or earlier, then images/HTML5SHIV.JS is called. As the old browser continues to read your HTML it may require HTML5SHIV.JS to use other scripts to help render the web page correctly. Those other scripts may never be used by one browser but a dozen of them might be used by other browsers. And yes, only one script at a time will be called, but there may be a need for many scripts.
The only problems I see are from folks still using Windows XP.
Everybody else will not need to have their browsers augmented with scripts you are providing. If you have limited server storage space, it might be time to tell those obsolete OS's and browsers to look elsewhere.Re: Mobile Friendly
I looked into HTML5SHIV.JS a little more since I wrote the above and will say I made a darn good guess considering I never used it before. It's what they call a shim for IE9 or earlier browsers so that those browsers may interpret HTML5 code correctly. Althought I've not seen a detailed explanation of it, I have seen a few references to the "library" of scripts that go along with HTML5SHIV.JS. That makes sense given what I know about programming languages. You can pre-load libraries of specific functions to make certain commands available in your programming code. Thus, instead of loading the entire interpreter along with your program code, you only need to load the libraries of functions you intend to use. In your case you want to load the library of javascripts that IE9 et. al. can use to emulate modern HTML coding.
So...do you need to load the whole library or not? That depends on the browser being used to view your web page. Since you seem to have a need to appeal to the entire world of browsers, then it would be prudent to load the entire library into your /scripts directory. If your storage space is limited, then you will need to decide if you should abandon those old browsers or give them an entirely different web (XHTML?) website of their own via a redirect. I don't envy you. It's a tough call.
So...do you need to load the whole library or not? That depends on the browser being used to view your web page. Since you seem to have a need to appeal to the entire world of browsers, then it would be prudent to load the entire library into your /scripts directory. If your storage space is limited, then you will need to decide if you should abandon those old browsers or give them an entirely different web (XHTML?) website of their own via a redirect. I don't envy you. It's a tough call.
Re: Mobile Friendly
Hi Yogi
So far I have not added any JavaScript or JQuery stuff to my web pages.
I need to learn a whole lot more about it before I do, and studying it was starting to confuse me.
I've never worried about IE users in the past, and probably won't in the future.
But none of the old browsers recognize the new HTML5 tags, and that line of code, although for IE, was supposed to handle all of them, I think, but don't quote me on it, hi hi. There may be some other JQuery lines I did not include in my example.
I was planning on doing a complete rewrite of my authors website in HTML5, but just learned the date Google chose was April 21st, not April 30th as I first thought. This gives me less than a week to get my authors website at least partially enough Mobile Friendly it passes their easier test first. Then I can go about writing it in HTML5 the right way.
YES we do have several programs for writing HTML, some are really neat, you type a tag and it has a drop down box with all the attributes, so you only need to click on them. Even so, I still use just GEDIT.
I can't remember the name of the program I was using when I was trying to learn PHP, bluefin, bluefish, something like that, but it had html4 and XHTML in it too. What I didn't like about it was all Styles were placed up in the head section, so if you wanted to use a stylesheet, CSS, you had to go through and add the curly brackets yourself after you moved everything between style and /style to the CSS page.
I could use a program where I don't need to know any HTML to make my HTML pages, it works like word processor and then saves as html, but differently than a word processor normally does. You don't learn anything using those types of programs, which is why I stick with GEdit which only gives a little help.
I did fall back on bluefish when I was trying to get my Float image, to not affect page length. An image, FIXED Position Absolute, should have absolutely nothing to do with the length of a page.
I did experiment a little with the html5 way of doing the same thing, and it works properly. I call it a float image, even though it is a fixed image, because it stays put as the page scrolls under it. It is only used on my third tier webpages.
It serves no function other than left border decoration and nothing more on pages that do not have a navigation section on the left. Google Mobile Test passes my navigation box on index.html and all html pages in my indexed pages folder, meaning the pages the Index Nav box links to, but fails my empty left column, those indexed pages link to,which column is much narrower, only 100px. I'm sure it has to do with how the page is set-up, which is why I want to rewrite in HTML5 from scratch.
I'm frantically going through my authors website, converting XHTML to html5 with as few changes as possible for now, resizing all images to the sizes they are displayed, then compressing each, and renaming them, probably with too long of names, but each now contains enough information for SEO purposes, and to help me know where each one goes.
Honestly, I really don't know what I'm doing. I keep looking at tutorials, watching video's, and reading forum posts, trying to achieve the 'best practices' and to figure out where things go and why. But as soon as I do rewrite my websites to HTML5 the right way, I will forget everything I learned, and have to look it up again when I need to add or fix something. Which is one of the reasons you see silly notes on my source pages.
HTML5 might just save me from having so many separate html pages,
If I'm thinking right here, my Nav Index could point to <Section> instead of to a separate html as an index, and then within <Section> I could have <Article> for each of my now separate html pages.
My only concern is having everything on one html page would mean a mighty big download, hi hi...
So I think keeping the main Indexed Links going to separate pages to be more reasonable.
No questions today, and probably not until I start trying to figure out how to rewrite in HTML5 the right way.
By the way, thanks for the vote of confidence!
TTUL
Gary
So far I have not added any JavaScript or JQuery stuff to my web pages.
I need to learn a whole lot more about it before I do, and studying it was starting to confuse me.
I've never worried about IE users in the past, and probably won't in the future.
But none of the old browsers recognize the new HTML5 tags, and that line of code, although for IE, was supposed to handle all of them, I think, but don't quote me on it, hi hi. There may be some other JQuery lines I did not include in my example.
I was planning on doing a complete rewrite of my authors website in HTML5, but just learned the date Google chose was April 21st, not April 30th as I first thought. This gives me less than a week to get my authors website at least partially enough Mobile Friendly it passes their easier test first. Then I can go about writing it in HTML5 the right way.
YES we do have several programs for writing HTML, some are really neat, you type a tag and it has a drop down box with all the attributes, so you only need to click on them. Even so, I still use just GEDIT.
I can't remember the name of the program I was using when I was trying to learn PHP, bluefin, bluefish, something like that, but it had html4 and XHTML in it too. What I didn't like about it was all Styles were placed up in the head section, so if you wanted to use a stylesheet, CSS, you had to go through and add the curly brackets yourself after you moved everything between style and /style to the CSS page.
I could use a program where I don't need to know any HTML to make my HTML pages, it works like word processor and then saves as html, but differently than a word processor normally does. You don't learn anything using those types of programs, which is why I stick with GEdit which only gives a little help.
I did fall back on bluefish when I was trying to get my Float image, to not affect page length. An image, FIXED Position Absolute, should have absolutely nothing to do with the length of a page.
I did experiment a little with the html5 way of doing the same thing, and it works properly. I call it a float image, even though it is a fixed image, because it stays put as the page scrolls under it. It is only used on my third tier webpages.
It serves no function other than left border decoration and nothing more on pages that do not have a navigation section on the left. Google Mobile Test passes my navigation box on index.html and all html pages in my indexed pages folder, meaning the pages the Index Nav box links to, but fails my empty left column, those indexed pages link to,which column is much narrower, only 100px. I'm sure it has to do with how the page is set-up, which is why I want to rewrite in HTML5 from scratch.
I'm frantically going through my authors website, converting XHTML to html5 with as few changes as possible for now, resizing all images to the sizes they are displayed, then compressing each, and renaming them, probably with too long of names, but each now contains enough information for SEO purposes, and to help me know where each one goes.
Honestly, I really don't know what I'm doing. I keep looking at tutorials, watching video's, and reading forum posts, trying to achieve the 'best practices' and to figure out where things go and why. But as soon as I do rewrite my websites to HTML5 the right way, I will forget everything I learned, and have to look it up again when I need to add or fix something. Which is one of the reasons you see silly notes on my source pages.
HTML5 might just save me from having so many separate html pages,
If I'm thinking right here, my Nav Index could point to <Section> instead of to a separate html as an index, and then within <Section> I could have <Article> for each of my now separate html pages.
My only concern is having everything on one html page would mean a mighty big download, hi hi...
So I think keeping the main Indexed Links going to separate pages to be more reasonable.
No questions today, and probably not until I start trying to figure out how to rewrite in HTML5 the right way.
By the way, thanks for the vote of confidence!
TTUL
Gary
Re: Mobile Friendly
I have a bit of good news today Yogi.
I'm no where near done yet, just starting in fact. But I finally solved a serious problem I've had for years with my third tier html pages. Those are the ones with the FIXED image I call a float image on the top left of the page, and the separate column of the background only darker on the left.
In the past, I had to control the height of each page on the actual html page, because it did not work on the CSS page. In fact, if I tried on the CSS page, to control the column height, like 100%, the fixed image would disappear, or the whole column on the left would disappear.
Also, if I tried putting it in a class .leftcolumn on the CSS it didn't work at all, or #leftcolumn, same problem with the controls for it.
You can only use background-image once, but can use background more than once in an element.
I followed every tutorial I found on doing this, using the exact directions provided by each tutorial, and not a single one worked. I just kept playing around until I did get it to work, but in a much convoluted way.
I thought I had found the answer when I found a two column website with all elements as Block. But when I changed the color to an image, it didn't work either.
Last night, around midnight I finally figured it out, thanks to a comment I stumbled across on one of the websites.
The entirety of the left column 100px wide image, the fixed image in the top left corner, and a way to move it down a tad, is contained in a single CSS statement. The whole page background is included on the next line and held in a container. It may still not pass the Mobile Friendly due to the 100px left margin, but I won't know until I finish the sample page and upload the new CSS.
You may have already known about this trick, or may never have had a need to use it. But it works perfectly.
It MUST be in <Body> because it does not work anywhere else, not even in a <div>. Why I don't know. But by putting it here, I do not need to worry about height, the left column never ends until it reaches the end of the page.
The reason for 0% 1% instead of top left is to move it down from the top of the page a tad.
Forgot to say the left-column-image is only 100px wide, as is the silhouette-float-image, which has a transparent box 100px wide with the image centered in it.
Oh, yes, I do have a question.
I'm getting so much conflicting information regarding Mobile Friendly it is downright pitiful.
I understand using BLOCK instead of INLINE will make the page appear as one long column on small screens, which is OK with me. Like Nav may appear first, then Section, etc.
I'm using a couple of tutorials and see no difference between them on HTML5 setup for a responsive website.
For example: I've always used a CONTAINER width statement. Then adjusted all of my images, boxes, etc. to fit within the confines of the container width.
I am using <meta name="viewport" content="width=device-width, initial-scale=1" /> in the head section.
When I view my existing site on a mobile phone, the images shrink to fit the screen, as does the container, even though I gave it a fixed width of 800px. If I use width 100% then images fall off the screen needing scroll bars.
Here is what I'm finding in the comments.
"I make all of my pages 400px wide. Desktop users can zoom in."
"I only make mine 300 wide for mobile, 1000 wide for desktops."
"How do you do that?" No reply to that comment.
"You shouldn't use a page width at all, it is included in the Body automatically."
"I have my Nav on the left, and it causes Google to say Not Mobile Friendly, content off screen. The code is identical on another page and I get 'this page is Mobile Friendly. So something is else is causing the problem. But what?" No response to this comment either.
Is there a specific width one should make their page?
I thought using BLOCK mode would fix the off-screen problems.
Thanks
TTUL
Gary
I'm no where near done yet, just starting in fact. But I finally solved a serious problem I've had for years with my third tier html pages. Those are the ones with the FIXED image I call a float image on the top left of the page, and the separate column of the background only darker on the left.
In the past, I had to control the height of each page on the actual html page, because it did not work on the CSS page. In fact, if I tried on the CSS page, to control the column height, like 100%, the fixed image would disappear, or the whole column on the left would disappear.
Also, if I tried putting it in a class .leftcolumn on the CSS it didn't work at all, or #leftcolumn, same problem with the controls for it.
You can only use background-image once, but can use background more than once in an element.
I followed every tutorial I found on doing this, using the exact directions provided by each tutorial, and not a single one worked. I just kept playing around until I did get it to work, but in a much convoluted way.
I thought I had found the answer when I found a two column website with all elements as Block. But when I changed the color to an image, it didn't work either.
Last night, around midnight I finally figured it out, thanks to a comment I stumbled across on one of the websites.
The entirety of the left column 100px wide image, the fixed image in the top left corner, and a way to move it down a tad, is contained in a single CSS statement. The whole page background is included on the next line and held in a container. It may still not pass the Mobile Friendly due to the 100px left margin, but I won't know until I finish the sample page and upload the new CSS.
You may have already known about this trick, or may never have had a need to use it. But it works perfectly.
It MUST be in <Body> because it does not work anywhere else, not even in a <div>. Why I don't know. But by putting it here, I do not need to worry about height, the left column never ends until it reaches the end of the page.
The reason for 0% 1% instead of top left is to move it down from the top of the page a tad.
Forgot to say the left-column-image is only 100px wide, as is the silhouette-float-image, which has a transparent box 100px wide with the image centered in it.
Code: Select all
body {
background: url("../gfx/htmlpgs-css-dutch-rhudy-silhouette-float-image.png") 0% 1% no-repeat fixed, url("../gfx/htmlpgs-css-water-left-column-image-compressed60.jpg") repeat-y;
}
.container {
background-image: url("../gfx//htmlpgs-css-water-background-image-compressed50.jpg");
position: absolute;
top: 0px;
left: 100px;
}
Code: Select all
</head>
<body>
<div class="container">
<!-- everything else is in here and container is closed after the footer, very last before the body is closed -->
</div>
</body>
</html>
I'm getting so much conflicting information regarding Mobile Friendly it is downright pitiful.
I understand using BLOCK instead of INLINE will make the page appear as one long column on small screens, which is OK with me. Like Nav may appear first, then Section, etc.
I'm using a couple of tutorials and see no difference between them on HTML5 setup for a responsive website.
For example: I've always used a CONTAINER width statement. Then adjusted all of my images, boxes, etc. to fit within the confines of the container width.
I am using <meta name="viewport" content="width=device-width, initial-scale=1" /> in the head section.
When I view my existing site on a mobile phone, the images shrink to fit the screen, as does the container, even though I gave it a fixed width of 800px. If I use width 100% then images fall off the screen needing scroll bars.
Here is what I'm finding in the comments.
"I make all of my pages 400px wide. Desktop users can zoom in."
"I only make mine 300 wide for mobile, 1000 wide for desktops."
"How do you do that?" No reply to that comment.
"You shouldn't use a page width at all, it is included in the Body automatically."
"I have my Nav on the left, and it causes Google to say Not Mobile Friendly, content off screen. The code is identical on another page and I get 'this page is Mobile Friendly. So something is else is causing the problem. But what?" No response to this comment either.
Is there a specific width one should make their page?
I thought using BLOCK mode would fix the off-screen problems.
Thanks
TTUL
Gary
Re: Mobile Friendly
Oy ... so many questions, and so few answers. I'm not surprised. I don't have all the answers for you either, but I think I can point you in the right direction.
First, look at this: http://brainformation.com/FloatImage.html
It's not your web page, but it seems to have all the elements you need to work with. Here is how it was accomplished: I didn't reproduce all the text in the above code because it is meant to just be filler to make a point. Your content will be much different but will fit easily into one column.
The CSS display property is an unnecessary complication. It had it's value in the days when making tables was in vogue. Today the id selector is much preferred because you have much more control of your elements (blocks of content) that way. While it's not strictly true, each ID can be considered a frame in which you can build an entire web page with the added benefit that you have control over where those frames are positioned on your web page.
In my example you will note I used one ID for the block of content called "war." and another ID for the leftcol <div> on the left that contains the "floating" image. I specified no width for the war ID so that it's content is fluid. You can squeeze it down to a 300 pixel width easily without losing anything off the edges or stretch it to 2400px if you got the monitor to do it. It might be hard to read that way, but it is fluid.
The position for the war content is absolute: 300px in from the left and 10px down from the top. You can adjust this position easily by changing the top or left specifications. I placed it next to the texture going down the left side, but it could go anywhere you need to put it.
The moral of this story is that your content container can be an ID selector that is easy to format and position.
The "love-u" graphic is the second ID. I put the image in a <div> tag so that I can make it into an ID. That allows me to do things like change the color of the background, resize the box in which the image is contained, and most importantly allows me to position it anywhere I want on the page. In my example it's in a fixed position so that you can scroll to the end of your computer's memory and the image will be in the same place all the time. Note that I stated a z-axis parameter. This is not absolutely necessary, but it assures that the image is loaded last and always on top. If by some chance you have content under the fixed image, the content will not overwrite the image. Also note, no page length is necessary for the image to stay put.
I have not tested my sample with Google or anybody else, but I am very confident that the image is the starting point for displaying the content of this page, which means it will never go off the page. The war content might go off to the right if you have it spaced too far from the left, but even that is very unlikely. The people who pick an arbitrary width or expect their viewers to zoom in as necessary are naive to put it nicely. To answer your question about an ideal width, that depends on your strategy for web site building. You can make pages for small screen mobile devices and for large screen desktops, or you can make pages that will work in both. I think you are interested in the later. It's harder to make such pages because you have to anticipate what happens to all the elements when you squish them, but it is the much preferred approach these days of mobile friendliness.
My example can easily be used as a template for all your web pages, thus making changes to the layout infinitely easier than fine tuning 50+ separate pages. The content will change, but the boxes you put it in will be the same everywhere.
First, look at this: http://brainformation.com/FloatImage.html
It's not your web page, but it seems to have all the elements you need to work with. Here is how it was accomplished:
Code: Select all
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<style>
body {
background-color: tan;
background-image: url(images_h/texture.jpg);
background-repeat: repeat-y;
background-position: left;
}
#leftcol {
z-index: 10;
position: fixed;
left: 10px;
top: 10px;
background-color: silver;
border: solid black 2px;
}
#war {
position: absolute;
top: 10px;
left: 300px;
}
</style>
<title>Floating Image</title>
</head>
<body>
<div id="leftcol">
<img src="images_h/loveU.gif" width="37" height="26" border="0" alt="Love You">
</div>
<div id="war">
Causes of secession
Main articles: Origins of the American Civil War, Timeline of events leading to the American Civil War and History of the United States
The causes of the Civil War were complex and have been controversial since the war began. The issue has been further complicated by historical revisionists, who have tried to offer a variety of reasons for the war.[13] Slavery
...
...
...
...
</div>
</body>
</html>
The CSS display property is an unnecessary complication. It had it's value in the days when making tables was in vogue. Today the id selector is much preferred because you have much more control of your elements (blocks of content) that way. While it's not strictly true, each ID can be considered a frame in which you can build an entire web page with the added benefit that you have control over where those frames are positioned on your web page.
In my example you will note I used one ID for the block of content called "war." and another ID for the leftcol <div> on the left that contains the "floating" image. I specified no width for the war ID so that it's content is fluid. You can squeeze it down to a 300 pixel width easily without losing anything off the edges or stretch it to 2400px if you got the monitor to do it. It might be hard to read that way, but it is fluid.
The position for the war content is absolute: 300px in from the left and 10px down from the top. You can adjust this position easily by changing the top or left specifications. I placed it next to the texture going down the left side, but it could go anywhere you need to put it.
The moral of this story is that your content container can be an ID selector that is easy to format and position.
The "love-u" graphic is the second ID. I put the image in a <div> tag so that I can make it into an ID. That allows me to do things like change the color of the background, resize the box in which the image is contained, and most importantly allows me to position it anywhere I want on the page. In my example it's in a fixed position so that you can scroll to the end of your computer's memory and the image will be in the same place all the time. Note that I stated a z-axis parameter. This is not absolutely necessary, but it assures that the image is loaded last and always on top. If by some chance you have content under the fixed image, the content will not overwrite the image. Also note, no page length is necessary for the image to stay put.
I have not tested my sample with Google or anybody else, but I am very confident that the image is the starting point for displaying the content of this page, which means it will never go off the page. The war content might go off to the right if you have it spaced too far from the left, but even that is very unlikely. The people who pick an arbitrary width or expect their viewers to zoom in as necessary are naive to put it nicely. To answer your question about an ideal width, that depends on your strategy for web site building. You can make pages for small screen mobile devices and for large screen desktops, or you can make pages that will work in both. I think you are interested in the later. It's harder to make such pages because you have to anticipate what happens to all the elements when you squish them, but it is the much preferred approach these days of mobile friendliness.
My example can easily be used as a template for all your web pages, thus making changes to the layout infinitely easier than fine tuning 50+ separate pages. The content will change, but the boxes you put it in will be the same everywhere.
Last edited by yogi on 17 Apr 2015, 00:19, edited 1 time in total.
Re: Mobile Friendly
I have used a CSS reset sheet which works out to be the same as the reference you found for putting the style configuration into the body tag: http://stackoverflow.com/questions/2357 ... -scrolling I've also read criticism about resetting web pages and have shied away from it for the most part. It boils down to personal preference, I suppose, and mine is to make styles as obvious and easy to read as possible. I am easily confused by indirect references, handy as they may be for some people.
The viewport metatag is not a standard from what I can gather. It is recognized by a lot of mobile browsers however, and most likely will be adopted as a standard in one form or another. Basically this metatag is the mechanism by which mobile devices automatically resize web pages. As I mentioned several replies back in this thread, two things are working simultaneously to determine the view of your web page. One is the browser and the other is the mobile device itself. The viewport metatag will tell the mobile device what to do, but the person doing the viewing can still zoom and pan the web page. It's two different things. I have a personal preference for making web pages visible on a 800px wide screen which is fine for laptops and desktops, but that has to be resized for most mobile devices. That resizing can be made automatic with the metatag. That is likely what is happening when you declare an image to be a certain size, but the mobile device adjusts it automatically to fit it on it's small screen.
There are a lot of options for accomplishing the same task and that is the downside of trying to get help from support forums. Everyone thinks their way is the only way and they assume you know what their way is. I think we have to be mobile friendly in order to appease the gods of Google, but the strategy and techniques we use to get there are so diverse that it's confusing. You seem to be heading in the right direction by just making things work and then going back later to do it the right way. The hard part will be determining what exactly is the right way.
The viewport metatag is not a standard from what I can gather. It is recognized by a lot of mobile browsers however, and most likely will be adopted as a standard in one form or another. Basically this metatag is the mechanism by which mobile devices automatically resize web pages. As I mentioned several replies back in this thread, two things are working simultaneously to determine the view of your web page. One is the browser and the other is the mobile device itself. The viewport metatag will tell the mobile device what to do, but the person doing the viewing can still zoom and pan the web page. It's two different things. I have a personal preference for making web pages visible on a 800px wide screen which is fine for laptops and desktops, but that has to be resized for most mobile devices. That resizing can be made automatic with the metatag. That is likely what is happening when you declare an image to be a certain size, but the mobile device adjusts it automatically to fit it on it's small screen.
There are a lot of options for accomplishing the same task and that is the downside of trying to get help from support forums. Everyone thinks their way is the only way and they assume you know what their way is. I think we have to be mobile friendly in order to appease the gods of Google, but the strategy and techniques we use to get there are so diverse that it's confusing. You seem to be heading in the right direction by just making things work and then going back later to do it the right way. The hard part will be determining what exactly is the right way.
Re: Mobile Friendly
Hi Yogi
Thanks for the info!
I've been working directly from the W3C Tutorials, and as usual, having more problems than Carter's has pills.
Starting with a blank page, I added all of the Text for my Natural Attractions page with no formatting.
Then using the new HTML5 element names, put it all together, exactly how they showed to do it for each one.
I did not use the <main> element, because it is not recognized enough yet.
Not counting the left column currently on the existing page, although I found adding it or not adding made no difference to the 'container' where everything else is located.
Nothing, and I mean Nothing, worked as shown on the Tutorial Pages.
<header> I placed the small host icon, absolute, so didn't need float left. Also in the header, I placed the wide image to its right, but used relative instead of absolute, because all the text was under it. Figure that would clear up after I added <nav> and <section> elements. Making the header image, relative, float left, did get the text out from under it, but adding <nav> ended up with the text under it.
I finally got thing to where they looked right on the page using <section> <article> </article> </section>, and added the <footer> at the bottom. I used BLOCK for everything, except I used INLINE for the <nav> (breadcrumb) line.
Passes W3C tests, passes Mobile Friendly paste in test. Looks like H on a mobile phone viewscreen, worse than my original document. This is without the left image by the way.
Adding a WIDTH to the <body> element, did not change the width of my document one iota.
Yet if I only do this without anything on a page other than sample text and no images at all, width does work.
I can resize <section> or <article> boxes, but not body. I can resize my <div> Id="container"> also. But it doesn't help with Mobile Friendly if the <body> is self-adjusting to 1121px wide. Causes page overflow, even when nothing is beyond 800px on the page. AAaaaaargh...
On a different topic.
I looked into BOOTSTRAP and followed ALL of the tutorials regarding same.
It uses it's OWN CSS, and from what I understand, you can still have your own CSS as well to work with it.
In fact, another person I was talking to, told me I could make two CSSs one for desktops, and one for mobile, like he does on his website. Naturally he's using JS because I saw @media instructions.
I got to talking to him because he has a left <nav> area used for desktops, but for mobile, he uses buttons across the top for the <nav>.
Basically, the MAIN CSS is the one for Mobile, it contains everything needed for the whole page, except for the left <nav> stuff. On the Desktop.css he only has the <nav> for the left column <nav> and the button bar is hidden in such a way it allows the desktop page to close up the gap. Apparently that part is done with JS because using the 'hidden' instruction still leaves the gap.
I thought cool, this would work for me to show my left column on a desktop, but not on a mobile. Unfortunately I was not that lucky. My left image ONLY WORKS if it is in the <body> element. It does not work in <aside> or <section> nor even by using a <div>.
I do not show a size in my <body> tried, doesn't seem to work.
You also cannot use the element name <body> on two different CSS pages. The first will override the second, and W3C will fail the CSS.
I also tried using a <body id="desktop"> this did not work either, nor does using 'hidden' for the left column, it just leaves a blank spot.
Just using text in the 'header' or 'container' with NO images, seems to make everything work OK, and as expected.
Until I check it on Mobile viewers. Instead of shrinking like images in the <section> area do, the <header> image runs off the page, and I get a page overflow error on Mobile Friendly, which means Not Friendly.
I see plenty of pages with images in the headers, and they work right.
Oh, if I used Bootstrap, I can use a thumbnail image so it scales with the device, and if you click on it or touch it on a touch screen it opens to full size, but scaled on the device.
Here I thought starting from scratch and following the new HTML5 directions would be a piece of cake.
Should work, but as when I was learning XHTML, what they show you to do, BREAKS everything else.
Using 'relative' 'float left' should bring your boxes side by side as if INLINE, even though each are BLOCKS.
If I have three BLOCKS side by side, and you narrow the screen, they are supposed to move under each other. That's the whole purpose of using BLOCK, and even if the 'container' is too big, it is supposed to resize to fit the window and all the text is supposed to be flowable within each <section> or <article>.
Everything does work if you use ONLY TEXT with no images anywhere.
Add even a small image and everything messes up.
So there is some important piece of information missing from every tutorial I've read so far.
OK, I do have two questions.
Would you use Bootstrap or stick with only JS?
If I chose to use Bootstrap, can I have two CSS pages?
I ask because the Bootstrap Tutorial only shows white or gray backgrounds.
It does have images boxes for pictures, but I saw nothing for backgrounds or header images, etc.
I'm using Bluefish instead of Gedit, helps a little but not much. Makes it easier to bounce back and forth between HTML5 and CSS pages, and view on web browsers.
Looked at Google Web Developer for like three hours. The pages it creates are so convoluted, I could never make an adjustment if my life depended on it. 1000 times more data in both the html and css than is needed to display a simple page.
Played with a WYSIWYG html editor, an online version. Every single thing I tried doing said 'not allowed in html'.
All I did was move a picture of my small host icon to the top left of the page, which I know is allowed, hi hi...
OK, I'll quit bending your eyeballs.
SEE, told you I knew NOTHING about HTML, hi hi...
TTUL
Gary
Thanks for the info!
I've been working directly from the W3C Tutorials, and as usual, having more problems than Carter's has pills.
Starting with a blank page, I added all of the Text for my Natural Attractions page with no formatting.
Then using the new HTML5 element names, put it all together, exactly how they showed to do it for each one.
I did not use the <main> element, because it is not recognized enough yet.
Not counting the left column currently on the existing page, although I found adding it or not adding made no difference to the 'container' where everything else is located.
Nothing, and I mean Nothing, worked as shown on the Tutorial Pages.
<header> I placed the small host icon, absolute, so didn't need float left. Also in the header, I placed the wide image to its right, but used relative instead of absolute, because all the text was under it. Figure that would clear up after I added <nav> and <section> elements. Making the header image, relative, float left, did get the text out from under it, but adding <nav> ended up with the text under it.
I finally got thing to where they looked right on the page using <section> <article> </article> </section>, and added the <footer> at the bottom. I used BLOCK for everything, except I used INLINE for the <nav> (breadcrumb) line.
Passes W3C tests, passes Mobile Friendly paste in test. Looks like H on a mobile phone viewscreen, worse than my original document. This is without the left image by the way.
Adding a WIDTH to the <body> element, did not change the width of my document one iota.
Yet if I only do this without anything on a page other than sample text and no images at all, width does work.
I can resize <section> or <article> boxes, but not body. I can resize my <div> Id="container"> also. But it doesn't help with Mobile Friendly if the <body> is self-adjusting to 1121px wide. Causes page overflow, even when nothing is beyond 800px on the page. AAaaaaargh...
On a different topic.
I looked into BOOTSTRAP and followed ALL of the tutorials regarding same.
It uses it's OWN CSS, and from what I understand, you can still have your own CSS as well to work with it.
In fact, another person I was talking to, told me I could make two CSSs one for desktops, and one for mobile, like he does on his website. Naturally he's using JS because I saw @media instructions.
I got to talking to him because he has a left <nav> area used for desktops, but for mobile, he uses buttons across the top for the <nav>.
Basically, the MAIN CSS is the one for Mobile, it contains everything needed for the whole page, except for the left <nav> stuff. On the Desktop.css he only has the <nav> for the left column <nav> and the button bar is hidden in such a way it allows the desktop page to close up the gap. Apparently that part is done with JS because using the 'hidden' instruction still leaves the gap.
I thought cool, this would work for me to show my left column on a desktop, but not on a mobile. Unfortunately I was not that lucky. My left image ONLY WORKS if it is in the <body> element. It does not work in <aside> or <section> nor even by using a <div>.
I do not show a size in my <body> tried, doesn't seem to work.
You also cannot use the element name <body> on two different CSS pages. The first will override the second, and W3C will fail the CSS.
I also tried using a <body id="desktop"> this did not work either, nor does using 'hidden' for the left column, it just leaves a blank spot.
Just using text in the 'header' or 'container' with NO images, seems to make everything work OK, and as expected.
Until I check it on Mobile viewers. Instead of shrinking like images in the <section> area do, the <header> image runs off the page, and I get a page overflow error on Mobile Friendly, which means Not Friendly.
I see plenty of pages with images in the headers, and they work right.
Oh, if I used Bootstrap, I can use a thumbnail image so it scales with the device, and if you click on it or touch it on a touch screen it opens to full size, but scaled on the device.
Here I thought starting from scratch and following the new HTML5 directions would be a piece of cake.
Should work, but as when I was learning XHTML, what they show you to do, BREAKS everything else.
Using 'relative' 'float left' should bring your boxes side by side as if INLINE, even though each are BLOCKS.
If I have three BLOCKS side by side, and you narrow the screen, they are supposed to move under each other. That's the whole purpose of using BLOCK, and even if the 'container' is too big, it is supposed to resize to fit the window and all the text is supposed to be flowable within each <section> or <article>.
Everything does work if you use ONLY TEXT with no images anywhere.
Add even a small image and everything messes up.
So there is some important piece of information missing from every tutorial I've read so far.
OK, I do have two questions.
Would you use Bootstrap or stick with only JS?
If I chose to use Bootstrap, can I have two CSS pages?
I ask because the Bootstrap Tutorial only shows white or gray backgrounds.
It does have images boxes for pictures, but I saw nothing for backgrounds or header images, etc.
I'm using Bluefish instead of Gedit, helps a little but not much. Makes it easier to bounce back and forth between HTML5 and CSS pages, and view on web browsers.
Looked at Google Web Developer for like three hours. The pages it creates are so convoluted, I could never make an adjustment if my life depended on it. 1000 times more data in both the html and css than is needed to display a simple page.
Played with a WYSIWYG html editor, an online version. Every single thing I tried doing said 'not allowed in html'.
All I did was move a picture of my small host icon to the top left of the page, which I know is allowed, hi hi...
OK, I'll quit bending your eyeballs.
SEE, told you I knew NOTHING about HTML, hi hi...
TTUL
Gary
Re: Mobile Friendly
You are one hella resourceful guy and probably will have it all figured out by the time you read this, but I'm going to respond to your latest comments as if you were starting from scratch. Which is what you admit you are doing with HTML5.
PAPER TIGER
I could be wrong about this, but I think the only reason you are having nightmares about your website(s) is due to Google's recent pronouncement that in a few days they are changing the way they index things. You perceive this change as being a direct threat to your page rank. Since Google is bigger than either one of us, you are capitulating to their demands regarding how a web page should be written. If you don't comply, they will apply a "sticky note" of sorts next to your indexed records telling people how unfriendly you are. While all that sounds reasonable, I'm here to tell you it's an idle threat. So what if they do tag your records? What will change in the search results when people look up your pseudonym? Are there thousands, or hundreds, or tens, or even one other author using the same pen name? Nope. You are the only one - I looked it up.
So, even if you never changed one line of coding on your web pages from it's original, your pen name would still dominate the results of any search engine because there is nobody else like you. True, your unfriendly pages will get a yellow sticky note saying how unfriendly you are, but does it matter to those people who know your name and are looking for you specifically? No it does not matter and Google's thread is moot.
Be that all as it is, you are doing a good thing by attempting to reach the widest possible audience. Your personal web pages may indeed lose rank if they do not comply because several of the topics are generic enough to have search engine competition. But more than page rank, it's a great idea to make your content readable by the largest audience possible. And that is where you are at as of last night's post to this forum. I have my doubts that you can meet the deadline, but any guy that can figure out and embrace the likes of Gimp sure as shootin' can figure out something like HTML5. You may not be able to figure it out in time to meet the deadline, however. My advice to you is to disable your website so that crawlers cannot index it until after you have made it perfect. You don't want to mess with robots.txt or .htaccess in order to deny the bots. They can ignore those things, although most of them will honor your wishes. But don't take any chances. Move your site(s) to a new subdirectory, change the URL, take down the site altogether, or do something so that the bots can't find you once Google changes it's ways. After you go into hiding, then work on improving your site(s) off line without fear of getting tagged erroneously. Once you are tagged, it will be very difficult to remove it. So don't give Google, or anyone else, the opportunity to make a bad call.
THE LEARNING CURVE for anything technical is steep. Fortunately, you don't have to learn everything there is to know about HTML5 in order to use it. In fact all you need to know about are the things you will be using to render your web pages. And, therein is the rub. Determining what you need is often trial and error, and the success of that depends on what you know to be available. If you don't know HTML5 in it's entirety, then your choices are limited to only what you do know. That's when you start to think seriously about using somebody else's brain instead of your own.
Enter BOOTSTRAP. Bootstrap CSS is a framework in which you can work to create web pages. It has a bunch of pre-written tools that you can copy and paste into your web page and just add content. If you believe that, I have this bridge in Brooklyn I want you to look at. The author of Bootstrap CSS has indeed taken the time to create a powerful package of tools, but the assumption is that you know which tools you need. More than that, the tool is just a framework which begs to be modified to your specifications. Obviously you need to know HTML5 to do that. Well, if you are not familiar with HTML5 (or even it's basics), you don't have a chance at success using Bootstrap CSS. Thus you must weigh the time it will take you to learn what you need to know about HTML5 and go it alone against the time it will take you to reverse engineer something like Bootstrap CSS to make it usable on your web pages. That's a tough call. My personal preference is to go it alone, but I am always open to new ideas from people who have already been there and done that.
What about those WYSIWYG online editors? They are good for what they were intended to do. Out of necessity they are not clean and simple with the code they generate. They are intended to make a quick and easy web page. If you want to make changes, you may have to reverse engineer what was done for you by a robot. On the other hand, if the end result is exactly what you want, then who are we to question chaotic coding? It will only be a problem if you try to change it to appease the gods of Google.
I think you would benefit tremendously from using the proper development environment. There are two excellent editors that I know you would love, EditPlus and Notepad++. Sad to say, they don't come in Linux versions. However, I like what I've seen (but never used) regarding Scintilla. There will be a learning curve associated with this text editor, but I'm thinking the benefits outweigh the pain of learning. Then again, I never tried to install and use it on my Linux boxes, but it might be worth the time it takes to evaluate. Gedit is great, especially since you are familiar with it, but it is lacking a lot of the amenities of a true HTML editing environment. Your revision work can be made a lot easier if you used the right tools.
INSPECTING ELEMENTS
Again, I might be telling you something you already know, but this seldom used feature of FireFox has been a life saver in my sordid past. When you right click on a web page in FireFox, you get the option to "inspect element (Q). Click that and a windwow will appear at the bottom of the web page displaying the underlying code for the element you right-clicked. In addition to the code, you get a highlighted area on the actual web page showing you exactly where that element is located. Thus when you embed an image into a web page, and inspect it as an element, you can visually see what space it is occupying and view the code that put it there. This is invaluable information when you are working with containers. Change a paramenter in your code and see how that affects the space taken up by the element. Do that enough and you will quickly learn how to write the coding you need to produce the end results you are seeking. This feature of FireFox has always lurked in the shadows, but not until I started using it did I discover how valuable it is.
One of the more amazing revelations to come to me as a result of this FireFox tool has to do with boundaries. I have specified frames of content using <div> tags, for example, and discovered that the stuff I put inside the frames is not always confined by its dimensions. In other words, an image can be positioned relative to the 0/0 point of the frame, but that image is a layer on top of the element and not confined inside it. (See Serial Killers below for an explanation of why this is so) Text, however, is restricted by any stated dimensions for the <div>. Also, content in <div>'s will span across the entire body of your web page if relatively positioned, but be confined to it's own unique size if absolutely placed. You would think Block display would fix all that, but it does not because it does not change the type of element you are viewing as a block. It only changes the way it is viewed and not it's basic characteristics. I played with display elements at one point and became totally frustrated because not every browser will interpret it the same way. I now use styled <div> instead. In any case, my point here is that the visual representation of my HTML code can be graphically displayed by using the Inspect Elements feature of FireFox. Being a visual kind of guy, that tool helped me a lot to understand what I was telling my browser to do.
SERIAL KILLERS AND INHERITANCE
Again I beg your indulgence if this is not news to you, but perhaps it will help to read it once again. All web browsers read their instructions (HTML) in a linear fashion. In other words, the browser reads and responds to your coding one line at a time from top to bottom. It's all one super long string of characters as far as FireFox is concerned and it knows nothing about frames, styles, or layouts. Thus, because it's all read in a sequence from top to bottom, the order in which you state things is important. If you code your footer first, it will appear at the top of your web page and not the bottom. Calling it a footer means nothing to your browser. You can specify a position on the bottom of the page, but all the styling and specifications for that footer will be read first. That means, anything you code about this footer and is inheritable will be propagated down to the rest of the page in spite of it's visual location at the bottom.
The serial interpretation of code may be obvious, but inheritance is a little more tricky. Body {color: blue;} for example will make all the text within the body of your web page blue. You may change fonts and colors in the middle of the page, but the blue text is inherited by EVERY element unless you style that element separately. Inheritance is a nightmare and a half when it comes to floating images on multiple column pages. Read up on the CSS clear Property and be aware of how it is inherited just like my example for font color. Here too not every browser handles it the same way, and apparently mobile devices don't want it at all.
Multiple CSS sheets are permissible. Keep in mind that style sheets are read the same way as is HTML, one line at a time in sequence from top to bottom. I use this to my advantage while troubleshooting. I may change a parameter in my styling simply by repeating it with different specs. The last thing read is what the browser will use to render the content. Thus it is possible to have the body element stated twice, perhaps in two separate style sheets, but the last one read is the one that sticks. It's a way to keep a short history of what you tried, but don't abuse this loophole. It can be confusing to the smartest of browsers. To answer your question about multiple style sheets, yes it is possible and necessary at times. Just be sure to have unique identifiers in order to avoid confusion.
PAPER TIGER
I could be wrong about this, but I think the only reason you are having nightmares about your website(s) is due to Google's recent pronouncement that in a few days they are changing the way they index things. You perceive this change as being a direct threat to your page rank. Since Google is bigger than either one of us, you are capitulating to their demands regarding how a web page should be written. If you don't comply, they will apply a "sticky note" of sorts next to your indexed records telling people how unfriendly you are. While all that sounds reasonable, I'm here to tell you it's an idle threat. So what if they do tag your records? What will change in the search results when people look up your pseudonym? Are there thousands, or hundreds, or tens, or even one other author using the same pen name? Nope. You are the only one - I looked it up.
So, even if you never changed one line of coding on your web pages from it's original, your pen name would still dominate the results of any search engine because there is nobody else like you. True, your unfriendly pages will get a yellow sticky note saying how unfriendly you are, but does it matter to those people who know your name and are looking for you specifically? No it does not matter and Google's thread is moot.
Be that all as it is, you are doing a good thing by attempting to reach the widest possible audience. Your personal web pages may indeed lose rank if they do not comply because several of the topics are generic enough to have search engine competition. But more than page rank, it's a great idea to make your content readable by the largest audience possible. And that is where you are at as of last night's post to this forum. I have my doubts that you can meet the deadline, but any guy that can figure out and embrace the likes of Gimp sure as shootin' can figure out something like HTML5. You may not be able to figure it out in time to meet the deadline, however. My advice to you is to disable your website so that crawlers cannot index it until after you have made it perfect. You don't want to mess with robots.txt or .htaccess in order to deny the bots. They can ignore those things, although most of them will honor your wishes. But don't take any chances. Move your site(s) to a new subdirectory, change the URL, take down the site altogether, or do something so that the bots can't find you once Google changes it's ways. After you go into hiding, then work on improving your site(s) off line without fear of getting tagged erroneously. Once you are tagged, it will be very difficult to remove it. So don't give Google, or anyone else, the opportunity to make a bad call.
THE LEARNING CURVE for anything technical is steep. Fortunately, you don't have to learn everything there is to know about HTML5 in order to use it. In fact all you need to know about are the things you will be using to render your web pages. And, therein is the rub. Determining what you need is often trial and error, and the success of that depends on what you know to be available. If you don't know HTML5 in it's entirety, then your choices are limited to only what you do know. That's when you start to think seriously about using somebody else's brain instead of your own.
Enter BOOTSTRAP. Bootstrap CSS is a framework in which you can work to create web pages. It has a bunch of pre-written tools that you can copy and paste into your web page and just add content. If you believe that, I have this bridge in Brooklyn I want you to look at. The author of Bootstrap CSS has indeed taken the time to create a powerful package of tools, but the assumption is that you know which tools you need. More than that, the tool is just a framework which begs to be modified to your specifications. Obviously you need to know HTML5 to do that. Well, if you are not familiar with HTML5 (or even it's basics), you don't have a chance at success using Bootstrap CSS. Thus you must weigh the time it will take you to learn what you need to know about HTML5 and go it alone against the time it will take you to reverse engineer something like Bootstrap CSS to make it usable on your web pages. That's a tough call. My personal preference is to go it alone, but I am always open to new ideas from people who have already been there and done that.
What about those WYSIWYG online editors? They are good for what they were intended to do. Out of necessity they are not clean and simple with the code they generate. They are intended to make a quick and easy web page. If you want to make changes, you may have to reverse engineer what was done for you by a robot. On the other hand, if the end result is exactly what you want, then who are we to question chaotic coding? It will only be a problem if you try to change it to appease the gods of Google.
I think you would benefit tremendously from using the proper development environment. There are two excellent editors that I know you would love, EditPlus and Notepad++. Sad to say, they don't come in Linux versions. However, I like what I've seen (but never used) regarding Scintilla. There will be a learning curve associated with this text editor, but I'm thinking the benefits outweigh the pain of learning. Then again, I never tried to install and use it on my Linux boxes, but it might be worth the time it takes to evaluate. Gedit is great, especially since you are familiar with it, but it is lacking a lot of the amenities of a true HTML editing environment. Your revision work can be made a lot easier if you used the right tools.
INSPECTING ELEMENTS
Again, I might be telling you something you already know, but this seldom used feature of FireFox has been a life saver in my sordid past. When you right click on a web page in FireFox, you get the option to "inspect element (Q). Click that and a windwow will appear at the bottom of the web page displaying the underlying code for the element you right-clicked. In addition to the code, you get a highlighted area on the actual web page showing you exactly where that element is located. Thus when you embed an image into a web page, and inspect it as an element, you can visually see what space it is occupying and view the code that put it there. This is invaluable information when you are working with containers. Change a paramenter in your code and see how that affects the space taken up by the element. Do that enough and you will quickly learn how to write the coding you need to produce the end results you are seeking. This feature of FireFox has always lurked in the shadows, but not until I started using it did I discover how valuable it is.
One of the more amazing revelations to come to me as a result of this FireFox tool has to do with boundaries. I have specified frames of content using <div> tags, for example, and discovered that the stuff I put inside the frames is not always confined by its dimensions. In other words, an image can be positioned relative to the 0/0 point of the frame, but that image is a layer on top of the element and not confined inside it. (See Serial Killers below for an explanation of why this is so) Text, however, is restricted by any stated dimensions for the <div>. Also, content in <div>'s will span across the entire body of your web page if relatively positioned, but be confined to it's own unique size if absolutely placed. You would think Block display would fix all that, but it does not because it does not change the type of element you are viewing as a block. It only changes the way it is viewed and not it's basic characteristics. I played with display elements at one point and became totally frustrated because not every browser will interpret it the same way. I now use styled <div> instead. In any case, my point here is that the visual representation of my HTML code can be graphically displayed by using the Inspect Elements feature of FireFox. Being a visual kind of guy, that tool helped me a lot to understand what I was telling my browser to do.
SERIAL KILLERS AND INHERITANCE
Again I beg your indulgence if this is not news to you, but perhaps it will help to read it once again. All web browsers read their instructions (HTML) in a linear fashion. In other words, the browser reads and responds to your coding one line at a time from top to bottom. It's all one super long string of characters as far as FireFox is concerned and it knows nothing about frames, styles, or layouts. Thus, because it's all read in a sequence from top to bottom, the order in which you state things is important. If you code your footer first, it will appear at the top of your web page and not the bottom. Calling it a footer means nothing to your browser. You can specify a position on the bottom of the page, but all the styling and specifications for that footer will be read first. That means, anything you code about this footer and is inheritable will be propagated down to the rest of the page in spite of it's visual location at the bottom.
The serial interpretation of code may be obvious, but inheritance is a little more tricky. Body {color: blue;} for example will make all the text within the body of your web page blue. You may change fonts and colors in the middle of the page, but the blue text is inherited by EVERY element unless you style that element separately. Inheritance is a nightmare and a half when it comes to floating images on multiple column pages. Read up on the CSS clear Property and be aware of how it is inherited just like my example for font color. Here too not every browser handles it the same way, and apparently mobile devices don't want it at all.
Multiple CSS sheets are permissible. Keep in mind that style sheets are read the same way as is HTML, one line at a time in sequence from top to bottom. I use this to my advantage while troubleshooting.
Code: Select all
body {
color: blue;
color: red;
}