Mobile Friendly

[yogi]

We touched on this topic and how it applies to our home page in another thread. Here I am providing a link to Google's explanation of why they are changing their search algorithm and how they are making measurements to determine mobile friendliness. Basically they figure more than half the world is now viewing the Internet via mobile devices and Google is just catering to the majority's interests.

The changeover date is April 21, 2015 and your web page will be tagged if it does not meet the standards by that date. A link in the article directs you to a mobile-friendly test page to see if your content will pass the test. They offer suggestions if you fail. In spite of some major changes, our home page still is sub-standard. At least now I can see why Google thinks so.

Mobile-friendliness: http://www.reactivegraphics.co.uk/google-responsive/

[Kellemora]

I ran both of my websites through the test. BOTH FAILED, hi hi...
But for reasons which are most illogical, because I've looked at my websites on large and small cell phones. The smallest had a 1-3/8" wide by 1-3/4" tall screen and it was perfectly readable.

My Errors:
Text to small to read.
Links too close together.
Mobile Viewport not set.

Naturally a SNAPSHOT of my landing page would be too small to read, which is why the Text is FLOWABLE and EXPANDABLE to meet the needs of the device it is viewed on. It is perfectly readable on even the smallest of view screens, simply because the text size is automatically increased by the device.

Have no idea what they mean by Links too close together. I have an INDEX on the left with an empty text line between each internal link.

If you set the text size of your web page to be readable at 1-3/8 inches wide, it would be unreadable at 15 inches wide and look downright horrible.

Based on their criteria, I don't see how ANY website could pass their ridiculous test without being UGLY AS SIN...

You can't take any 12 inch wide page of anything, shrink it down to 2 inches, and expect it to be readable.
This is the reason I used Flowable/Expandable Text in the first place. So the USER or DEVICE selects the font size of the text.

I guess the Internet is going BACKWARDS Again, having to maintain separate web pages for different browsers and now for different TOY devices NEVER INTENDED to take the place of computers, but they try.

Going to go do a test and posting this first so I don't lose it.

[Kellemora]

You are going to LOVE THIS...

Google's own search result page FAILED THE TEST...

When I tried another Google page I got this instead.
"The requested URL redirected to https://www.google.com/search?q=Home=h which is disallowed by robots.txt.Dismiss"

I guess they don't want you to know they DO NOT COMPLY with their OWN Test, hi hi...

[Kellemora]

I ran another test, and Google really does play DIRTY POOL.

Checked this page: https://news.google.com/

It PASSED THE TEST, however, the page it showed was NOT the page I tested.
It showed an entirely different page which looked NOTHING LIKE the page the link goes to.

So I can assume from this, Setting The Mobile Viewpoint, is only a REDIRECT to a different web page where things are set up differently. Sorta like we had to do for IE users and their lousy browsers.

I know what I can do. I can set a Mobile Redirect Page, that states, website is viewable on Wrist Watch size view screens, but it is not done the Google Way, hi hi...

Thanks for the links Yogi, I did bookmark them!

TTUL
Gary

[Kellemora]

Had to get these two images to show you what I mean.

The first image shows the page I ran through the Google Mobile Test.
The second image shows a totally different page inside the little cell phone window.
Probably because the first page with its TINY TEXT could never pass their own test.





OK, I'm done agitating you to death, hi hi...

TTUL
Gary

[yogi]

I just spent a few hours on our home page and got it to pass the test. I learned more than I wanted to learn in the process. I'll be happy to share some of what I discovered in the hope that it might be helpful to you.

First and foremost is to understand what Google is talking about. There is a huge difference between rendering a web page in all browsers verses rendering a web page in all mobile devices. The warning I received from Google has to do with mobile device rendering, not browser rendering. Thus, compliance with W3C standards is irrelevant. Well, not totally, but it's not those standards that Google is concerned about here.

Google prefers us webmasters to employ a responsive web design strategy. This strategy uses one set of coding to make a page readable on any and all devices. The alternatives are to try and detect what user agent is viewing your page and then redirect them to some other code that is appropriate for their mobile device. That appears to be what is happening in your graphics, but is it? Mobile devices themselves can rearrange web pages to optimize viewing. What Google will be flagging is those pages that cannot be handled by the internals of certain mobile devices.

So, exactly what messes up mobile rendering? A lot of things can do it, but this article narrows down the top five.

1. Blocking CSS or JS Resources
2. Using Too Small a Font Size
3. Placing Buttons Too Close Together
4. Not Making All Pages Mobile-Friendly
5. Content Is Wider Than the Screen

Just about all the errors in this article were found on our home page.


There is something called a viewport meta tag. This is one of those meta statements in the header of your web pages that usually make little sense to humans but has a huge impact on browser, and mobile rendering devices in this case. Basically it sets a frame of reference from which the device will render your web page. Without the statement most devices make a best guess, but don't always get it right. Thus it's important to set the standard in the header of your web page. Adding one line is all it took for our home page:

Code: Select all

<meta name=viewport content="width=device-width, initial-scale=1">

VIEWPORT REF: https://developers.google.com/speed/doc ... reViewport
VIEWPORT REF: https://developers.google.com/web/funda ... responsive


The recommended standard font size from Google is 16CSS pixels; not points, not ems, not a percentage. 16px is the spec, and it gets put into the body tag of your web page:

Code: Select all

