Google Sabotaging Firefox

Code:
Vull I have not used Apache in a long time so I don't recall the proper way to set that.

The best way to test your HTML/XHTML is using the W3C validator.

You can see what your server is actually delivering by using the dev tools in Firefox. Enter ctl-shift-C and click on Network. That should display the files being served. Click on the html one. Click on Headers on the right side and look for "content-type". If you are serving HTML, then it will list it as "text/html". If it truly is XHTML, it should say "application/xhtml+xml".
I'm serving "text/html". Switching back to xhtml at this time would be problematic at best. Dug through my notes; I switched to HTML5 several years ago, but formerly I used this and passed the W3C validator for xhtml using this:
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
Then I switched to html5 which is incompatible with xhtml, but by following something similar to these w3.org compatibility guidelines, was able to continue using a relaxed xml style syntax with xml_parse() to check each page for syntax errors, which is all I ever really cared about. I also need to serve non-xml streams like css stylesheets, js ECMA scripts, and plain text via XMLHttpRequest, and since I've already parsed my xml syntax on the server, I don't really need the browser to recheck it. Maybe I'm missing something (?) but don't see any harm in letting the browser use its text/html parser on pre-validated xml text.
 
obsigna They aren't claiming to be Safari. They're pretending.

Well, yes I am not a native English speaker and I agree, "to pretend" is actually the better verb. This is like some of these Korean cars pretending to be a Mercedes with respect to look and feel (perhaps feel and first look), anyway, the important UI facilities are all in place where it belong to, like the steering wheel, the accelerator/brake pedals and the gear change.

This has to do with applications, software and web sites which test to see which user agent/browser you are using and deliver pages based on that. Some sites will not serve anything at all ("best viewed with ...."). Removing that will actually break some things.

Of course, that’s the reason, and like the Korean Mercedes-alikes these Safari-alikes come fully equipped, otherwise these won’t be alike and the end user would complain or choose the real thing one day. This is not my fight and I don’t care, should I?

This is why it's always better to target standards and not browsers or devices but, of course, one needs to test in all of them if one wants to be 100% sure. At my place, we liked Chrome/Chromium dev tools so it got tested there first but sometimes we'd be sitting in Firefox and I'd use Firefox tools but, eventually, we'd look in both. Then Safari cause we'd have to bump the graphics guy off his machine for that. Lastly, we'd dust off the Windows machine in the corner and clean off all the spit on it and test in IE and Edge. We kept that machine in a separate room that had padding to keep the screaming noise down.

This is similar to my development procedure. Only, I develop on and test against a different set of browsers, and with respect to the standards, I tend do stay on the narrow road. IE and Edge are not on the list, but occasionally I opened the one or the other of my sites with these as well, and it simply worked. Perhaps the pages render not as beautifully, however, the whole Windows is ugly and who accepted no-kerning Arial as the Helvetica-alike for decades won’t see any difference anyway.

I'll look at the rest of your post later. Your software looks like cool stuff.

Thank you!

I'm cooking and the Blues hockey team is in the playoffs!

Good luck.
 
It's not. You may find this and this interesting reading.
After skimming through those two links, my mind is mush. I feel like I've been tag-team slapped-silly by Moe Microsoft and Curly Chrome. It reminds me well of why I dropped support for Microsoft browsers in the first place.

Clearly I was in error by claiming to still be using XHTML, so I'll just stop that right now. I must be getting senile. I'm also dropping the <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" /> tag, which is long past due, leaving me with an even simpler prolog:
Code:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="cache-control" value="no-cache, no-store, must-revalidate" />
<meta http-equiv="Expires" content="-1" />
Thanks again.

Web browser war... it seems that the winner will be the one that will manage to impose on the web market its power.
Sorry for going off-topic.

One Browser to rule them all, One Browser to find them,
One Browser to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.​

Additional apologies to J.R.R. Tolkien.
 
After skimming through those two links, my mind is mush. I feel like I've been tag-team slapped-silly by Moe Microsoft and Curly Chrome. It reminds me well of why I dropped support for Microsoft browsers in the first place.

Clearly I was in error by claiming to still be using XHTML, so I'll just stop that right now. I must be getting senile. I'm also dropping the <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" /> tag, which is long past due, leaving me with an even simpler prolog:
Code:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="cache-control" value="no-cache, no-store, must-revalidate" />
<meta http-equiv="Expires" content="-1" />
Thanks again.

Sorry for going off-topic.

One Browser to rule them all, One Browser to find them,
One Browser to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.​

Additional apologies to J.R.R. Tolkien.

good imagination...

