detect JS with CI?

[eluser]Pascal Kriete[/eluser]
I clearly can't read, absolutely skipped the noscript snippet in your original post.

There is no really nice way to achieve what you're trying to do. If both of your css files are setting the exact same things, you could just put the big one at the top and load the other one with js.

Code:

<link rel="stylesheet" href="./big.css" type="text/css" media="screen" title="no title" charset="utf-8">

<script type="text/javascript" charset="utf-8">
if (window.getWidth() < 950 ) {
  new Asset.css('800x600.css');
&lt;/script&gt;

Or you could make two body views, and ajax update the whole body.

Neither is ideal though.

[eluser]mr_coffee[/eluser]
Yeah, I agree... I don't think there IS a nice way. I responded to Andrea's post hoping she has an "out" for when the page is ALREADY php as her method obviously didn't consider that... and she's obviously some sorta genius. Trying her method within CI didn't do anything with or without JS.

I will likely default to the 1024x768.css file... and load the 800x600 if and only if javascript is enabled and the screen is small. The only thing I HATE about that is loading the big images for the small screens first, and the short delay while the page gets resized with the graphics. Horrible waste is what that is. I truly feel there should be some way of using CI's unique features to figure something out though, but the answer appears to be out of my grasp just now. I really kind of need CI to run one line of javascript client side prior to loading the site, heh.

I'll do this FOR NOW, but I'm certain there is an ultimate solution. If you can do it on a non-php site, you should be able to do it on a php site. There IS a way. I must only keep trying till I discover it.

[eluser]esra[/eluser]
Having javascript enabled or not enabled is only one part of the problem.

I did some experimenting with this last night. Screen resolution is provided using the full dimensions of the end user's monitor in pixels, but the viewport in the browser's client window is the real set of dimensions you need. Also, the client browser's viewport size can vary in size if the client is displaying extra toolbars or lateral viewing areas like trees on the side of the client window. Viewport dimensions can change dynamically as the end user turns various browser features on and off, thus a solution needs to compensate for such changes when the end users screen is refreshed.

If I was to experiment a bit more, I would probably check to see if the client viewport's window is provided in a DOM or could be calculated from a DOM, but the DOM support in some browsers is a work in progress.

[eluser]esra[/eluser]
We use EXT JS at work for our backend applications and have been doing some experiments based on the EXT JS desktop example. These experiments have more to do with running multiple CI applications simultaneously by registering multiple front controllers with Apache (that is, using Apache's native threading capabilities in lieu of PHP's lack of multithreading support). However, the operation of the Windows Desktop example suggests some interesting possibilities.

This example mimics a Windows desktop, allowing multiple windows to be loaded within a fluid-like desktop template. I myself have really not looked at the underlying code, but the embedded windows seem to be positioned within the fluid-like desktop window based on the coordinates of the upper-left EXT JS viewport and the full dimensions of the viewport. The embedded windows in the example are centered but could appear with their upper left corner positioned using absolute coordinates. Generally, this is not the kind of user interface a end user would anticipate seeing in a frontend, but it might be possible to adapt their Template solution to meet your needs. EXT JS also provides a solution for storing Window states (last position, maximized, minimized, etc.). The example code for storing states in a datastore might prove useful since server-side sessions are not used.

[eluser]mr_coffee[/eluser]
Actually... the window.getWidth() function I'm integrating from mootools grabs the view size of the browser... not including the scrollbar if it is there. This is why I set the midrange number of 950 to check for. I'm guessing at the size of a window not fully maximized. Really... I could set a more conservative number like 900, or even 820. All it has to be is a number that would be larger than someone with a screen resolution of 800x600 could have. I'm not really interested in modifying the dimensions of all the graphics and proportions of the site based on every conceivable size of the browser window, though I might integrate some really crazy proportionate math later to do just such a thing. But I'd need JavaScript to help with that, so for now I'm just trying to effort a way to find out if JavaScript is being allowed by the browser first. If it isn't, I want to default to CSS that just doesn't care.

In this case, that CSS is going to be the largest possible size. Make those jerks with JS disabled scroll. And that's fine. But yeah, currently... I'm not concerned about every in-between size and getting it all pixel perfect for widescreens, etc. It's pixel perfect for 800x600 or 1024x768, maximized in both cases. But yeah, if I wanted to get really clever I could have javascript resize the images, margins, spacing, etc... proportionately based on viewable browser width. And I'd use the mootools function to come up with that number since it's giving me the actual size of said viewport.

But my bottom-line issue - I've determined - is if there's some method of getting CI to make a call like this:

Code:

<script type="text/javascript" src="cssFilter.php"><!--// CSS Filter //--></script>

from a "view", and actually have the php on that page performed before proceeding to the next line. There doesn't appear to be a way to get CI to pause and let that code run and then go on from there... but maybe I could sneak something like that into the controller somehow? If so, I could have that php file set a variable, and then the site would "know" that javascript was allowed from that point on, thereby I could impact how the rest of the site was assembled.

I'm really just wanting it to degrade nicely for browsers that have "allow javascript" unchecked, that's all. As far as the CSS selection and all that, it's handled quite well with javascript. But if there isn't javascript to manipulate the page... I will want to sneak in some CSS for those uncooperative souls who will deem the site unusable.

And - if you haven't gathered from my dripping sarcasm that is pooling at the bottom of this page - I am one who strongly believes there is no 10% that "can't" view javascript. I implemented javascript on a site that didn't "allow" javascript use, and manipulated a browser that not only had javascript "disabled", but also had NoScript blocking both that site and the site I had the javascript on. Still ran. Even cell phones have javascript engines built in... if there's an actual browser that doesn't have javascript functionality built in, it's installed on a hard drive that met it's expiration date 4 years ago. The only thing is I'd like the code to validate in the end. If I didn't, using <noscript> in the head would suffice.

It's unfortunate that my site wasn't for some mega-corporation like Micro$oft. Because then I could use all the buggy invalid code I wanted and users would just have to get over themselves and enable javascript to view the page as intended, and they'd automatically know that was the issue on their first visit. Unfortunately, I am not in such a position.

I'd still like more suggestions. Yours is a good one... just not for the issue I'm trying to solve.

[eluser]xwero[/eluser]
I'm just wondering instead of creating a 800*600 and a 1024x768 css why not use a liquid layout? Use relative sizes for everything? No javascript, no php

[eluser]Tom Glover[/eluser]
[quote author="xwero" date="1209344559"]I'm just wondering instead of creating a 800*600 and a 1024x768 css why not use a liquid layout? Use relative sizes for everything? No javascript, no php[/quote]

Would seem to be the simplest, you can still specify max widths and min widths or heights to stop the page becoming deformed.

[eluser]esra[/eluser]
[quote author="mr_coffee" date="1209341847"]But my bottom-line issue - I've determined - is if there's some method of getting CI to make a call like this:

Code:

<script type="text/javascript" src="cssFilter.php"><!--// CSS Filter //--></script>

[/quote]

Not with CI but Coolfactor's old View library did allow the css, javascript and meta data for the head to be constructed using view class methods. This library no longer works correctly in 1.6.x because CI duplicates the same view loading behavior resulting in a double template load. However, it might give you some ideas.

[eluser]esra[/eluser]
[quote author="mr_coffee" date="1209341847"]Even cell phones have javascript engines built in... if there's an actual browser that doesn't have javascript functionality built in, it's installed on a hard drive that met it's expiration date 4 years ago. The only thing is I'd like the code to validate in the end. If I didn't, using <noscript> in the head would suffice.[/quote]

Most mobile devices support WAP and as a result WML and WMLscript. WMLscript is a subset of javascript based on a stripped-down version of the ECMA specification. As long as the subset of javascript was supported, the javascript should work for both.

[eluser]esra[/eluser]
[quote author="mr_coffee" date="1209341847"]But my bottom-line issue - I've determined - is if there's some method of getting CI to make a call like this:

Code:

<script type="text/javascript" src="cssFilter.php"><!--// CSS Filter //--></script>

[/quote]

Another thought. cssFilter could be a helper function. Then you might be able to do:

Code:

<script type="text/javascript" src="<?=cssFilter();?>"><!--// CSS Filter //--></script>