body {
  font-size: 16px;
}

.small {
  font-size: 12px; /* 75% of the baseline */
}

.large {
  font-size: 20px; /* 125% of the baseline */
}

If you need to vary from the standard, the you can create classes to suit your needs. Our web page was simple enough so that I did not have to scale the font beyond 16px, but I did use the <h1, h2, and h3> tags to render something acceptable to my eyes.
FONT SIZE: https://developers.google.com/speed/doc ... eFontSizes


LInks too close has to do with people who have fat fingers and are trying to use a tiny screen to tap on links. The problem is not reading the link text but being able to strike the area of the screen that will take you where you want to go. When using images for this purpose it's easier to get the spacing correct, but our home page had textual links as well as images. Changing things to the standard font size as described above fixed the text links as well as putting each link into a <p> tag of it's own. In other words, two line feeds between each link. This problem was almost self-correcting for us, but I did change the image links as well to better reflect the new structure of our web site.
TAP SIZE STRATEGY: https://developers.google.com/speed/doc ... ropriately


Keep in mind that all of this is important only if you need the visibility and want to optimize your site for search engine indexing (SEO). A small personal site with a limited audience may not benefit at all from this kind of optimization. But if your livelihood depends on the traffic through your site, you better learn all you can about what Google is doing.

[Kellemora]

Thank you Yogi

This response and the links are an amazing help at understanding and to help changing what needs to be changed.
My image links are the only ones that lead to other peoples web pages, advertising for them, and I would probably be best served by eliminating all of them. At the time I placed them, the algorithm gave you a boost of for having links, but not so much anymore.

My authors web page, when using Google Search and my pen name. I am the only one on the first three pages of hits, and dominate the fourth page of hits. Most people only hope to get mentioned somewhere on the first page of hits, and the nearer to the top the better. I've never done anything special to get the hit coverage I get, other than to be active everywhere. My landing page is and has been in the top spot on a search now for over a year, and I would like to keep it that way. I'm getting very close to releasing the first novel in the long series, three years after my expected release date.

What kills me is I've looked at my own web sites on very tiny viewscreens and it looks just fine to me.
I will study very closely all the links you provided and I guess I'll have to update my websites or lose my place on the hit boards.

Want a laugh. As I said, I cover over three pages solid of hits. Yet Google+ will not let me use my pen names first name on Google+, I have to use the letter D instead, or I get an INVALID NAME warning, hi hi...
One would think someone who has three full pages of hits on Google Search would be recognized as Valid by Google+.

Thanks again Yogi

TTUL
Gary

[Kellemora]

Man Oh Man Yogi, have you opened a can of worms for me to deal with, hi hi...

I have been studying ever since I left here, and missed doing most of my evening round of work.
It also looks like I'm a LONG WAY from Optimizing my Desktop version before I can start on getting the Mobile part acceptable. They are interactive, so if the Desktop is not up to snuff, the Mobile never will be.

The very first thing I hit was I had no image or css expiration dates.
Spent hours trying to figure out how to add an expiration date to my images.
The only way I could find to do this was using the hidden file .htaccess a server file, and I do not have access to Comcasts Servers, hi hi... OK, so after a bit of studying I found I can upload my own htaccess file, and how Comcast suggests we do it. So far so good. Then I had to learn what it is, what it does, and how to use it.

Before I can consider getting to the Mobile things I need to do, I have to handle ALL of my Desktop issues first.
These include: Leverage Browser Caching, Enable Compression (not yet studied much), Optimize Images, Minify HTML, Minify CSS, etc.

I did find on the pages you sent me to, a handy little tool which Minify the Images and CSS, I don't use JavaScript so no worries there. Have not found a tool to Minify XHTML yet.

Plus I need to ask you about Compression, which I may or may not have figured out.
It doesn't seem logical to use gzip to zip everything into a brown box that needs extracted.
However, while studying the ways to use .htaccess, I ran across only one that contained the following lines.

*****
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml text/x-js text/js
</IfModule>
*****

My thoughts on this I hope are this simple, but the way my luck goes, probably not.

Since most of my Expiration Problems can be handled by a few lines in .htaccess using

*****
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ETC.
*****

Is it possible that my Compression Problem can be handled by the gzip code shown first above?
Naturally I will have to add things like PDF to it, and remove cgi-script and javascript since I don't have those.

I know from hanging around with a few gaming programmers that they keep two program files, one is complete with all notations, indents, and line spaces for clarity. The second one is the run file, which has everything not necessary removed from it, which makes it almost impossible to read, but speeds it up considerably.

Based on what my Minify of the CSS looks like, I will now now have to maintain two whole packages. My working full size file with notes, indents and line spaces, and the file I Minify before uploading to the server.

Once I get my website to pass the Desktop tests, then I can move on to the Mobile tests and deal with those changes.
W3C Tutorials never brought up any of this stuff when I was building my new websites. But at least by using XHTML/CSS STRICT I managed to get every one of my pages perfect and error free.
I'm have a whale of a time figuring out this 16 CSS px bit. It shows some of my 18 px fonts as only being 2 CSS px in size. This will be a whole new field I will have to study to see how to fix, without messing up my entire web site. I used what naming methods W3C required for STRICT, and apparently they are not compatible with Google Mobile.

