interesting tweek, i guess the only catch is that some ppl are going to have js disabled .. but thats the breaks

You could of course put your header as a background, use fixed width side bar areas (linkblog, calender etc) and then leave the middle to fill the rest of the screen.

That way you don't need Js and you satisfy 100% of the res's that people prefer to use ;)

¥

Kweb,

You've obviously spent a lot of time thinking about the visitors to your site and that it A GOOD THING.

However, I have to agree with ¥åßßå that rather than relying on client-side JS to decide the visuals (where you have issues NOT ONLY with 'is it turned on' - about 10% of folks fall in this category, btw - ... but what VERSION is it written for, what version do they have ... are any of their files CORRUPT or is there something else wrong with their installation?) ... let CSS do the work.

¥åßßå's solution uses 100% of the screen space available at ANY resolution (as determines, as it should be, by the user).

Use java, as you suggest, to optimize the header image, swapping out a different file for users with lower resolution (to OPTIMIZE the experience), but use standard server-side stuff for the important visuals (like width determination, etc.)

If you really don't want a liquid display, you can use PHP to make a CSS style switcher and let users pick the width that suits them best. (You could have a few buttons 600 | 800 | 1024 | 1120 ... where the CSS files are optimized for those widths ... and everything else is the same).

Just some thoughts.

-stk

Thanks for the suggestions, guys. However, I think I'll just stick with what I have for now. My blog is not a high-traffic site (mostly for family & a few friends) and I doubt there are more than 1 or 2 users that are below 1024px resolution. A server-side PHP version would definitely be preferred for a high-traffic commercial site, but I think it's overkill for what I'm doing.

Steve - are you possibly confusing JavaScript with Java? JavaScript is included with all major browsers and enabled by default, and although it can be disabled, I don't think many people do that (however, if they are savy enough to disable scripting, they probably are not using an 800px resolution, so they won't be affected anyway). Java, on the other hand, is a seperate install with many (conflicting) versions and I never use it on the client side unless I absolutely have to.

My main reason for not just using a 100% width is I (and other people I know) have some very high-resolution monitors (1900px +) and I think some pages look terrible when stretched to that width (not everything, though). I wish that CSS would allow some kind of minimum and maximum width so you could allow an element to expand between set boundaries (e.g. 740px to 960px), but I don't see that being added any time soon.

Anyway - your suggestions are still good ones and maybe someone else will take advantage of them.

Kweb - are you possibly confusing Steve with Scott? I didn't just pull the 10% number out of a hat, as these are statistics shows at the [url=http://www.w3schools.com/browsers/browsers_stats.asp]w3shool site[/url]. Of course, statistics are only a guideline and not gospel AND if you're catering to a select (and known) audience ... then you should adjust your pages accordingly.