Testament for the web and low spec machines. windows or android will tell you. Dude your hardware is too old for the web. Upgrade dude. Buy a better one to bill. Bill will be richer if you have a newer hardware. thanks again. bill thank you very much for supporting windows.

... and sorrow on mordor.
 
Vull I have not used Apache in a long time so I don't recall the proper way to set that.

The best way to test your HTML/XHTML is using the W3C validator.

You can see what your server is actually delivering by using the dev tools in Firefox. Enter ctl-shift-C and click on Network. That should display the files being served. Click on the html one. Click on Headers on the right side and look for "content-type". If you are serving HTML, then it will list it as "text/html". If it truly is XHTML, it should say "application/xhtml+xml".
A little more follow up here, just in case anyone else reading this in the future might be interested in serving pages as xhtml: PHP allowed me to serve my pages as application/xhtml+xml by using the PHP header() function to send an additional header prior to sending the actual document or page:
PHP:
header ("Content-type: application/xhtml+xml;charset=UTF-8");
... this requires PHP but should work with any webserver software. However, doing this made my ECMAScript (javascript) unusable, most likely because, as I now understand it, I'm partly or entirely using the XML DOM (document object model) instead of the HTML DOM. To serve my page as xhtml, I also needed to change my opening HTML tag:
HTML:
<html xmlns="http://www.w3.org/1999/xhtml">
... I also shortened my META tag from <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> to <meta charset="UTF-8" /> which I don't think is absolutely necessary but it's less confusing from my POV.

Once having accomplished this, I decided to revert back to serving my pages as text/html, and would like to say why. One reason is that I simply don't want to re-debug my scripts to work with with the XML DOM; it's probably quite do-able, I just don't want to take the time to do it. Since this is only a personal project, I have the ability to easily opt-out of anything I don't want to do, as well as the luxury of deciding not to support any browsers other than the ones I choose. Active professional programmers usually don't have such luxuries, and may decide to use xhtml or xhtml5 for these reasons as well as other reasons.

Another important reason for opting-out is that further research into this area (after 10 years of basically ignoring it) suggests that the popularity/market share of XHTML has declined over the past 10 years, and is now at around 14%, and steadily declining, as indicated here, as opposed to HTML5 which is reportedly over 86% of market share and growing, as suggested in that same link, and also indicated here.

I read this as meaning that plain text HTML5 is more likely to be around in the future (like another 10 years), and a little more research has suggested that HTML5 is probably going to be more stable for other reasons. Using PHP's xml_parse() function allows me to check my syntax, which was my main reason for migrating towards XHTML in the first place, and to do the syntax-checking server-side, where I can control it, as opposed to relying on the browser to do it for me. Furthermore, even if I debug my ECMAScripts to work with the XML DOM, serving pages as application/xhtml+xml will actually break the syntax-checking mechanism I already have in place, because the browser would then be unable to display the screenshot I showed in my previous post-- the syntax is already broken in the page as displayed, and so the browser using the xml parser would decline to, or be unable to, display it.
 
I read this as meaning that plain text HTML5 is more likely to be around in the future (like another 10 years)
HTML5, as discussed in this thread, is just HTML and the same HTML used since Tim Berners-Lee created it long ago with all the updates since then. The term HTML5 is an all encompassing one that includes all the technologies involved in making a modern web site but the version number "5" will be dropped eventually as it carries no meaning. Originally it was just that, a version number one step above HTML 4.01 so HTML will be around forever or until someone decides it needs to be replaced and does so.
 
Another important reason for opting-out is that further research into this area (after 10 years of basically ignoring it) suggests that the popularity/market share of XHTML has declined over the past 10 years, and is now at around 14%, and steadily declining, as indicated here, as opposed to HTML5 which is reportedly over 86% of market share and growing, as suggested in that same link, and also indicated here.

I'd be interested to know what percentage of the sites using HTML validated. If it doesn't validate it isn't considered to be XHTML.

Mine are static pages served up as:

Code:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
 
I'd be interested to know what percentage of the sites using HTML validated. If it doesn't validate it isn't considered to be XHTML.

Mine are static pages served up as:

Code:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
I still verify each dynamically-generated page using xml_parse() for XHTML syntax conformity, and most of my html-generating PHP scripts have been previously verified using the W3C validator, but I'll probably look at this further when I have more time and will most likely wind up adding a profile option for each user account to toggle the generation of application/xhtml+xml. This will provide a good exercise for figuring out what the important differences are, between the XML DOM and the HTML DOM, and to hopefully debug my ECMA conforming javascripts to sniff out the differences and handle both DOMs.
 
Back
Top