On the bright side, I am learning. But with no one to answer my dumb questions, it takes ten times longer for me to figure out how to even ask the questions at all. Like my directive to "Enable Compression" suggestion gzip. I know how to zip packages, but don't think that is what they mean, so am hoping the .htaccess codes is what they meant. Fingers crossed.

Broke or not, I feel a donation to BF is in order once again. Thanks for all your help.

TTUL
Gary

[yogi]

Oy - you have more than a can of worms there. You got the whole farm full of worms.

Let me preface this by saying that I never had a need to modify the blank .htaccess files provided by our phpBB software. We also have one in our root directory that I've ignored entirely. I can see why image expiration dates and compression methods might be important on large web sites, but I've never been flagged for either of those and thus never looked into it.

.htaccess is a directory control file. Most likely your hosting service put one in your site's root directory, and they certainly have a global one for their entire server. This is good because it means their server supports this means of control. There are servers which do not. The .htaccess controls which appear in subdirectories override the global settings made at a higher level in the hierarchy. Thus it is possible to have layered levels of control over your site's directories. There is a protocol for coding instructions and you discovered the best way to become familiar with it. That would be to copy and paste something written by a coder who knows what they are doing. Simple modifications such as adding mime types or changing compression methods would work well in these pre-written code modules. You are on the right track there. The only other alternative is to spend quite a lot of time learning the basics from scratch and inventing your own code tricks.

Given the time constraints imposed on trying to become compliant as quickly as possible, my personal approach to fixing .htaccess problems would be the shotgun method. Make a change in the file that seems logical to you. Then run it through the verification to see if the flag was removed. Then test the actual control to be sure it is doing what you want it to do. Repeat as necessary. In the case of image expiration times, be sure images are being loaded from cache instead of being downloaded from the server before they expire. This is an issue only if you have a lot of large images that take a long time to download. Fetching them from cache unloads the server and makes the images appear a lot quicker in the client's browser. No, I don't know why Google would care, but keep in mind they are interested in providing their customers with the best possible experience. Pages that download quick are a good experience, not to mention a good programming practice. I'd further guess that we were not cited because the images on our home page are very small and do not affect download time.