You may make a distinction between the JAVA and JavaScript, but regardless, whether java applets or the browser's Virtual Machine (either MS's old and no-longer supported version or Sun Microsystem version) ... all are client-based and dependant upon the versions, file integrity & o/s install. (I just lump them together because they're all client-based).

1900+ is definately in the wide category, but I would contend (from using my 1280x1024 screen on sites designed for smaller) that I rarely go 'full-screen' with my broswer windows anyway, prefering to have overlapping windows and size each according the the page. If it looks better smaller, so much the better for me, as I resize the window to take up a smaller desktop footprint.

I still *try* to accomodate 800x600, but this is a rapidly moving target as 1024x768 is becoming more pervasive. (Again, citing stats from the w3schools ... 13% of users have resolutions > 1024x768; 13% have THAT resolution & only 29% have 800x600 (with about 5% unknown) ... so I'm making an effort for only a third of the folks). Like you say though, I'm reasonably sure that most of my traffic is higher resolution (more tech-oriented). That's why I'm not too anal about it ... I know my banner is designed for a n 800px screen, so I just shrink the width down ... have a look ... okay it works, or a move a picture down.

CSS does allow a min/max width/height ... it's just that IE doesn't support it. Statistics come into play, because about 65% of folks are using an IE product. If you knew most of your visitors were using FFox or some other product that DOES support these properties ... go for it.

PHP or Javascript, both style switchers operate in a similar fashion. It's just that I'd pick the PHP route over the other because it is server-based ... regardless of site traffic. (I didn't realize that PHP was only for high-traffic commercial sites. Why is that?)

As I said before ... thinking about your visitors experience is a good thing!

Cheers,

Scott (aka Steve) ;)

Sorry, Scott - I don't know why I said Steve. My mistake. :oops:

I did not say that PHP is only for high-traffic commercial sites. I only said that the PHP solution (as opposed to my JavaScript solution) would be a better choice if I was running a high-traffic commercial site (because of the wide-range of visitors and configurations), but I'm not.

If you read the page you linked to, they note that the stats are from their own site, and are skewed by the fact that their visitors tend to be much more tech-savy than the average website. In reality, IE is closer to 80% of the market according to most recent studies, and I would say that much less than 10% of users have disabled scripting. And I still think that if a user is smart enough to turn off JavaScript (or even know why they should), then they are probably not going to be running below 1024px width.

...whether java applets or the browser's Virtual Machine...

Those are both parts of Java, and have nothing to do with JavaScript.

all are client-based and dependant upon the versions, file integrity & o/s install

JavaScript is no more dependent on these things than CSS or HTML itself. It's a feature of the browser, just like CSS. Both can be disabled or overridden by the user.

I'm not trying to insist that you should be using JavaScript or anything like that - I just want to dispell the myth that it has the same limitations and / or requirements as Java. The two are unrelated, other than a similar syntax and similar name (which is the source of most of the confusion).

Perhaps you can educate me more about the difference between javaScript and Java ... or point me to some place that identifies the differences?

It was my understanding that MSIE used to ship with a thing they called "Virtual Machine", which there was a big bruhaha over a couple of years ago. I understand that Sun won that battle and that MSIE no longer ships or supports their version, though lots of folks still have browser versions that have it installed. So that is ALL java?

I know that w3schools stats are from their pages, though I might argue about the technical nature of their visitors, considering they offer free online tutorials that deal with very basic matters. However, you say the 'reality' is a 15% difference in market share. Upon what are you basing the claim? (Because I often cite the w3schools stats, it would nice to have a more accurate source of information).

Regardless the exact stats, two things remain clear: (1) MSIE still holds a very large market share (shall we say between 65-80%) :) and (2) Ffox has been making cutting into that market share.

You make an analogy between CSS and javascript. That may very apt. However, I've experienced MUCH frustration using CSS to style both MSIE and Ffox pages - as each browser renders a different interpretation of the CSS 'standard'. If, to use your analogy, javascript is like CSS, then I would believe that interpretive difference exists with each browser type and version for javascript, as it does for CSS.

And that's the benefit of a server-based solution, like PHP. Each time a visitor comes to a page, regardless of what operating system or browser or version or whatever ... the PHP is run on the server, and not interpreted or run on the client. THis makes for a more universal experience. CSS, in constrast, is served up the same, but since it's interpreted at the client, the experience is dependent upon the client ... and often with unfavorable results.

If CSS could be implemented in a server-based setting, I'd be the first to applaud. If javascript is like CSS, then I believe that PHP (provided it offers the same functionality) provides a more universally similar viewing experience.

I'm not trying to push PHP (sounds like a drug ;) ), but what I am saying is that HTML/CSS and java/javascripting are all client-based. Client-based solutions don't provide as consistent a viewing experience as server-based solutions. If I had a choice, I'd choose a server-based solution.

I don't have a choice with CSS/HTML. But I can choose between javascript/java and PHP.

Make sense?

So that is ALL java?

That's right. And it had nothing whatsoever to do with JavaScript. I'll try to summarize the history:

Java is a full object-oriented programming language. It has to be compiled into machine code in order to run (JSP's, which are similar in nature to PHP pages, are compiled on the fly by a Java container / app server, such as Tomcat or WebSphere). Java was created by Sun Microsystems, and in a desire to create a cross-platform language, they created the "virtual machine", which is the environment in which Java is executed. Any OS for which there is a java virtual machine (JVM) can run Java applications, and those applications should perform the same on every platform (although it's not perfect). That's why a Java Applet requires a JVM to be installed, and the version of the JVM dictates what Java features are available, so there are a lot of applets that require specific versions.

Incidently, there are tons of Java applications that have nothing to do with the web and do not run in a web browser in the form of an applet. They are simply stand-alone applications that run within the JVM on whatever platform you are using. But for a while, Java applets were the "latest trend" in interactive and "flashy" web pages, until people got into JVM version hell and decided that Java is better suited for server-side technologies.

And yes, Microsoft did what they do best - they took Java and made changes to it, and released their own version of the Virtual Machine, so that applications written for their JVM would often not work properly with the (correct) Sun version. We in the IT department at the company where I work have suffered many headaches because of the differences in MS vs. Sun JVMs and having various apps written for one or the other.

I have written a few applications in Java myself, but it was all server-side code in JSPs and servlets. It's not unlike writing PHP in that sense.

Now, JavaScript, on the other hand, is a text-based, non-compiled scripting language created by the folks at Netscape back in the early 90's. Its purpose was to allow HTML pages to become more interactive - responding to user actions and making changes on-the-fly, performing calculations, etc., without making a trip back to the server to execute logic. It was very beneficial in the days of dial-up, when each request to the server could be very expensive (taking a long time to complete). Having a scripting language on the client-side made it quick and easy to change things like colors and display properties on a page. You can also use it to do form validation, making the user aware of errors before making a trip back to the server. Broadband has made it more feasable to go back and forth to the server for these things, but it's still faster to do it with JavaScript in many cases.

It was originally called "LiveScript", but in 1995 they changed the name to "JavaScript" to capitalize on the growing popularity of Java at the time. To further muddy the waters, they worked with Sun a little to write some hooks between JavaScript and the applet structure that was being used for Java programs embedded in web pages, so that an applet could call functions within the HTML page and vice versa. However, JavaScript, from the start, was not a part of Java and doesn't really fit the same needs as Java. You may have heard it referred to as DHTML (Dynamic HTML), which is really just another name for the combination of HTML and JavaScript, along with a (semi)standard Document Object Model (DOM) for accessing and manipulating page elements. When you use an "onclick" property of an element, you are using JavaScript / DHTML.

There are still a lot of things you can do with JavaScript that you can't do otherwise. For instance, there is a lot of information, like screen width in my example, that you can't find out from an HTML request. The only way to get that information is to use some form of script on the client to ask the browser for certain properties that are available. That's one of the things I like about my "changing width" solution - the user is unaware that anything has changed, and doesn't have to do anything to get the page sized appropriately. You can also find out things like what plugins are installed (I've used this to check for Adobe Acrobat before offering a PDF). You just can't do these things with a server-side technology (you can use that information on the server side once you get it, but you have to use JavaScript to get it in the first place).

You are right about differences in browser implementations. Just like CSS, some browsers handle JavaScript in slightly different ways. Once again, Microsoft has added their own JavaScript "features" that only work in Internet Explorer. I do my best not to use those, or to write code that can actually check the browser and do things the most efficient way for the browser in which it is running.

I do prefer server-side technologies to client-side solution in many cases, but I also like efficiency. In this example, the only people that will be negatively effected are those who have scripting disabled and are running a low resolution (less than 1024px). I personally think those numbers are very low. The benefit to all my users is they never have to select anything or even know there is a choice to make (sometimes choices are bad - but that's another discussion). It's just automatic. It also doesn't require any cookies, which would be necessary to maintain the user's preferred "style" if it was a server-side decision. The same people that disable scripting are likely to disable cookies for security (paranoia) reasons.

Another benefit of client-side scripting, formatting, etc. is that you can take advantage of the processing power on the other side of the wire. If you do everything on your server, and then just send it to the user, your server is doing a lot of work that could be pushed off to the client. This can make a huge difference in large-scale applications (as I said, my site is not a high-usage site, but I'm just pointing out one of the benefits of client-side scripts).

If CSS could be implemented in a server-based setting, I'd be the first to applaud.

The only thing is, that's not how the web was designed to work. You'd be essentially sending something like a PDF document to your user (completely formatted beforehand, with no flexibility on the client side). You can do this, by the way. Just write some code to dynamically generate PDFs. But then you run into the problem of the load on your server to do all that formatting. That's why it was designed to happen on the client side.

A much better solution would be to just get all the browser manufacturers to adhere to the standards properly so that things like CSS and JavaScript work the way they are designed to, regardless of browser and OS. I mostly fault Microsoft for this - they are generally the ones to take a standard and "enhance it", thus making it non-standard. They aren't the only guilty party, but definitely the leader of the pack. The fact that they plan to ship IE 7 without full CSS2 support is irritating.

Until then, it's a trade-off. You can get efficiency and features, but have to account for possible implementation differences. Or you can do it all server-side, and not take advantage of the extra features and efficiency. Neither is wrong, really.

I know that w3schools stats are from their pages, though I might argue about the technical nature of their visitors, considering they offer free online tutorials that deal with very basic matters.

I guess I will just have to disagree with you there. I don't think the average web user knows how to spell HTML, let alone ever looking up information on how to use it. They just click on stuff and read what it says. Sure, there are people who are considered non-technical but still try to learn about the web, but in no way is that the majority. The page you linked to even supports that claim.

However, you say the 'reality' is a 15% difference in market share. Upon what are you basing the claim? (Because I often cite the w3schools stats, it would nice to have a more accurate source of information).

Once again - the very page you linked to has that information. They state that their stats are likely skewed due to their audience, and other sites show IE at above 80%. I've seen other studies to support that figure (some have even put it closer to 90%, but I agree with you that Firefox is gaining ground - and I'm glad for that). I don't have any URLs handy at the moment, but you can probably easily search for browser market share studies.

Wow - this has gotten long. Sorry for the huge post, but I hope the information is useful. I think you and I agree more than we disagree.

Kweb,

Thanks for taking the time to write that. It was informative and well thought out. I never knew the technical/historical differences and I appreciate the lesson. I have empirically come to the conclusion that anything involving an "applet" or a "JAR" was JAVA and anything scripted inside the html (more than just calling the applet and passing variables) was JavaScript.

Are there only small differences between MS JScript and Netscape's JavaScript? Is there some place that you know that highlights these? (Might be a good reference).

Short of a Gallup poll that randomly calls folks and asks about browser information, any browser stats gleaned off the web will be skewed toward the site audience, which may (or likely not) be representative of ALL computer users.

The browser landscape & the interenet are changing rapidly enough that anyone hanging their hat on anything today, will likely be eating that same hat sometime in the future. I never thought I'd have half a terrabyte of HDD in my house, but I do. The ability to rip all of my music CDs and make them available on a wireless home network was also something I never anticipated.

You've opened my eyes regarding javaScript (so your post was worth the effort). I've been trying to avoid javascripting in my pages, without really knowing why (other than the client/server-side arguement). Yet, when XHTML doesn't allow a link to open in a new window, there are times when functionality dictates its use.

And yes ... I agree. We mostly agree. :D

Cheers,

-stk

How timely - this morning as I was browsing the news, I ran across an article on the subject of browser market share:

http://story.news.yahoo.com/news?tmpl=story&cid=528&e=4&u=/ap/20050513/ap_on_hi_te/microsoft_browser_market

The story cites statistics from WebSideStory.com, and their take on the market share as of late last month can be seen here:

http://www.websidestory.com/products/web-analytics/datainsights/spotlight/05-10-2005.html

I haven't read all the details about how they gather statistics, but they claim to gather info from over 30 million users daily. I've heard of this site many times over the years and I'm pretty sure they are reputable.

I don't have any good comparisons of JavaScript and JScript. From what I have seen, though, it appears that JScript includes all of JavaScript, plus some additional features that are IE-specific. In general, if you use good JavaScript references (books, websites, etc.), you will either not see that stuff at all, or see it clearly marked as "IE only". Most people don't even use the term "JScript" - they just call it all JavaScript and note the IE specific features.

I'm glad I could help you understand it a little clearer. I must admit that many of your posts in these forums have opened my eyes to the need to write more strict markup, and in the last couple of months I've updated several of my sites to make them XHTML 1.0 Transitional & CSS2 compliant. I've been doing web design since the days of IE 3, so I had a few sloppy habits from writing so much HTML 4.0 that needed breaking... :) Just consider this a returned favor, I guess.

Kweb,

Yes ... that was timely. You were correct, that the MS market share is approx. 90%. I was surprised to see it that high, even knowing the w3schools stats were skewed. (I would have guessed that they were + or - 5% ... but it's not the case).

Thanks for opening my eyes to BOTH. That's what's great about these forums .. you just never know what you're gonna learn next! The more I learn, the more I realize I don't know squat. ;)

See you on the boards.

HBX Analytics, the flagship product of the WebSideStory Active Marketing Suite, is a comprehensive on-demand web analytics solution, delivering actionable, up-to-the-second insight into online activity and visitor behavior.

This is just one of the products that they deliver, I wonder how many "IE only" websites that product is installed on ?

My own site (when it was IE only) had a "90% of your visitors use IE" result. When I recoded it to "any browser" IE dropped to < 60%.

So, I wonder how skewed their own stats are ? ;)

¥