I just started at a new company and have been asked to do what I believe impossible, but I need confirmation on this. The website that my company has allows users to view images in extremely high resolution using SVGs. We've built a custom viewer for these images that allow you to zoom and scroll around the image and it works well. Because of this, the image format "needs" to remain SVG. However, we need to include a watermark to this image. The way we're doing this right now is passing the SVG and PNG watermark to the client, inserting the watermark into the SVG, and displaying it to the user. This is very obviously easily hacked as anyone with client-side experience knows (The dev team here is mostly older developers and don't have much web experience). Even if the raw SVG isn't intercepted, they can still just delete the watermark from the source. I've convinced my boss to make the watermark be injected on the server-side, so this leaves just the problem that SVGs are editable by the end-client.
What I want to know is if one of these two things are possible:
1) Is there another image format akin to SVG that could be used to keep this highly scalable image without loosing resolution, and without it being directly editable by an end-client? The only options that people seem to discuss for the web is JPG, GIF, PNG, and SVG. I've looked at Adobe Illustrator ".ai" files and EPS (Encapsulated PostScript) as other vector options, but I can't find anywhere if I can modify these images in PHP, which is key if I want to overlay a watermark in server-side code.
2) Is there a way to obfuscate the raw SVGs content so that the use can't go and manipulate it? I've seen SVGs that have <image ...> tags inside them with PNGs represented as long and complex strings before. Something like xlink:href="data:image/png;base64...". I was wondering if there's a way to display an SVG as this string, so that the data can't be directly manipulated. I'm sure there's an algorithm to reverse these, but so long as we're sticking with SVGs, I need to make this as secure as possible with as many hoops to jump through as possible if someone wants to steal the data.
Either way would be acceptable, as long as removing this watermark is more complex than just hitting F12 and removing the element inside the dev tools.
Is there another image format akin to SVG that could be used to keep this highly scalable image without loosing resolution, and without it being directly editable by an end-client?
SVG is a vector format, and to maintain extreme scalability, you need to stick with vectors, be it any format. However, in that case it will always be possible to remove the vectors that belong to your watermark. There are of course vector formats that are stored as binary, which would make it somewhat harder for an enduser to parse and edit, but those are not editable in PHP either, and are much less compatible. So you probably don't want to do this.
Is there a way to obfuscate the raw SVGs content so that the user can't go and manipulate it?
First, it will never be "secure" in the sense that as said above, it will always be possible to remove the watermark from a vector image. (Btw the only difference to bitmap formats like JPG is that content below the watermark in bitmap is actually missing, while in SVG it's still there.)
However, depending on how "good" you want this to be, you can do a few things. I think the "goodness" here means the effort needed to remove the watermark, and you can raise the bar relatively easily. You don't have to (and you probably can't reasonably) obfuscate the whole SVG.
One thing that comes to mind is that SVG is basically just XML, it consists of tags like <rect>, <line>, <circle> etc. The order of these tags doesn't matter much (mostly, with exceptions of course). So you could entwine the tags that draw your watermark pretty much randomly among existing tags. I mean really randomly, so different downloads would produce different results. If you do this well (eg. you find line tags to "hide" your watermark line tags, and so on), it will be hard to automatically remove the watermark, because it's all over relevant data that is your actual image. Of course, the watermark could still be visually in a corner, and this is already a weakness, anything drawn to a corner could possibly be removed automatically. And it will be easy to remove by hand with any decent editor I suppose. So it depends on what the purpose is.
But I still think this sort of thing could make it hard enough in many scenarios (and would be totally inadequate in others).
I read while Googling that SVG was "dead". Although I disagree, could anyone tell me more/future vector based format to represent 2d/3d graphics? What about VML? What format should I use to represent 2D and 3D graphics on Web?
I playing around with graphics on web and I would like to know if I'm working with an obsolete technology.
Microsoft is supporting SVG in IE9, and gave a detailed explanation of why they were doing it on the IE blog:
http://blogs.msdn.com/b/ie/archive/2010/03/18/svg-in-ie9-roadmap.aspx
SVG's main advantage is that it becomes part of the DOM, so you can use CSS to style it and javascript to modify it. Canvas, by contrast, must redraw every frame completely. This makes canvas suited to spectrum analyzers, video processing, fast-paced games, and other non-gradual animations. SVG is better suited for gradual animations.
As far as 3D is concerned, the future is WebGL, a thin shim over OpenGL ES, but it's far off. Microsoft has not committed to supporting it, and that means it's not going to be in IE9. Maybe IE10, maybe not.
If you do use SVG, I recommend using svgweb to abstract away the browser differences (falls back to a flash applet on outdated browsers).
This post is rather late... but I think it is worth re-addressing, since your question has popped up again with all the html5 talk.
SVG is a vector drawing format that also supports animation, timing, and Javascript DOM support. In other words, it is a standalone format for static and dynamic vector graphics; you might say it is a web-focused (or screen-focused) alternative to EPS/PDF. The html5 canvas tag is not a format but a way to draw (static images) to the screen with Javascript — that is all; there is no competition between it and SVG, as they have entirely different purposes.
Most other vector "formats" involve plugins (Flash) or hardware support (webGL). Ironically, the VML format you mentioned is now deprecated in favor of SVG.
To answer your question: SVG is now the standard vector format for the web. Hopefully, in the near future, we will see it being used for video/animation as well.
You can try the Raphaël JavaScript Library.
It is easy to implement and provides the same UI features as SVG (and more!).
If it is SVG you are after the best way to go is svg.js. It supports SVG better and it is a fraction of the size (4.5k gzipped) of Raphaël (31k gzipped). It also has a very intuitive syntax.
All major browsers including ie9, firefox, safari and chrome are starting to supporting svg as part of the upcoming html5 standard. I wouldn't call that "dead"
2D: SVG
3D: X3DOM or webGL directly
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I heard from more than a single source that SVG is dying, it is abandoned by Adobe.
How sad! What's will be next alternative to SVG?
SVG is an open standard, developed by W3C. I really don't see it dying any time soon. Just because certain companies decide to drop its use for their commercial products (usually because they need, or feel they need, something more customised), it does not at all mean SVG will disappear on a more global scale.
At the moment, it's undoubtedly the most widely used vector graphics format on the web. Just take for example the images on Wikipedia - for almost all diagrams SVG is either used or there is a notice stating that it should be used. Many other open source projects endorse it in a similar way.
Now, the XAML markup language (part of WPF/Silverligtht) has been seen as a competitor to SVG by some, but truly they only overlap in functionality to a certain degree. (XAML supports lots of other things such as data binding, events, triggers, etc.) Indeed, the general use of XML is much restricted in that browsers don't natively support it (and can't properly, because of the fact that it's tightly bound to MS technologies). I would not even believe that it's strictly a direct competitor to SVG, nor that Microsoft have intended so.
To conclude, I don't think one can envisage SVG dying out until something clearly improved (and open-standard) comes along to replace it. As far as I know, there is nothing like that at the moment.
Check your sources.
A lot of people want SVG "dead". A common way of getting something to happend is by spreading rumours that it has already happend. It's called a self-fullfilling prophecy (wikipedia). Don't buy into it, and please don't actually help those wanting it dead by spreading the rumor further yourself.
Is SVG dead?
No, it has just begun.
What's next?
HTML5, Canvas and SVG in one long glorious love-affair. Get your first-row tickets now!
(Actually here's a youtube video of html5, canvas and svg showing off the infinite resolution inherent in vector graphics. Somewhat lame but real, unlike rumors.)
SVG (Viewer) was abandoned by Adobe ages ago since most browsers support it natively.
Only IE is holding back the technology by not having native support.
Update: IE9 will have both native SVG support and native Canvas support! (Vista and above only though)
If you'd like to show your support for getting IE to support it natively add your vote and comments to these bugs.
https://connect.microsoft.com/IE/feedback/SearchResults.aspx?SearchQuery=SVG
Bring back VML! Just kidding ;) I don't think SVG is dying, but <canvas>'s adoption for HTML5 seems like the way things are going on the web.
I'd like to add my support for SVG. First, I believe that it is widely used in mobile technology though this is through conversations about 2 years ago rather than seeing code. It was one for the first languages developed by W3C to be used over-the-web and has been consistently supported for the last 10 years. I initially thought it would be a killer-app in 1998 and said so, especially since Adobe then had enthusiastic support.
Because SVG is a full XML dialect it can be easily mixed with other XML applications such as XHTML and MathML. It's possible to include XML information in SVG elements so that documents can be fully semantic (i.e. carry a data-meaning as well as a graphical one).
SVG is effectively feature-complete for a 2-D graphics language. There is no technical reason to invent anything else. It does high-quality rendering, animation and can support interaction through its own elements or through Javascript. It is therefore unlikely that major web software manufacturers will NEED to invent anything else.
The main problem is not that SVG is "dying" - it is not - but that it takes a long time for the various companies to converge. When they do I would expect SVG to emerge as a consensus.
Part of the problem is that graphics are not yet seen as a semantic problem - it's often "easier" to inflict a dumb animation on a client than to set up the infrastructure to send semantics over the web and repurpose at the client. But as the semantic web develops then standards such as SVG will be increasingly important. If, for example, you wish to mash-up geographical information then either you use a properietary solution such as GoogleMaps, or you look for a shared standard approach. You can never count on free proprietary solutions in the long run.
Note also that in many areas which receive public funding there is an increasing drive towards Open standards and this is another reason why SVG is well positioned.
Then there's this article posted Friday on Network World, titled EC decision expected to force IE to better support standards. In it, Håkon Wium Lie, Opera's CTO, states
Second, due to the increased competition stemming from the ballot box, browsers will improve their support for standards. This will result in a richer, faster web. For example, I believe that Microsoft's IE will add support for SVG, a standard that all browsers but IE support.
Of course, it's in his best interest to see IE falling in line, but behind, his browser. He gets to be cutting edge, but part of a larger 'standards' crowd.
While this is an question was asked before high res/ retina displays came to be the normal for mobile devices. SVG is having a big come back as vector graphics solves DPI issues on the web. You will be seeing more SVG on the web than before.
Even apple.com menu is svg now days!
Update:
I deleted my motivation because it seems to distract readers. This is not about "why don't you make your window smaller". See the screenshots and you will see obstructed text because of fixed width. See my reference to "em/ex" notation in CSS. I would like to have a real discussion here. Thank you.
Now I would like to ask real experts on this topic -- I'm not a web designer -- why fixed width layout are still that popular and if there are really good reasons for it. (you are welcome to point out reasons against it as well.)
Is it too hard to design your layout relatively (from start on)? It seems some people even forgot how to do it.
Do you have real reasons like readability and just don't know how to deal with it correctly? Here I'm referring to pieces of wisdom, like it's harder to read longer lines (that's why newspapers use columns) -- but then, width should be given using em and ex.
Are you forced by some old guidelines? In the dark old age of HTML, people did a lot of things wrong; now everybody finally uses CSS, but perhaps this one just sticked.
Or are you like me, wondering why everybody is doing it "wrong"?
To illustrate the issue, I want to give screenshots of negative examples first:
StackOverflow (here I can't even see what would make it any hard to fix it)
Filmstarts (a german website which renders itself unreadable-if I don't take a reading-glass with me)
And here is a positive example. It looks like a typical fixed with site (even with transparent borders), but it is not:
Website on Wiki software -- associated Forums
What do you think?
Update: Related questions: this one and that one.
And here, as expected, comes the usual canard: “long lines are too hard to read”.
[Citation needed], folks.
See http://webusability.com/article_line_length_12_2002.htm for a summary of actual research in this area. A number of these, plus http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp, find that although users express a preference for moderate line lengths, reading speeds do not sharply drop off with ‘long’ lines; in fact many show increased speeds with the longer settings.
As long as it's not ridiculously long, and taking care to use a decent amount of leading, long lines are not generally a real issue at today's typical browser widths and default font sizes. (If you're one of those designers that loves to use teeny-tiny type for everything, it could be an issue, but then you're already making it impossible to read with the flyspeck text. Stop it!)
So as it's only an option of user preference that prefers medium-short lines, let us users decide how much screen space we want to give the web site to get our work done. We're the ones best-equipped to know. If you decide you know definitively best you're likely to waste space, or, if you guessed too long, make us scroll back and forth sideways to read the text — and that really is a readability nightmare.
If you want to protect us from ourselves, you can compromise by specifying a min-width and max-width in ‘em’ units so that the page is responsive to liquid layout, but doesn't get stretched to extremes.
But otherwise, the best reason to design fixed-width is indeed that it is easier, especially for someone with a fixed-2D-grid view of the world and static visual-design tools like Photoshop.
It's already a pain to make a website that renders correctly across all popular browsers; if you also want it to render correctly at all text sizes, it's quite a lot of work. A lot of web developers design their sites for the default font size and try to support fonts that are either a little bit larger or a little bit smaller. (You might be interested in this dated but relevant piece from Jakob Nielsen.)
As for fixed-width sites, it's hard to say. Personally, I suspect that a lot of web designers just like to feel like they have a lot of control over their look and feel, and think the site looks "ugly" when you stretch it too far, so they don't let you do it. Probably not wise, but there you go.
Now I would like to ask real experts
on this topic -- I'm not a web
designer -- why fixed width layout are
still that popular and if there are
really good reasons for it.
Ah, both subjective and argumentative. I'm sure my argument won't convince you, but here's one really good reason, IMHO:
Presentation.
Just like a movie, the director has an experience in mind for the viewer. They frame the movie just so. They move the action at a given pace for the emotion they are trying to invoke in the viewer. Even though DVDs have had the "angle" feature since inception, few movies have ever given viewers the opportunity to watch the film from a different point of view, and if they have that viewpoint was still under the control of the director.
Now, any old sap can throw up a website, and for the most part they aren't interested in anything more than the content.
But real designers fully understand that the design must be understood as a whole. A wide layout has a very different impact on people than a multicolumn or thin layout. Reader eyes move in a certain pattern, and the text is intended to pull the reader along a path.
Those who claim that every layout should have certain features are shortsighted. There are no universally true 'rules', and trying to make an expanding layout a rule is shortsighted at best, and arrogant at worst.
-Adam
Here are my $0.02 and they are worth exactly what you paid for them (and if that's not a perfect example of the current economic situation... :-))
The layout of a website should be dictated by the overall user experience. This is in part determined by the accessibility, in part by the design, in part by the functionality:
Accessibility - as several people pointed out, letting the website use the full width of the browser without any control can result in quite a long lines that make it hard to read[1]. Making the text automatically layout in multiple columns is a potential answer to this problem, but it's really hard to achieve with CSS (that's gotta be the worst tool for doing layout humanity ever devised, but that's a separate topic) and is fraught with other issues as well.
I should note that you do have a point - most websites with fixed width do suck on high-DPI because they don't take into account the changed font size. However, that's not an inherent problem of the fixed width design; I've seen it with fluid designs as well.
[1] No, I don't have a citation. I, however, have tried reading on full-screen on my 24" 1920x1200 96dpi [2] and gotta tell you - after 15 minutes my neck is cramping from the constant turning of my head.
[2] The typical user still runs 1024x768 or 1280x1024 (based on instrumentation from the product I work on, with about little bit less than 10mln installs for the latest version). So yeah, I am not the typical user.
Design - most modern designs are very rich on graphical and video elements. Most graphical elements do not scale well with the document reflow and video does not scale at all. (I would again blame this on CSS - it's support for dynamic resizing of images is lacking some basic operations and there is aboslutely no support for building and control of the visual tree. But I digress again :-)) As such, disegners opt in for the easier approach.
Functionality - fluid layout is really good for dealing with big text chunks like documents. However, quite a few modern websites are in effect applications, not documents. They have multiple elements and controls and increasing the area on which these elements are scatered makes it harder for the user to keep all of them in focus.
Couple examples:
two control groups that are aligned at the left and the right end will be too far away from each other in full-screen width. Note: that can be alleviated by choosing to always keep all the controls grouped together, like most desktop applications do (almost all desktop apps keep all toolbars left-aligned).
a picture/video and associated text below it. On full screen there are two possible approaches for fluid layout:
a) scale the picture to the full width, at which point the text is visually lost
b) leave the picture the same width, but let the text flow the full width, at which point the picture is visually lost.
I guess my point is that the fluid layout is not the Holy Grail of all layouts and there are scenarios where it's not applicable. The designer and the developer of the webapp should choose the appropriate layout and implement it so that it meets the needs of the target users, delivers the best experience of the product functionality and adapts to the user environment.
I suspect that most web developers go for fixed width because it's by far easier to develop such a site (in addition, many Content Management Systems only offer a fixed-width layout).
Getting a dynamic layout to work well & correctly in different browsers is more tricky - but it is definity doable (I'm just recently working on that issue ;-).
And I do agree with you - I want web pages that dynamically adjust their contents to the browser size that I as the 'customer' like to work with (whether that's small or large). I don't like to be patronized into "not using my browser in full-screen mode" or anything the like...
You might try zooming in. Most modern browsers will zoom the whole page by default, not just the text. This preserves the page layout and uses more of your screen. Usually the shortcut is ctrl + + and ctrl + -. It works well on my laptop, at least
[Forget my mention of the windowmanagement, it wasnt on topic]
I currently run a big internet-community and we'll switch to fixed-width (for 1024px) design asap because we only get problems currently using a dynamic-width-layout: You cant rely on anything, and (the biggest problem imho) text gets to long, so there are only a few lines but the lines themself are much to long to overview.
Readability and Predictability
You need to know how things will be displayed to be sure it will be readable and pleasant to the eyes. By using a fixed width, you know exactly (almost exactly because of cross-browser support) what your users will see.
However fixed-width designs would be a thing from the past if browsers could support correctly exactly 2 CSS properties:
min-width
max-width
That would allow designers to design web sites that would be flexible and predictable. No more surprises and users can use whatever resolution they want.
In my experience, it is for two reasons:
1) Speed - it is generally faster to write a web page in fixed with, rather than trying to write one that resizes correctly at more than a small number of resolutions.
2) The designer of the web site isn't the ultimate approver of what goes into production - if you try to work with a flow instead of fixed layout you get questions about why it looks different on Sallys' PC vs the Big bosses, and why can't you move this over to here, etc, which are easier to fix by moving to a fixed layout.
Tabbed Browsers
Since I use a tabbed browser for day to day use, resizing my window every time I switch tabs is actually a bit of a hassle. I have the window set to the maximum usable width for my purposes, and to accommodate the "largest" tab that is open. For the remaining tabs, having fluid layouts is actually kind of annoying and distracting. Items and text jump around and change position depending on how I may have resized my window for another tab. Also, fluid layouts result in uncomfortably wide blocks of short (vertically) text.
For me, it's a lot easier as a reader to keep my eyes tracking properly on narrower blocks of text with lots of vertical scroll, and it's much easier when sites I'm familiar with stay the same size so that the layout and positioning is predictable, regardless of what I've done to my window to accommodate other tabs. I actually used to be a big fan of fluid layouts, but I find more and more that I prefer fixed layouts now that I use a tabbed browser.
I think the question shouldn't be "Why would you choose a fixed-width design?" it should be "why wouldn't you?"
Firstly, you need to cater for the lowest-common denominator. Many developers will be running on screens with resolutions like 1680x1050, 1920x1200 and 1280x1024. Some users will be using 1024x768, which I personally consider the lowest resolution you need to cater for (thank God it's not 800x600 anymore). If you fix the width to 960-1000 pixels then you don't run the problem of developers unintentionally making pages that can't be viewed without scrolling on a monitor with less than 1600 pixels (wide). Believe me it happens.
Layout on any non-trivial Webpage is hard. Throw in cross-browser support such that your page not only works but looks reasonably consistent and it's a huge problem. Now try to throw in variable width and it just gets that much worse if not impossible. Look at the payoff too: who is it going to benefit? A small minority of users that have high resolutions and actually want to stretch that content across the entire screen. I have a widescreen monitor and I won't maximize my browser for instance. Many people are like me in this respect.
Consider another problem: CSS. CSS s good for many things but is a royal pain in many others. For one thing. Now browser box model differences aside, there are still many quirks with how different browsers handle CSS and even if there weren't there are many trivial things CSS can't do and the only workaround is to do things by pixel.
As a concrete example, I'm doing some tables at the moment that are bursting at the seams. I'm reloading the contents with an Ajax call and replacing the contents. Now I at first tried to fix the widths of the columns with percentages. Doing it this way would be a prerequisite for not fixing the width. Firefox treated those as a suggestion and would resize them anyway even when it arguably didn't have to. I didn't get satisfactory results until I fixed the widths in pixels.
At the end of the day no website really cares if it stretches across 1600 pixels or not. That's what it comes down to.
I've worked with a lot of artists. They design a layout to be pleasing and clear. They want the presentation to match what they designed. Artist-driven design leads to fixed-width. For brochure sites, fixed width makes a lot of sense.
For sites with rapidly-changing content (news or shopping, or most anything driven by a CMS), I much prefer fluid, full-screen designs.
One of the biggest concerns that fixing the width of a website solves is readability. If you let a site be arbitrarily wide and have a block of text using that entire width, it becomes very difficult for people to read. If you make the font size bigger to compensate, then you destroy the experience for people with smaller screens.
On the other hand, if your content is visual or modular and you can make it fill up the page more intelligently, you might have a case for a totally fluid layout.
But I agree with the others who question why you would maximize a browser on such a big display. Why not make your browser window smaller? You'll be more productive and you'll stop worrying about it at the same time.
Many browsers do a better job of scaling websites to be larger than they used to; Firefox 3, at least, grows the entire page when you zoom in, not breaking the layout.
If you want it to take up more screen real estate, use a lower resolution. This can be useful if you're displaying a website on a large monitor up on a wall for public view. Otherwise, take #theomega's advice and use the rest of your screen for other windows.
As for a little (of the very little) of what I know about web design and fixed width sites:
They tend to make good use of white space and draw your focus down the page. Cluttering up the page by cramming every last corner with content is what designers call "visual intimidation." It's difficult to figure out what's important versus what's not.
They feel more "finished", like a picture in a frame instead of like a photo print thumb-tacked up on a cork board.
"It has a resolution of 1920x1200, so all fixed-width sites waste space
The form factor is only 15". So I have to use larger fonts and the text won't fit into these crammed layouts any more, sometimes even getting obstructed by other elements."
There is a good reason for that. If the paragraph are stretched too wide, it gets more difficult to read. Humans need a "break" after about 15 to 20 words and that is EXACTLY why we don't have books that are very wide.
The higher resolution allows you to have MORE details BUT it also depends on HOW you use the space. I never maximize the browser and PC's are built for window multitasking, not ONE window at a time.
The whole point of being able to adjust the size of your browser window is to better see the content of a web page, in the way that suits your situation. If the page isn't going to adjust, why not just make browser windows a single, fixed size?
If I have a big monitor, I want to be able to stretch my window out and have the content correctly fill it. If I need space for another window, I want to be able to shrink my browser window down and have the content correctly adjust by changing the layout (until a certain minimum point, and then by switching to a scroll bar, of course.)
Fixed width layouts are perfectly acceptable.
Fluid layouts are nice, but are more difficult to implement, especially if there are more than two columns and source div order is important.
Line length is an issue regarding readability, but this interacts with font size. So you have to balance width against likely font sizes on screen.
Nowadays, it's reasonable to assume that 1024 x 768 and up is the vast majority of the desktop user market, so you can safely design for 960 px fixed width -- for screen media type.
A couple of important constraints:
ensure is that horizontal scrolling
is never required by the user
if conversions are an issue, make sure
that clickable things -- particularly
"calls to action" or anything than
makes your cash register go
"ka-ching" should not fall to the
right of the 770th pixel or so --
just in case.
But another consideration is handheld media. You should provide alternate CSS for handheld media type. Many of these screens are under 400 px wide.
Delivering a site that looks good and functions on a wide variety browsers, devices, display widths and viewport sizes is a moving target and continuous challenge.
As regards the filmstarts.de site, it is definitely a mess, but the problem is not that it is a fixed width layout, but rather with how the layout is designed and implemented. There are good and bad implementations of fixed width layouts, just like there are good and bad implementations of fluid layouts, or semi-fluid layouts with fixed width elements, etc.
I put it down to laziness. Fixed width layouts are simply easier to design and make look nice because you do not need to worry about the size changing. This, for example, makes it really easy to add images, since you know what size the layout will be.
Personally, fixed-width websites really irritate me. I like to use large monitors. I paid a lot of money for them, so I'd like to make use to make use of them instead of having most of it be left blank. This is made even worse by sites which refuse to get larger if I increase the font size. I don't have the best eyesight and often use larger fonts to read text on websites and nothing is worse than a fixed-width layout leaving me with three words per line and a mostly blank screen...
As far as I'm aware while all the reasons cited are valid, the primary reason is that a lot of machines in monolithic institutions like banks and government orgs are still on fixed and somewhat archaic low resolutions. It's just the lowest common denominator sadly.
I personally like fixed width sites better. I am not forced to mess with my browser window to get a line size I can deal with. I personally find very long lines very hard to read. I also just think it looks better although that is 100% completely subjective.
I have designed and worked with both. Some aspects of variable width sites make displaying data easier. The only problem I have had with them is due to right aligned navigation which was a little messy when it could move based on the user's browser setting.
My final answer - both are fine and each have their place.
I just came across this site, which actually has a link in the top right corner that lets you switch between fixed and fluid.
http://developer.spikesource.com/wiki/index.php/Home
A major point for using fixed width is that the designer can actually control the way the webpage looks irrespective of browser environment. I see two reasons to use FW:
The designer wants the webpage to look all the same.
The designer lacks time/wish/... to test their page in different modes and in different browsers, and just avoids the risk of webpage layot starting flying around.
I didn't make fixed-size layout until I switched to a 32 inches monitor. It is very hard to read the text if the lines goes over 32 inches. I've learned appreciate text that do not span over more than 1,000 pixels, and I have switched to fixed layout since.
But I agree that reducing the content width to < 800px is a pain when you have a big monitor.
Most users lack understanding of how to use a browser properly. When the day come such that users actually know how to use a computer then you will understand that fluid width is the obvious choice for web sites.
I am frequently forced too. None of the 3 developers here has a strong background in design, and the dictated rules and implementations we strive for reflects this. It is an area I want to improve in.
Liquid layout using % as unit can adapt to any screen.
Some layouts must use fixed column design. If there's table or image in the column, you have to use fixed column, or the table or image will break the column in liquid design.
In grid layouts with heights of the grid normally fixed, it's better using fixed column or the widths may got uneven.
It's upto the content of webpage to use elastic column or fixed column layout.
Long lines of text can be difficult to read. For the website I work on we limit the width for usability and readability. We have also designed our site to scale well using CTRL-+ to zoom.