Let me say a few words about SEO here. I know the importance of appearing on page one of Google's search results; page two or three isn't bad either, but forget it if you are further down the list. Ask yourself if you are concerned about the wrong thing regarding your site's visibility. For example, go to one of your neighbors and tell them you will buy them a beer if they find our web site in a Google search, but don't tell them the name of our web site. (I'll gladly reimburse you for the price of the beer if they succeed ) I'm confident we do not appear anywhere near the top when people search for general discussion forums, chat sites, or any other generic description of what we are doing here. However, if you tell them to search for brainformation.com, we get quite a display all over the first page. Think about your target audience. Are they searching for your pen name or for something generic that would lead to your pen name. If I used keywords such as "fantasy fiction" where do you suppose your site would show up (assuming you write fantasy fiction)? My guess is that most people who you want to see your web page don't know who you are so that you need to optimize your site to something other than your pen name.

Many hosting services offer tools which will allow you to analyze the traffic on your web site. Those tools will tell you quite a few interesting things above and beyond how many page views and hits you get to your site. The question is how will that traffic be affected if your pen name is no longer indexed, or is flagged as unfriendly. Well, if nobody is searching for your pen name, your ranking will be unaffected. If only a few people find your web site regardless of what they are searching for, then your deadline to optimize is not as tight as you think it is.

And now a few words about responsive web design. You are not following that strategy and I don't have to see your web site to know it. Google would like you to design your site to that standard because it makes life better for their clients, but at this stage it would be utter disaster for you to switch layouts. Briefly speaking a responsive web site design is one that uses a single URL and a single set of HTML (et al) coding to render your web pages. As you are discovering, maintaining a separate block of code for mobile and desktop rendering is a nightmare. Would it not be nice to be able to fix everything in one place instead of trying to make ten pounds of web page fit into a five pound mobile device? Obviously changing strategy before Google's deadline would be impossible. But, do think about it going forward.

Minifying code would be part of the new strategy, but it's a matter of elegance for the most part. Code can be written using labels and variables that are self explanatory, or at least give you a hint about how to derive what is going on in the software. Embedded comment lines are good, but should be brief and sparse. Again, the issue here is download time. The server has to read all this stuff before it knows what to do with it. So if you have more comments than you have coding, then the server is wasting a lot of time. I still don't see why Google is interested in such things other than to provide it's users with high quality web sites. Should they be looking at quality instead of content? Well apparently they think so and they are big in the search engine field. I'm sure you can minify many things simply by using best practices in your coding. That may be all you need if your site isn't too complex. Otherwise, dual sets of coding (or possibly a flow chart) is what you need.

A 16px font size standard is probably the easiest problem you have to solve. All Google is looking for is your statement of a standard. What you do after that is not their concern. Thus in your <body> tag state the standard font size as shown in my example above. If you really want to know the nitty gritty of it all, look here for advice from Google. There is a price to pay for making that standard font part of your body tag. It will affect the appearance of your text throughout the entire body of your web page. You may have to make adjustments elsewhere on the page, or in your style sheet, to override the standard.

And I know you don't need any more problems, but it might be interesting to run your web page/site through a critical review. These guys are selling a service, of course, but the free analysis is worth the read. It expands upon what Google is telling you and might give you some ideas about how to go about improving things.
WOORANK: https://www.woorank.com/

Speaking of free service, donations are not required to take advantage of what I have to say here. I appreciate your good thoughts and your contributions to our content. That is more than enough compensation.

[Kellemora]

Hi Yogi

Got your PM, thank you!
Between yesterday afternoon and this evening, I have read every word of the Google Developers website, including many of the links. Plus viewed several websites about htaccess.

Although I based my Authors website on my Personal website to save time, my Personal website has a lot of redirect html pages, just in case folks used my old website access names to certain files. I think I can finally eliminate all of those.

Let me ramble for a bit here. I'm hoping not to have to use htaccess because...
I'm not running a server, but can open and view my website on my own computer to see how it looks before I upload it to Comcast.
Almost all of my font sizes are already in percentages, but I'm so rusty, I forgot where I defined the base font size.
Without making any changes to my existing web pages, I ran each xhtml page through a minify tool and saved them in a new folder and file for testing purposes. I also did the two CSS pages associated with them.
I saw no difference in the original vs the minified versions in how they displayed. So I assume the tool merely strips out all the excess.
I didn't try it, but I doubt placing a .htaccess file in the root folder for my web page would have any affect on my computer displaying the file, so I would have to upload it to a server to see what happens. I could make my own server again, but that would require yet another learning curve to overcome.
Since font sizes are handled in the CSS style sheet, I can work with this with no problems.
I can optimize the images and possibly figure out what they mean by the 1 block in my css.

Now it seems to me, since my web pages are hosted on Comcast Servers, they would be the ones to enable compression on the files they send out. And since you don't mess with the htaccess file yourself, I have to ask, how are you adding expiration dates? Or is this something your host provider is doing for you? I have not found a way to do it without using htaccess yet, but I'm still looking. I found absolutely nothing on W3C regarding same.

One last thing, already asked in my last message, has to do with the gzip code I showed. Is this how it is done, using htaccess, or am I barking up the wrong tree? Perhaps I have to manually compress the file another way, something else to have to learn.

At this point, I don't know the questions to ask. And if you are not having problems, perhaps I should just go through all the things I can under DESKTOP and then try some tests before hitting the MOBILE tests.

I did find in a comment on one of the website forums I visited, one guy lucked out big time on his personal website.
He just added the meta line for the viewport on his Index.html page, and added the base line 16 px on his CSS and his page passed, and he has NO htaccess or expiration dates on his images. All of his images are small, but there are a lot of them. So go figure, hi hi...

One other problem is probably the breadcrumb I think it's called. Where I show the path and page the viewer is on, so they can jump back more easily. These are all links back to the previous pages, and purposely placed together.
Oh Well, shame I don't understand this stuff and just learn what I need to long enough to complete a task.

Have a great evening. I'm going to be studying and trying stuff, hi hi...

TTUL
Gary

[yogi]

Gary

I think this quote from a relevant web site can say it better than I can:

What is .htaccess?

.htaccess is a configuration file for use on web servers running the Apache Web Server software. When a .htaccess file is placed in a directory which is in turn 'loaded via the Apache Web Server', then the .htaccess file is detected and executed by the Apache Web Server software. These .htaccess files can be used to alter the configuration of the Apache Web Server software to enable/disable additional functionality and features that the Apache Web Server software has to offer. These facilities include basic redirect functionality, for instance if a 404 file not found error occurs, or for more advanced functions such as content password protection or image hot link prevention.

In other words, .htaccess may contain instructions to the Apache Web Server and modify it's behavior in some ways. You are interested in exactly what it is that .htaccess can modify, and to answer that question I'd refer you to the table of contents from said web site:
http://www.htaccess-guide.com/

I don't see anything in the table of contents that suggest .htaccess can specify what form of compression to use. it makes sense not to burden the server with the task of compressing and un-compressing what it is serving. All a server does is serve. If a client is asking for a .gzip or .tar or .rar file, the server normally does not do the compressing. It only looks for the file that has been specified and servers it to you.

Having said the above, you can specify mime types. This associates an application with a file extension:

• AddType application/zip .zip

This tells the Apache server that any file with a .zip extension belongs to the application called zip. Well, that is perfectly understandable but looking through all the .htaccess files on our web site I see no instruction to add .gzip (our download format) to any application. That means our server is not running compression software and it's up to me to figure out what to do with xxx.gzip, not up to Apache.

The coding you posted for .htaccess asks the server if it has a mod_gzip.c file - a gzip config file. If it does exist, the rest of your code sets parameters for that file. I don't know what the DEFLATE is all about, but the query is the same. If the config file exists on the server, then an OutputFilterByType is specified. These lines of code imply that the server will run compression software on its side, but actually doing that in practice would surprise me.

As you probably know, every browser has a setting to determine expiration times for the content it renders. It may seem reasonable for a web server to also set limits. But, since the image cache is on the client side, I don't see why the server would care about expiration dates. It knows nothing but to serve when asked. Thus the expiration time for images probably is not required to be stated in .htaccess. That would be one way to control loading of the server, but our (Apache) host apparently doesn't need it. Therefore I'd suggest you contact Comcast tech support and ask them about it. While you are there, ask them about those compression settings that Google can't find.

That comment you found regarding the simple fixes could have been written by me. I did three things to fix our home page.

• I created a separate directory for home page images because I don't want Google poking around our site resources.
• I added the meta tag for viewport.
• I added the font size specification to our CSS file.

Of course I had to move the images from the standard /image directory to the new image directory. My HTML is written so that each section of it can have it's own font specifications. Placing an acceptable spec in the <body> tag is just a formality in my case, but it satisfies the standard requirements. I did in fact change font sizes after I added the standard, but that was nit picking on my part and not a requirement for rendering the page.

[Kellemora]

Hi Yogi - Well I guess I don't have to worry about learning how to use the htaccess file, comcast does not support the only two things I thought I needed it for. They also do not allow any side server scripting on personal pages. Yet the instructions they provide say to upload your .htaccess file as htaccess.txt, then after it is uploaded, rename it to .htaccess and it will disappear but still be there. I've since learned anything in the htaccess file calling for a mod file is disable on personal pages. Blocked by this is password protection and gzip. With modules blocked, so is Expiration dates. So therefore, I have nothing I can use the htaccess file for.

Trying to comply with Google Mobile Friendly requirements seems impossible except for those who own their own servers. But to get as close as possible, right now I'm doing things I probably should have done long ago. Making sure the image files are the size I indicated in the display lines and not larger. Then I go use a compression tool to compress them even further. Plus for SEO reasons, renaming each file to what keywords fit it best, including in the alt text area.

Rather than my authors personal website which is fairly clean, I'm working on my old personal site about me. Because, when I upgraded my site from HTML to XHTML/CSS there were hundreds of links to my original website file names. So I maintained all the old names and locations but with a redirect to the new upgraded pages. I can remove every one of these old file placeholders and get rid of their redirects now, since enough time has lapsed and I see no hits to them anymore, despite all the links still appearing when I check who linked to me.

I have not seen where adding the font-size 16px in the body has caused anything on my page to change at all, nor the meta-name viewport line in with the other meta lines. But then I've not uploaded it to a server yet either.
I guess I could install server software back on one of my computers, but that don't mean I would know how to use it, hi hi...

Comcasts commercial pages have a standard htaccess file added to each users page, which already defines the most common items with the normally selected options, and most users have no idea it is there doing it's thing.

After I get my personal site cleaned up and uploaded again without all the garbage, and have made the minify of each page, I will then try the Google test again and see what happens.

I have no idea what I'm going to do with the PDF pages I have on both websites. They work fine on computers, because the PDF reader is built into the PDF page display. It does not download and open in their own PDF reader, but works on all web browsers, but not on Mobile.

I wonder if there is a way to not show to Mobile Users the link to the file containing the PDF files?
Sorta like something we had to do with IE users to see a different page. But we cannot use redirects for mobile, hmm.

Thanks for all your help Yogi!

TTUL
Gary

[yogi]

Thanks for the update Gary.

Would you like the name of the hosting service we are using for Brainformation? We do not seem to have the problems that you are experiencing with Comcast. Actually, that might not be a good idea. Our service obviously has set up their servers with different parameters than Comcast's. You would have the same problem if you installed Apache on your own computer because you would not know what settings they have set and could not duplicate the problems. It would be interesting, however, to see how many of your flags would disappear on some other server.

Yes, you can use something like javascript to sense what browser/device is being used to view your web pages. Then you can redirect viewers as necessary. That is not what responsive web design is all about, but it does serve your purpose.

[Kellemora]

Hi Yogi

The problem I would have with moving to a different host is I had to drop my domain name when I went with Comcast a decade ago now, and use their domain name. When I requested they set my site up using my domain name, I was told at that time that Personal Webpages cannot use our own domain name, I would have to get a Commercial Web page. Needless to say, the cost was most prohibitive.

There was another glitch also. When I got my domain name, I obtained it through my hosting service, which meant THEY owned it, not me. They would be glad to sell it to me for like 250 bucks, or higher,and that was more than ten years ago. They based the sale price for the domain name on your websites activity I guess, as some companies paid almost a grand to get theirs back.

It's just one other thing I had to learn the hard way.

I heard new rules prevent people from buying up hundreds of domain names, because they have to use them or lose them. No more keeping them forever for a dollar a year, hi hi.

When I did follow the right channels to obtain a domain name, I did a search and found the one I wanted to use was open. But I didn't get it right away. Big mistake, because folks are following those searches and buying up the names searched for. Then they contact you wanting to sell it for big bucks.

You're going to love the reason I stopped in tonight before heading off to get some shuteye.

The meta viewport tag you showed above, as well as EVERY SINGLE ONE I found on-line is ERRONEOUS...
Well not exactly erroneous for the SLOPPY coding which is allowed in HTML5.

I use XHTML/CSS STRICT which allows for ZERO Errors.

The one you showed above was written like this
<meta name=viewport content="width=device-width, initial-scale=1">
It fails W3C for html transitional with 2 errors, and strict with 5 errors, but passes for html5

I found a couple on-line written that way, but the majority were written as follows
<meta name="viewport" content="width=device-width, initial-scale=1">
This one passes both html transitional and html5, but fails strict with 2 errors.

The one I have to use in XHTML STRICT is shown below
<meta name="viewport" content="width=device-width, initial-scale=1" />
It passes all tests for html transitional, strict, and html5 with Zero Errors and Zero Warnings.

I have no idea if it will pass Google's own Mobile Friendly test, since their page shows it the way you posted it.
I have found most examples given on-line are usually wrong in one way or another. In books also for that matter.

Have not found a way to add expiration dates, or global compression. But did learn this is something your provider or host is supposed to have set, and not left up to the individual users.

Well, I'm off to hit the horizontal. It's been a long day.

TTUL
Gary

[yogi]

As you may know, the server rental for this web site is under $10 a month. It's what they called a small business plan when I picked it up. The hobby server I was on previously was nearly three times the monthly fee. Go figure. My hosting service also runs a domain registry service where a two year lease on any available name is about $20. If you want to add anonymous registration to that, you can double the price.

I also have web space provided by my ISP. That is restricted in much the same way as you describe your Comcast account. It was so primitive that I've abandoned it, although there still are a few thing up there from days gone by. I know you are on a tight budget, but I'm thinking you could get a lot better service for a minimal price these days.

The viewport metatag I gave you was right off Google's developer site. It's a perfectly valid structure depending on the DocType you use with your web pages. Google is a big fan of HTML5 so that I'm not surprised they would suggest tags that are not self-closing. It turns out that the W3C validator (and Google's for that matter) are not perfect screening devices. They are both flagging some embedded javascript code on our web page for reasons that are valid only if it were HTML but not a problem for javascript. Apparently they can't determine if what they are validating is not HTML.

