Detect Viewport Width Live in Javascript Pass Result to Ajax Call PHP Page

[bigignoramus]

I have been wrestling with this subject for six months and can find no complete answer anywhere on the web or in any book seen. I have become very familiar with the debate and so it is not necessary to debate the following here. I had rather do all of this in PHP, but I know of no way to avoid javascript because detection must take place on the client side, and no way to avoid AJAX because the feed is continuous and the pages fed depend on the viewport's width. Since the content of the pages will change, css at media will not work.

The object is first to create an html or, preferably, PHP page that will detect the ever-changing width of the viewport as the viewer crunches it up or extends it, and change the content of the page at two breakpoints; thus, there will be three php pages with content. I am not sure if the landing page should be .php or .html; in any case, the landing page will ultimately be the index page, and its sole function is to call or extinguish one of the three PHP includes, each of which will itself have includes and calls for the css. Both the content and the css of these includes may differ, operating on the principle of VARY HEADER in order to keep the integrity of the SEO.

In Pseudocode,the foregoing requirements become the following.

1. Detect viewport width LIVE in javascript; thus, if a viewer diminishes or increases the width of the browser, the detection will be continuous.
2. To make the detection constant, it seems that the javascript must not be cached.
3. The output of the javascript, which is width of the viewport in pixels, must be passed to AJAX because the page is dynamic.
4. I cannot find any coherent reference to conditional statements in AJAX, and I had rather avoid JQuery, but the idea is:-
   if viewport < 700 px, serve x.php;
   if viewport > 700 px and < 900 px, serve y.php;
   if viewport > 900 px, serve z.php;
   
   
   1. Since this must happen live on demand, it seems that the cache for the AJAX and the PHP pages must never be made.
   2. Whenever the viewer changes the viewport according to the above breakpoints, the PHP include will change, no matter how rapidly the viewer may do so. Practically, however, this means simply that telephones, tablets, and larger devices will each have a page tailored, both in style and in content, for that kind of device.

The above having been accomplished, the next considerations are:-

1. Is it possible to have the landing page written in php, which I doubt, because the detection ought to precede the PHP; hence, the probability arises that the landing page ought to be written in HTML.

2. Shall the html of the landing page be replaced by a completely fresh page, header and all, in one of the three called pages called by AJAX, such new page to be the usual PHP page in all of its glory? It seems doubtful, because the viewport must be constantly detected, which is the reason for the landing page in the first place. Therefore, each of the three called PHP pages must probably simply be includes that flesh out the original html page. If so, what is the best way in which to structure the code? Please see below for a statement of difficulties.

3. The first trial ought to be of simple content which, on each include, simply says something nice and gives the dimensions of the viewport live. If that works, then the frindly message and statement of width will be eradicated by replacement with the real content, a copy being kept as a souvenir for future reference.

   I have cobbled together code in Javascript that detects the width and runs it live perfectly in all of the three named devices, and during crunching and expanding on a laptop, but I am having trouble preventing it from caching, so that it occasionally sticks on contraction when I reach a width of 541 px. Most websites seem to have this problem.
   I have cobbled together AJAX code that will serve up the pages required, but I have not been able to destroy the caching.

   I have tried for many sleepless months to pass the running width from Javascript to AJAX, but without avail.
   I can present either the width or the includes, but not both, on the landing page; the AJAX overpowers the Javascript and ignores its content.I tried to put the Javascript for detection on the include, which neither works, nor has any use, because the width must go to the AJAX before the includes are called.

   Although this question has been asked before in various ways, there is no one comprehensive answer to the question to be found.

   Many thanks to any such of good will who may be kind enough to address this question with the comprehensiveness which it deserves.

[hericles]

This sounds like you've made it overly complicated.
Why are you trying to serve differing PHP pages when, if I'm reading this right, all you really need to do is return content from the server?
You could design your page to have the elements you need for the various screen sizes, if that varies at all, and on a screen resize, detect the size, make an AJAX call to the server, retrieve the necessary content and display in the relevant elements.

You keep referring to includes which are a specific thing in PHP, which makes parts of explanation confusing. By includes you are simply referring to the content to be passed back to the page correct?

You can write a PHP file that includes html elements and javascript. The server passes a PHP page to client as HTML anyway.
For example - save as file.php and run from your server:

<?php 
    echo "Hello from PHP";
?>
<html>
    <head>       
    </head>
    <body>
        <script>
            alert("hello from javascript");
        </script>
        <?php 
            echo "a second hello.";
        ?>
    </body>
</html>

Having said that, if you're going to be updating the content through AJAX the entire page can jsut be HTML as no actual PHP is required except for the end points of the AJAX calls.
The thing is I don't see this as that difficult at all so either I'm missing something or you're making it far harder than it should be.
The only thing that it should do is only do AJAX requests when certain widths are hit, as doing calls on every width adjustment is just wasteful but maybe you've already factored that in.

[gentlemedia]

For (multiple) media queries in javascript look into window.matchMedia()
http://www.javascriptkit.com/javatutors/matchmediamultiple.shtml

[bigignoramus]

Many thanks for both of your kind replies and the speed with which you made them!
yes
The issue of the php is that I should like to have the apparatus for resizing active before I call a normal dynamic php site. The "includes" part was, I apologise, a tying of the tongue; what I meant was that, when the resizing be settled, the next step would be the calling of the php files that do their usual behind-the-scenes toil and then fill the index page, where the apparatus for resizing is supposed to be, with its content.

Then, we move into mutual understanding that the Ajax is to be used to fetch the php files. For the present experiment, I should like to use Ajax or Javascript to complete the text that presents the dimensions; on the real site, these dimensions will not require presenting, but be relegated to a test page that will be invoked from time to time to ensure that the code for the finding of the dimensions is still alive - in case of trouble! As it is now, Javascript is presenting the dimensions.

You are absolutely right in inferring that the Ajax calls should occur in the real site ONLY at the two breakpoints (perhaps four, if huge screens be considered), as I mentioned in my post and as I tried to be particular about in the comments to the code below. You say most correctly that further calls on resize would be an utter waste. I should add that these breakpoints will cause the change of content in the same browser only on larger screens; obviously, a telephone will never see the tablet's size, but a tablet's browser, if crunched, MIGHT reduce to the telephonic size. Only on a laptop or larger screen will the browser be capable of displaying all three (or four, if need be and the device be large enough) sizes.

If one looks at one of many examples of resizing, such as Click Here, one will notice the clumsy manner in which it is done, and not completely done. This is the horror that I seek to avoid.

I enjoyed running your php code, and plotted a reply using it, but felt that, in the interests of saving time, I ought to keep to business. Your idea to replace the php altogether in the index page is probably the right direction, so that the detection occurs before the loading. The "alert" is one javascript call, and the other is an html one; what I was talking about was two Ajax calls.

Here follows the code.In hopes of increasing understanding, I have ncluded what they call an "exhaustive commentary". If you will be so kind as to save it under any name that you feel appropriate,and then run it, you will see what the working part does. The nonworking part is the part in question.

Many thanks for your kind attention. If we can solve the issue, I think that the solution will be a great boon to many.

[bigignoramus]

Learning to use this site. Here is the promised code.

<!--
The whole point of this index.html page is to enable resizing. CSS Media Queries are restricted to style, and so those who change content on resizing must needs have recourse to alternate methods for the attainment of their worthy ends.
    The rest of the site ought to be of the usual dynamic kind marshalled by and in php. Obviously, every page on the site will have to have reference to the code in this index page, or copies of it in each of its manifold pages, so as to enable consistency of changing content on the resizing of the viewport.
    Following the philosophy of straight HTML here, and so no need for php yet. Further, no php on this index page,  UNTIL the pieces of php be called, means that this index page will load before the pieces of php, which is better for preventing unnecessary reloading, I think.
    If this were a normal php page, an "include" would be the appropriate term, but, since it is not, the term "piece of php" is employed. What this means is that, in an ideal world, everything on the page beyond the sizing ought to appear in php in the usual php-ish manner.
    The calls to the pieces of php should happen every time this page is crunched up or expanded.
    This is where the caching becomes a nuisance, and must be prevented everywhere on this page, I think.
    When there be no cache, this page will squeeze down to 275 px. with words wrapping; with caching, the dimensions stop at 541 px. and the words will not wrap.
    So, we require here