RE: SELF-CLOSING TAGS: http://xahlee.info/js/html5_non-closing_tag.html

[Kellemora]

Hi Yogi

Not to long ago I took a couple of my web pages and changed them to simply HTML doctype which made it read as HTML5.
I saw no difference in the displayed pages, except for one image which now filled the width properly, when before it wouldn't.
Running it through W3C with that doctype produced no errors.
I uploaded a really old page which used obsolete tags I couldn't use in XHTML and never found a way around not having the use of that tag, without rewriting the whole page in html. I wanted the page to look typewriter written because of what the page was for.
Using HTML5 or the doctype HTML with nothing else, it too passed the W3C test with zero errors.

Because of a couple of new things you can do in HTML5, perhaps instead of sticking with XHTML STRICT I should use HTML5 and not be so picky about having a perfectly coded page.
It looks like I'll have to go that route anyhow if I ever expect to get my page Mobile Friendly, since Google considers proper coding an error, hi hi...

I could move my personal webpage to almost any server without a loss of followers, and Google Searches would find it fast enough. But my authors page took over a year of work for Google to place it as the only hits for the first three pages of Google hits. Once I was dominant on page one of Google hits, visitors to my website soared exponentially.
And I didn't even make good use of SEO keywords in places which would have helped considerably. Correcting those when I redo my authors pages. For me, I'm having to learn all over again. Thankfully I made many notes in my html and css files to remind me why I did something a certain way, usually to overcome a bug in the html language itself.

One example is to force a line feed within a <ul> or <ul> <li> statement.
The right way to create a line feed is an error when used within <ul> statements.
But you can force a line feed by using </ul><ul> to stop and start the <ul> over. This generates a line feed, even though it is not supposed to. Also, in XHTML you have to drop the first </li> when followed by <ul> statement. Then close it at the end. So moving from HTML to XHTML had its own set of problems, but ran perfectly when finished.

HAVE A QUESTION HERE - A little commentary first though.

Stumbled across some forum posts while I was searching expiration and compression which talked about changing the width of your desktop webpage so someone using a desktop has to zoom out to 200% for it to fill the screen, as a trick to get Google's Mobile Friendly test to quit saying text too small.
I thought about this for a moment, and if you zoomed out to 200% and set the page width so it didn't cause a scroll bar, the text is humongous and you would have to make it smaller yet.
I happened back on the same page an hour later and someone gave the same advice, except sorta in reverse.
You set page width narrow enough so at 200% the page fills the screen, but when you are adding content, you do so with the page displayed at 50%. Of course the display size for the page is set to automatic or 100% of screen width.

If I zoom to 200% on my websites, the text goes beyond the right edge of the screen, so the scroll bars appear.
If I shrink down to 50%, a lot of the text is unreadable, but the boxes, unless specified width, still fill the screen width.

If I understand what this guy was alluding to, by setting my text so it is readable at 50% zoom. It will force me to use the proper font sizes for Mobile viewing. I have all of my text flowable, so as you zoom in and out, even if the boxes cause a scroll bar, the text is still fully within the screen.

I placed the px16 on all my CSS pages, and it appears to have made no difference anywhere on the displayed pages. Nor did I find anything which over-rode text sizes, all of them are a percentage of the base font size.

The only other comments added by the posters to the forum were things like "It works for me!"

I have not played with it yet. So my question is simply. If I view my webpages at 50% and adjust the fonts upward to readable size, would that not then make the text too large even for mobile?

By the way, until I added
body {
font-size: 16px;
}
I had no declaration of base font size anywhere.
But all mentions of font sizes in my CSS stylesheets are all in percentages. E.g.
.contents p {
font-weight: bold;
font-size: 110%;
text-align: justify;
}
.contents ul ul {
list-style-type: square;
font-size: 65%;
}
.contents li {
font-weight: bold;
font-size: 130%;
}
.contents ul ul ul {
list-style-type: circle;
font-size: 70%;
}

Makes me wonder where it determined the initial font size from in the first place?

OK, I guess I didn't have any real question. Just rambling, hi hi...

Thanks for putting up with my lack of knowledge about this stuff.

TTUL
Gary

[yogi]