1. Finding the dimensions.
2. Fetching the appropriate piece of php (small, middling, or large).
3. Accommodating any possible width down to 275 px. at any reasonable speed of resize (turn a child loose on it?). This seems to mean disabling caching.
4. Presenting the size not on this page, but in the pieces of php.
-->

<!DOCTYPE html>
<html>
    <head>
    </head>
    <body>
<!--
The following script will not work, at least for me, in <head>, and so it is here put in <body>. Putting it in <head> would be preferable, because then the <body>, all of the contents of which ought to be in the pieces of php, would then be cleaner codewise.
-->
        <script>
//Finding of Width and Height. Height is immaterial, but why not display the height for the fun of it?
            window.onresize = displayWindowSize;
            window.onload = displayWindowSize;
// Javascript Function for Presentation of Width and Height.
            function displayWindowSize()
                {
                    pageWidth = window.innerWidth;
                    pageHeight = window.innerHeight;
// Passing of Variables to HTML for Presentation of Size.
                    document.getElementById("dimensions").innerHTML = "This Browser's Width Is "+  pageWidth + " Pixels and Height Is " + pageHeight + " Pixels.";
                };
//The idea is to put a function here with the condition
//  if width =  < 600 or so px. load smallpage.php;
//  elseif width = 600 or so px. or so AND < 900 or so px.  load middlingpage.php;
//  else load largepage.php;
//  AND do this on every resize without reloading the page.
//In other words, the php pages should fill this index.php page, not be reloads.
//  It would thus be preferable to put the <p id="dimensions"></p> that appears below on each of the pieces of php pages, not on this html page. This index page ought not on itself to present anything.
//  I have tried this approach, but failed.
        </script>
                <p id="dimensions"></p>
    </body>
</html>
<!--
A further observation is that the three pages of external css, one each for the html of each piece of php will presumably be linked in the <head> of this page, but be applied appropriately in each of the pieces of php.
-->

[gentlemedia]

That LA times site is indeed horrendous. It's a good example of a bad implementation of Responsive Web Design. Not to talk about a Google PageSpeed test.
But... it's a massive site of course with lots of dynamic content and is not an easy task to give it a smooth RWD experience, but it's doable if you look at the Boston Globe site.

What you want with loading different PHP or HTML snippets with AJAX on certain breakpoints, can be done with the matchMedia API. No need anymore for calculating window.innerWidth/Height or for a library such as jQuery. If you need to support older browsers, then you can polyfill it for those.

But I think you go overboard with your approach as well... try to use CSS mq's first over JS mq's. If done right, you don't have this wonky RWD experience as the LA times site. Especially if your pages are not that huge as those of the LA times site.

[bigignoramus]

Dear gentlemedia, Many thanks for your further comment. I am glad that we agree on the goal. I looked at the Boston Globe's site, and agree that it is a much better implementation than that of the Los Angeles Times, but it still has its quirks; it feels "nervous". I agree also that there is a massive amount of dynamic content on each site; I looked at the HTML source code of both, and consider their programmers very brave even to have attempted the task.

I apologise for the delay in witholding comment further because I am still studying your link and making sure that I understand it, which I do not yet fully. More time this evening! It looks promising.

I object to CSS Media Queries because they are not infallible, but mainly because they do not allow the change of content, in so far as I can find out and test. I am looking for more precision, which means a manual rather than an automatic, so to speak. The trouble with w3 is that their productions seem to be a mass of compromises that often seem to defy common sense; perhaps I am too hopeful in thinking that a committee comprised of conflicting interests could devise something as simple as a detection of width of viewport followed by a simple conditional statement based on that width that allows one to serve up content styled to taste.

Actually, compared to other things that I have seen, my code is much simpler; removing the comments displays that code as very short. Not that I care if it be my own invention; if somebody has a better way, then I'll readily accept the idea. The constraints are no framework and no CSS media queries unless they permit a way to change content as well as style.

I shall continue studying your link and report.

[gentlemedia]

Changing, or serving, different content for different screen/device resolutions has never been a good content strategy. Users expect the same content on all their devices. Just prioritize it good! The only things that should differ is the user experience and usability. For example if you get really long pages on small devices, consider to convert some content for these small screens into accordions or tabs and make sure users can swipe between this content as well on touch screen devices.

For more advice on this matter head over to Jakob Nielsen's website:
https://www.nngroup.com/topic/mobile-and-tablet-design/