There are various strategies you can use when designing a web site, but the strategy de jour is responsive web design. Read up on it and learn everything you can because that is what's happening in the near future. You also do not want to discount HTML5. XHTML isn't going away anytime soon but all the development money is on HTML5. It will be the new standard not too many years from now.

Check out this link: http://mydevice.io/devices/

Do you see anything scary in there? You should if you want people who own those devices to see your web page. That first column shows the width of the displays in popular mobile devices. The width ranges from a paltry 360 CSS pixels to a humongous 1600. How in all Hell does a webmaster construct a single code set that caters to all these beasts equally well? It takes a lot of thinking, or in your case a lot of re-thinking, to get all your content visible in every scenario.

Your web page(s) probably should be constructed so that they are readable on a desktop without any zoom views. Somehow you decided what the optimum font for your content was, along with a suitable layout. Stick to it. You now have a vast array of devices that will no longer see what your desktop sees, but there is coding to take care of the problem. CSS media types seem to be the answer to your almost asked question. You will have to write different code for 360px resolution than you can use with 1600px resolution but it can all be contained in one webpage or style sheet. Here is some good information about media-at rules that will help get around the font size and zoom problem you anticipate.

I don't know what your layout looks like but the elements (frames?/columns?) will have to be collapsible in a specific order if you want it to be seen on a tiny screen. Then again you may decide to not show certain sections when the resolution is poor. All that is possible within HTML, but I would guess your original web page design didn't anticipate the problems that are creeping up now. You may have to redo the whole site in order to get your message to the largest possible audience. Then too, you will have to decide if you really want the whole world to see what you have to offer.

[Kellemora]

Hi Yogi

Thank you! I bookmarked these sites as well. I am studying all I can about responsive web pages, and as you said, am in the slow process of relearning and rewriting my smaller personal website first.
There are so many new features available in HTML5, I think it would be wise to rebuild using same.

I used the same hand-coded base for my authors website as I did for my personal website. They look basically the same, with only images and text changed. I still use the Index box on the left, and an expanded Index at the bottom.
Here is a link to my personal website on Comcast

http://home.comcast.net/~classichauslimited/

I've looked at it on my wife's Schmartz-Fone and on my neighbors small flip-phone with web access. On those two devices I've not seen any problems, it was still readable. My authors page, which has a few links as images within the Index box are too small to hit with fat fingers, so I will probably remove them as I get to working on that set of pages.

I have very few hits to my personal website, so figured that is the one to make changes to or rewrite first, then try it out on Comcast's server. I can always put the old version back up if the new one doesn't work as expected, and no one would be none the wiser.

Trying to relearn, learn anew, and redo my web sites is really taking away from my long past due writing time as well. Not enough hours in the day.

Have a Happy Easter Yogi. We have family coming over in about another half hour.

TTUL
Gary

[yogi]

Thanks for the link to what we have been talking about. Your personal web page looks normal to the average eye, but my initial impression was to want to change it immediately. Then again I'm looking at it with a critical eye instead of as a resource.

The layout is organized but definitely made for a desktop environment. All those links at the bottom are intimidating and provide very little content. That page makes a beautiful index, but it's not set up to navigate easily or to be in your face about what you really want viewers to see. I'm thinking a permanent row of button links across the top would eliminate the necessity to scroll down to parts unknown. Think in terms of tapping, swiping, and mouse gestures. The old point and click mouse is being deprecated.

I also looked at the HTML code, not any CSS, and was impressed. You did a great job of writing it considering that you claim you know nothing. The notes you included are exactly the kind of thing I often put into my own code. You seem to have a fascination for unstructured lists <ul> but I don't see why you only have one item per list. That's a hella lot of lists you got there. I know you want to change bullet types along the way, but that is what CSS is made to do. Graphic links that a fat forefinger can press on a small screen can easily (snicker) be made in HTML5. You may still need lists, but one item per list is a lot of unnecessary code.

If you are seriously thinking of changing your web pages, perhaps it would save you some time to look for downloadable templates. There is a ton of them out there and modifying existing code is a bit easier than writing it from scratch. Then again, it's clearly obvious that you are a perfectionist. Deriving it from scratch may be the best approach for you after all.

[Kellemora]

Hi Yogi

Thank you for your observations.

I agree with you on my list of links after the fold, named 'The Castle Archives.'
These were added 'by request' at the time I rewrote my website to XHTML/CSS, so folks could jump straight to the articles without going to the Paged Index first.

I don't think you could see the jumbled mess of pages in my root directory. After I wrote the new website, hundreds of website who had linked to articles on my website were now broken. So I created a page for every page linking to my website and made a redirect to the new page. I had to do this redundantly also, one copy in the root directory and one copy in an old folder name I once used. ALL of these are being eliminated as I rewrite my first draft into HTML5.

FWIW: all of the </ul><ul> lines you see, were used to FORCE a line break. I wanted to keep the Links in the Navigation Box on the left apart from each other. The suggested code to add a line break in Lists did not work. I had several things which did not work according to the text books and tutorials I followed. Many of these I notated in comments on both the html pages as well as in the css, as to why I did something the way I did. At the time, others were having the same problems.

Because my Landing Page does have the Expanded Index at the bottom, it was only placed their as a convenience for mainly two types of folks who visited my website often. Genealogists looking for names, and Amateur Radio hobbyists.

Everyone else would normally use the Navigation Box before the fold, which only has seven entries. The space between each Link was far enough, this part was not flagged by the Google Mobile Friendly test. But yes, those next to each other in the Expanded Index were flagged, because fat fingers would hit several at once, hi hi...

On my original website, the seven links on the left were across the top of the page. But I did not make them as drop-down boxes, they worked the same as they do now, taking you to a page where all the items under that heading can be found. For E.g., if you go to Floriculture, it takes you to a page with live links to 'History of Hydroponics' and 'The Tangy, Tantalizing Tomato.'

There are a LOT of links turned off in the individual index pages. This was because I had to remove old pages to add new, as my original website only allocated so much web space to users, and I had used it all up.

Oh, there is one oddity about my website I'm sure you noticed right off. My Navigation box and header was duplicated on every single xhtml page I used as an Index Page, not to be confused with Index.html in the root directory.

I talked with programmers on Tizag until I was blue in the face, trying to figure out how to write one page, either html or css which would add this navigation box and header without having to have seven nearly duplicate pages. On my authors website, I have fourteen such pages, mostly duplicate content from the Index.html page. So every time I change something to do with this area, it must be done on all seven or fourteen pages. A royal pain.
You have to remember too, I cannot use PHP or Javascript on personal webpages, which I don't know anyhow.
It is supposed to be able to be done using CSS, but nobody knew how, they all used PHP to generate their html pages.
Way over my head.

I really do not know what I'm doing. As I was writing my new website, I studied the best practices comments made on-line and tried to implement them. After I finished writing my websites, I basically forgot most of what I learned. If you don't use it daily, you simply don't remember this stuff for long. Each time I need to change or fix something, I have to study it again to get it right.

NOW, with HTML5, I see a lot of new ways to do the same old stuff, many things work differently too. Yet I've not found enough information yet to let me know how to use <nav> in lieu of <div>, or <section> instead of <div>.

As I'm converting over to HTML5, I'm not making too many changes to my layout at first. There is enough to do, because not all XHTML code works in HTML5, there are a few must do changes I've had to make. One example: In XHTML using MAILTO: blah de blah. You'll notice a Space after the Colon. HTML5 cannot have the blank space after the Colon.

I use ONE css page for my Index.html, and ONE css page for my Indexed Pages. After that, I have to use seven different css pages for the page affects on each of the seven indexed pages. Namely the background, left column, and float image. The rest of the css page is almost identical. I've been told to combine my css pages into one page for all, or at the most two css pages. I've tried this and the items not needed for the displayed html page is considered an error in the css page. Especially if you run it through the Minify process, all lines not used in the css for the page calling it, are deleted. So then if you call the same css page from a different html page, the data is not there.

QUESTION HERE: Maybe you can answer this question for me. How do you get a line space between each <li>, so fat fingers won't hit both lines? Several other programmers were using the </ul><ul> to force the line break, because they could find no other way either. Maybe there is a way in HTML5, don't know, haven't got that far along yet.

There are many things about css which causes unexpected problems. Such as a font-size for a particular line, may mess with the h2 header of a totally different area. Moving the instruction to near the bottom of the css page sometimes helps, but then it is far away from the area on the css page dealing with the area in question.

I am currently in the process of taking my existing XHTML/CSS personal website, and making the changes necessary for it to pass W3C as HTML5. This does not mean I'm changing the format yet. It is sorta like a learning process right now.
I'm not changing to the new tags just yet, until I learn what they do, where they go, and how to use them. Keeping the code more like XHTML, meaning I'm still using space /x> to end a line rather than just a > by itself. To me it makes it much more clear as to the intent of the mark, and since both are acceptable in HTML5, the proper way seems best to me, for now anyhow.

After I get all the pages working properly on HTML5, I was going to delve into what the new features do.
I'm also looking into setting maximum and minimum page widths to fit some mobile features. These will make my pages narrower on desktop computers, but one can always zoom in. Using width 100% as I have previously, if you zoom out on a desktop, those boxes stay the width of the screen and only the text and box height changes. Looks weird.

I figure I have to get the HTML5 done first, then worry about the Mobile Friendly parts later.
As you said, the Extended Index does not fair well on a little 1-3/8 inch wide touch screen, hi hi...
It would be a whole lot easier on me, not to have to keep this part of the Landing Page up.
But almost all of the Landing Page text is associated with this area of the Landing Page, and it is still used by many, to skip over the Indexed pages. They just scroll down to it, and hit the exact page they want.

One thing I went to a LOT of trouble to do, was to add the Back Buttons, and Return to Top buttons, to make my website more user friendly. Also included was the Breadcrumb at the top. At the time I converted up to XHTML, these two features were considered MUST HAVE features to be user friendly. As was the Index on the left side of the page to save having to go back to the Landing Page to get to it. In other words, I tried to use the best practices of the day. Which now appear nearly obsolete. I rarely hit a page anywhere where I can return to the top of the page without using my scroll bars to do so. Maybe on touch screens it just takes a swipe of the finger across the screen, so they are no longer needed for the mobile folks.

OK, I'm rambling, hi hi...

Oh, perhaps if you have a link to some of those Templates you mentioned, I could look at and study them to see how they do certain things. I'm taking valuable time away from writing my series to update my websites, and if I could change them now, instead of by slow improvement steps along the way. I would be ahead in the long run.

Thank you Yogi!

TTUL
Gary