I agree entirely that changing the supplied data without warning isn't ACID compliant; in fact, it's quite scary that any serious database would even consider it reasonable behaviour.:-(
With all due respect, you're missing the point. Some DBMSs provide these "non-standard extension" because they are useful. Achieving the same goals with the same reliability in client code would take much more development; why bother, when your database tool already offers the same functionality?
Portability is merely a means to an end, not an end in itself. Lack of portability does not imply a bug, it is simply a design decision to be made by weighing the pros and cons, just like any other. In this case, it seems a decision made one way some time ago is now causing problems, but who knows whether it was the right decision at the time? Maybe if the original development had been done with portability in mind, the extra overhead would have killed the project and there'd be nothing left now on any system.
This issue simply isn't as black and white as you're making it out to be.
For example, if you insert a number into MySQL that is too large for its data type, MySQL will truncate it (NOT good for accounting), while PostgreSQL will terminate the transaction and happily raise an exception! THis behavior is NOT ACID complient.
OK, you got me. Why can't you just roll back the entire transaction, and issue an error message indicating that the data provided was invalid? How is that in any way non-ACID-compliant? (Or are you saying that PostgreSQL doesn't respond this way, and that's what isn't compliant?)
You've just got to look at the backlash when it was reported Mandrake had an adware installer and screensaver to see that this is unlikely to work in open source software communities.
But many of those are the same open source communities that used to believe you could get something for nothing. Today, even the biggest OSS projects, things like Linux and OpenOffice, have found that ultimately, you do need some source of income if you're going to keep good people working on good output for an extended period. A lot of these projects now have "donation funds" by whatever name, or sell packaged versions of products. Either way, the end user is back to paying for his software again.
Sure, most people don't like adware today. They probably don't like ads on TV or radio either, but as another reply noted, those still exist. I think if it comes down to a choice between adware or paying hard-earned $$$ for free (-as-in-Joe-Public-doesn't-care-as-long-as-it-does n't-cost-anything) software, a significant number of people would probably opt for the adware.
There is perfect software that has no bugs, but it's extremely expensive and difficult to produce. You need integrity checks at every single layer of development to ensure that nothing added compromises the code already in place.
It's interesting that the highest quality (in the sense of low bug count) code I've ever encountered is the source for TeX. IIRC, Knuth used to offer a financial reward for identifying bugs in the code, and a few people did get one, but after a while it was remarkably clean and he pretty much froze it at that point. No big development process. No ISO-certified XP-based integrated-team-managed fuss. Just a good guy, writing good code, and making a genuine effort to have it reviewed by enough competent people.
It's not the only way to make great code, but it's a shining example of what can be done with a bit of talent and a bit of effort in an otherwise pretty dim world.
My point was that the post to which I responded advocated not letting you turn it off at all. Indeed, to this day, there is no standard switch in Outlook even in any of the advanced options to switch off this safety feature if you really don't want it. Instead, you have to resort to third party tools -- lucky there are some available for this, isn't it? -- or Dr Regedit, which is way more dangerous to a random end user than most executable attachments you see.
Yes, please, make safety the default. Lock it down out of the box, switch off all the remote comms stuff, get users to add a password when they set it up the first time, whatever. But do let the serious people play with the grown up toys as well. There's no point making an application so safe that it's no longer useful for its original purpose.
It seems like after a decade or so of being stalled in the mainstream, new features are being added to commercial developmental languages and at a furious pace.
I think that's rather harsh.
Ten years ago, several of today's most popular languages (Java, Python, Perl...) were toys if they existed at all. Others (C++, VB) were nowhere near the tools they are today. Many useful extras have been added into these languages during that period.
As for new features being added now, my first response to that was, "What's new about any of these features? Many other languages have had them for years, and those behind Java and C# have just noticed that the critics were right all along."
I wondered about the same thing, and indeed the people behind C++ considered (and rejected) the explicit constraints idea long ago, for this among other reasons.
Another good question is how do you write other plausible constraints, e.g., something generic in terms of two types, one of which can be converted to the other.
Seeing as how everyone is moving to.NET, including the next Windows version, you're clearly talking out your ass.
That kinds depends on what you mean. Have I "moved to.NET" because I have Visual Studio.Net 2003, and hence a recent version of the framework, installed on my PC at work? I don't use a single.Net thing other than what VS uses itself, nor am I developing for that platform or likely to do so in the near future, but I'm sure MS would love to call me a convert.
As for the next Windows version... Plenty of big players have only just moved to Windows 2000, and that's the one they pretty much got right. I haven't seen Windows XP on anything except a new PC that happened to come with it, though I've seen several people specifically ask for a downgrade to Win2K with their new box on the basis of "tried and tested matters". Everybody moving to WS2003? Not likely.
I'm neither a Microsoft-lover nor a Microsoft-hater, but I do prefer to stick to facts, thanks.
MS had to change the name of its last server upgrade from Windows.Net to Windows Server 2003, because the.Net name was such a marketing failure.
I saw a joke in a major PC magazine not long ago. They were going to run an article on Microsoft's forthcoming (now released) tools to provide Visual Studio-esque kit to Office developers. Unfortunately, they couldn't fit the product name within the available column inches.
I'm not stupid. I'm fully aware of the risks involved in opening and running an executable file from an untrusted source. I'm also a professional software developer, and I send and receive executable files on a routine basis, as does everyone else I work with. Who are you, or Microsoft's Outlook development team for that matter, to tell me whether or not this is acceptable behaviour?
Sorry, I don't understand your complaint about C++. Pretty much all the standard library containers and algorithms C++ added to what it inherited from C are generic. Actually, a common criticism is that in some cases they're too generic.
I understand both arguments here, and I think there's an element of truth to each. NULL pointer problems are invariably logic errors, yes. But they should also be preventable logic errors; the reason they're not is that C (and, to an extent, C++) do not offer sufficiently powerful high-level features that programmers can avoid low-level nastiness like pointers unless they're really necessary.
The solutions you mention -- exceptions and null objects -- both have their place. So do neat constructs in C++ like:
if (derived *pDerived = dynamic_cast<derived*>(pBase)) { // Do something with derived types only
} // pDerived no longer in scope, so can't use by accident
However, NULL pointers are and always have been a nasty, low-level concept. They don't really mean anything in themselves, they're just used to indicate special cases. Consider a hypothetical language that has
a solid exception mechanism, for reporting errors
good support for both disjunctive and conjunctive types, for handling functions that can sensible return several related but different types of information (e.g., a search function that returns "didn't find anything" or information about one or more types of thing that were found)
a solid object lifetime model
and you're just rendered NULL pointers irrelevant. Instead of risky dereferencing of pointers, you have pattern matching on disjunctive types, so you can only "dereference" in a context where it makes sense. Instead of using "signature values" to indicate errors, you either throw exceptions of as many types as are appropriate, or in non-exceptional cases such as a search not finding anything, you return a disjunctive type. There is no concept of an object disappearing, because you set up the rules such that objects can't disappear when they're still accesssible.
Now consider that all of these features are available, today, in many different languages, and the argument that NULL pointers are a low-level problem also has a lot of merit.
Re:Does adding every ingredient make it better?
on
C# 2.0 Spec Released
·
· Score: 1
I have some sympathy for your point of view, but I'm afraid you give universities way too much credit.
Universities are right to teach important concepts [...] like software engineering, project managment, [...]
Yep, because academics are well-known for their firm grasp of both software engineering (do you appreciate what that term implies? -- they often don't) and project management. Not.
Academics teaching within their research interests are usually the best guys in that particular business. Academics who've only read a couple of books in preparation for giving a lecture course to postgrads with industry experience are likely to get schooled in fairly short order.
If you've got a Computer Science degree, and you payed attention, you can pick up the syntax for a new language within an hour. With a good API reference, you can be banging out code like an old pro with a weekend of study. It's not that hard.
I'm sorry, but that simply isn't true. And I speak as someone with both a formal, academic CS background and plenty of experience in the trenches.
Academics who claim they can get up to the standard of an old pro in a weekend are deluding themselves. Yes, general skills are very important, far more so than any specific language or tool. Yes, someone who's familiar with one imperative language can probably learn another with relative ease. But that still doesn't make up for the lack of experience with the things that matter in an industrial context: you won't know the idioms, the special cases, the gotchas, the workarounds for the gotchas, the sometimes vast and sometimes complicated standard libraries, where to go when those libraries are inadequate for your needs, where to find good quality reference material on the language, its library and ongoing developments in the industry...
There is a difference between being familiar enough to knock up a basic program or maintain someone else's simple code, and having a sufficiently broad and deep knowledge of the tool to write good code in realistic contexts independently. That difference is about 1-2 years of regular use backed up by a reasonable amount of reading around the subject, IME.
Any monkey with a keyboard can whip out a Visual Basic app.
Any monkey with a keyboard can whip up "Hello, world!" in C++ as well, and usually with only two basic errors that will get past most compilers. The same monkey, asked to do a significant piece of work, would be a serious liability, particularly if they were arrogant enough to assume from their academic background that they understood the tool they were using and could do no wrong because they "knew how to program".
LANGUAGES SHOULD NOT BE DEBATED BY THEIR STANDARD LIBRARIES.
A nice help page or not has nothign to do with a language!
Again- the IDE is not a language feature.
I think perhaps you're missing the point. Languages are just tools, and what matters to a developer (as opposed to an academic) isn't the fine print in a spec, it's what you can do with the the tool, and whether it helps you to do you job more or less effectively than any other.
In this case, a good IDE including good reference material makes a huge difference. A lot of syntax and complexity that would be awkward if your only tool was a simple text editor can become useful and powerful when your development environment helps.
The same goes for libraries. My long-held personal view is that a small "kernel" library to deal with basics and provide a framework for more advanced features works best, preferably combined with a public repository of extensions that integrate into those frameworks. Perl and CPAN is a good example; (La)TeX and CTAN is another.
Nevertheless, let's not kid ourselves here. People didn't switch to Java because it had GC, at least not just because of that. They switched because it had an enormous library that let you do a great deal of common, routine programming tasks with almost no code, and they did it when C++ was still trying to work out what a string was. For most developers working on so-called business apps -- and that's a very significant fraction of the development world -- such a library can be a huge time-saver. It may not be the best idea, but sometimes things are good enough, and that's what matters to people in that position.
I think reducing this discussion to merely comparing language technicalities would lose most of its value. Yes, the features of a language itself are important, but the relevant thing to developers is what you can do with the whole, not just theoretical advantages or disadvantages you see by comparing parts in isolation and out of context.
The big difference is that in C++ the templates are compiled based on what's actually being used.
That's true. Actually, I find it quite ironic that the generics advocates slam C++ templates for "code bloat" and then compile everything, whether or not it's ever actually going to be useful.:o)
The cheap update deal expired at the end of September IIRC, at least here in the UK. It was being featured fairly prominently on the MS web site and doesn't appear to be there now, so presumably it's gone elsewhere as well.
FWIW, I've seen several sites that provide a similar feature for their fonts. The sizes are hard-coded to preserve the layout, but there's a set of buttons for "normal size", "large text" and "small text", which instantly switch the display as indicated. For sites that are quite clever with their layout, this seems a good compromise if you need to hard-code the text size but still want to cater for a variety of readers.
The primary good reason to fix the width is that readers tend to suffer more-than-usual fatigue reading lines beyond the 65-80 character range.
Unfortunately, that isn't strictly true. It's hard to read text beyond a few inches in width, the exact distance obviously varying with reading distance. That doesn't correspond to a given number of characters or words, however; font size (in pixels), viewable screen size, resolution and such all play a part as well.
The difference is vitally important in fluid design for web sites, because it means you can't insert hard-positioned <br> tags and such. Instead, you need to use tools like max-width (except that almost nothing supports it yet), and <nobr>.
Incidentally, who cares if the latter isn't official W3C standard? It works in pretty much every browser I've ever seen, and as such they should have made it part of standard HTML long ago. I'd far rather use something that's going to work than something that's theoretically standard but not actually supported for 95% of the visiting the site...
As usual, A List Apart offers interesting insights on what can theoretically be done with CSS. What a shame about the browsers.
I've recently been involved in a complete redesign of a fairly large club web site (several dozen pages, several thousand page hits per month). One of our goals was to move from an old, table-based and clunky design to a streamlined system based on XML --XSLT--> HTML and CSS.
We spent a considerable amount of time investigating how the pages rendered on CSS-capable browsers, and ensuring that the HTML degraded to at least a readable form on older browsers.
Almost every attempt to use CSS for anything non-trivial was a complete failure. To give a couple of examples...
Firstly, we have a list of links across the top of each page, and (pretty much as the ALA article describes) we were using an HTML list to represent the content, and then using CSS to format it as a simple horizontal list with dividing bars between the links. This works great...
...Until someone shrinks their browser window, so that it's not wide enough to fit everything on one line, and the list has to wrap. Or just display as complete rubbish, with the border settings that normally make the dividing bars completely mis-rendered, depending on how charitable you're prepared to be. I wouldn't even dream of trying the techniques in the ALA article on a production web site: even current browsers can't handle the underlying concept of using CSS to change how a list renders significantly yet.
Secondly, we're using some fairly standard CSS tricks to get a two-column layout, with a main text column and a second column to its right containing supporting "footnotes", links, etc. Aside from the usual IE-doesn't-understand-boxes and IE-doesn't-understand-float-margins bugs, and the usual workarounds for them, this is working nicely.
So here's an idea: let's have the club's logo as a feint background image behind our main text column. (The logo is a somewhat intricate image that isn't very clear if you shrink it enough to fit as a graphic on the title bar across the top of each page, but works really well as a watermark.) You can set up a watermark by using a CSS background image, and we can position it "fixed" to prevent it scrolling away and enhance the effect without being too distracting when scrolling is required.
No current browser -- not IE6, not the latest Gecko-based ones, none of them -- gets even close to rendering the simple combination of a fixed background image and the usual CSS floating-DIV-to-get-columns tricks correctly. Actually, I was really disappointed with Mozilla's handling: after all the hype about Gecko being so standards compliant, its performance here was worse than IE6 in several respects.
It's perhaps worth noting that with slight tweaks to the CSS, we could get several similar effects to what we wanted, which pretty much confirms that (a) we did understand how the CSS was meant to work, and were using it correctly, and (b) the rendering screw-ups were browser bugs.
So what can we learn from this experience?
Well, our XSLT now generates the menu bar output "raw", without the nicer effects the CSS should have allowed. We still get
| Link 1 | Link 2 | Link 3 |
but the |s are characters not borders, and you can't do any of the nice highlighting effects we were looking for cleanly. It does, however, wrap sensibly in browser windows too narrow to display it all on one line.
We abandoned the idea of using a watermark image. You can have one for a full-width page, but getting it anything close to correctly placed and left there where columns are involved was clearly beyond any current browser.
All in all, we were left with a very disappointed feeling. CSS has such potential, and I hope that the few really good sites (such as ALA) will continue to push the limits of what should be possible. Alas, for now what actually is possible is nothing like the same thing, and that's really the defining rule for any serious web site.
Slashdot Mirror
Ah, that makes sense then; thanks.
I agree entirely that changing the supplied data without warning isn't ACID compliant; in fact, it's quite scary that any serious database would even consider it reasonable behaviour. :-(
With all due respect, you're missing the point. Some DBMSs provide these "non-standard extension" because they are useful. Achieving the same goals with the same reliability in client code would take much more development; why bother, when your database tool already offers the same functionality?
Portability is merely a means to an end, not an end in itself. Lack of portability does not imply a bug, it is simply a design decision to be made by weighing the pros and cons, just like any other. In this case, it seems a decision made one way some time ago is now causing problems, but who knows whether it was the right decision at the time? Maybe if the original development had been done with portability in mind, the extra overhead would have killed the project and there'd be nothing left now on any system.
This issue simply isn't as black and white as you're making it out to be.
OK, you got me. Why can't you just roll back the entire transaction, and issue an error message indicating that the data provided was invalid? How is that in any way non-ACID-compliant? (Or are you saying that PostgreSQL doesn't respond this way, and that's what isn't compliant?)
But many of those are the same open source communities that used to believe you could get something for nothing. Today, even the biggest OSS projects, things like Linux and OpenOffice, have found that ultimately, you do need some source of income if you're going to keep good people working on good output for an extended period. A lot of these projects now have "donation funds" by whatever name, or sell packaged versions of products. Either way, the end user is back to paying for his software again.
Sure, most people don't like adware today. They probably don't like ads on TV or radio either, but as another reply noted, those still exist. I think if it comes down to a choice between adware or paying hard-earned $$$ for free (-as-in-Joe-Public-doesn't-care-as-long-as-it-does n't-cost-anything) software, a significant number of people would probably opt for the adware.
It's interesting that the highest quality (in the sense of low bug count) code I've ever encountered is the source for TeX. IIRC, Knuth used to offer a financial reward for identifying bugs in the code, and a few people did get one, but after a while it was remarkably clean and he pretty much froze it at that point. No big development process. No ISO-certified XP-based integrated-team-managed fuss. Just a good guy, writing good code, and making a genuine effort to have it reviewed by enough competent people.
It's not the only way to make great code, but it's a shining example of what can be done with a bit of talent and a bit of effort in an otherwise pretty dim world.
Unfortunately, now it'll be:
My point was that the post to which I responded advocated not letting you turn it off at all. Indeed, to this day, there is no standard switch in Outlook even in any of the advanced options to switch off this safety feature if you really don't want it. Instead, you have to resort to third party tools -- lucky there are some available for this, isn't it? -- or Dr Regedit, which is way more dangerous to a random end user than most executable attachments you see.
Yes, please, make safety the default. Lock it down out of the box, switch off all the remote comms stuff, get users to add a password when they set it up the first time, whatever. But do let the serious people play with the grown up toys as well. There's no point making an application so safe that it's no longer useful for its original purpose.
I think that's rather harsh.
Ten years ago, several of today's most popular languages (Java, Python, Perl...) were toys if they existed at all. Others (C++, VB) were nowhere near the tools they are today. Many useful extras have been added into these languages during that period.
As for new features being added now, my first response to that was, "What's new about any of these features? Many other languages have had them for years, and those behind Java and C# have just noticed that the critics were right all along."
I wondered about the same thing, and indeed the people behind C++ considered (and rejected) the explicit constraints idea long ago, for this among other reasons.
Another good question is how do you write other plausible constraints, e.g., something generic in terms of two types, one of which can be converted to the other.
That kinds depends on what you mean. Have I "moved to .NET" because I have Visual Studio .Net 2003, and hence a recent version of the framework, installed on my PC at work? I don't use a single .Net thing other than what VS uses itself, nor am I developing for that platform or likely to do so in the near future, but I'm sure MS would love to call me a convert.
As for the next Windows version... Plenty of big players have only just moved to Windows 2000, and that's the one they pretty much got right. I haven't seen Windows XP on anything except a new PC that happened to come with it, though I've seen several people specifically ask for a downgrade to Win2K with their new box on the basis of "tried and tested matters". Everybody moving to WS2003? Not likely.
I'm neither a Microsoft-lover nor a Microsoft-hater, but I do prefer to stick to facts, thanks.
I saw a joke in a major PC magazine not long ago. They were going to run an article on Microsoft's forthcoming (now released) tools to provide Visual Studio-esque kit to Office developers. Unfortunately, they couldn't fit the product name within the available column inches.
People like you are the reason that pages like this exist.
I'm not stupid. I'm fully aware of the risks involved in opening and running an executable file from an untrusted source. I'm also a professional software developer, and I send and receive executable files on a routine basis, as does everyone else I work with. Who are you, or Microsoft's Outlook development team for that matter, to tell me whether or not this is acceptable behaviour?
Sorry, I don't understand your complaint about C++. Pretty much all the standard library containers and algorithms C++ added to what it inherited from C are generic. Actually, a common criticism is that in some cases they're too generic.
I had a great joke to put here, but unfortunately Slashdot doesn't...
I understand both arguments here, and I think there's an element of truth to each. NULL pointer problems are invariably logic errors, yes. But they should also be preventable logic errors; the reason they're not is that C (and, to an extent, C++) do not offer sufficiently powerful high-level features that programmers can avoid low-level nastiness like pointers unless they're really necessary.
The solutions you mention -- exceptions and null objects -- both have their place. So do neat constructs in C++ like:
However, NULL pointers are and always have been a nasty, low-level concept. They don't really mean anything in themselves, they're just used to indicate special cases. Consider a hypothetical language that has
- a solid exception mechanism, for reporting errors
- good support for both disjunctive and conjunctive types, for handling functions that can sensible return several related but different types of information (e.g., a search function that returns "didn't find anything" or information about one or more types of thing that were found)
- a solid object lifetime model
and you're just rendered NULL pointers irrelevant. Instead of risky dereferencing of pointers, you have pattern matching on disjunctive types, so you can only "dereference" in a context where it makes sense. Instead of using "signature values" to indicate errors, you either throw exceptions of as many types as are appropriate, or in non-exceptional cases such as a search not finding anything, you return a disjunctive type. There is no concept of an object disappearing, because you set up the rules such that objects can't disappear when they're still accesssible.Now consider that all of these features are available, today, in many different languages, and the argument that NULL pointers are a low-level problem also has a lot of merit.
I have some sympathy for your point of view, but I'm afraid you give universities way too much credit.
Yep, because academics are well-known for their firm grasp of both software engineering (do you appreciate what that term implies? -- they often don't) and project management. Not.
Academics teaching within their research interests are usually the best guys in that particular business. Academics who've only read a couple of books in preparation for giving a lecture course to postgrads with industry experience are likely to get schooled in fairly short order.
I'm sorry, but that simply isn't true. And I speak as someone with both a formal, academic CS background and plenty of experience in the trenches.
Academics who claim they can get up to the standard of an old pro in a weekend are deluding themselves. Yes, general skills are very important, far more so than any specific language or tool. Yes, someone who's familiar with one imperative language can probably learn another with relative ease. But that still doesn't make up for the lack of experience with the things that matter in an industrial context: you won't know the idioms, the special cases, the gotchas, the workarounds for the gotchas, the sometimes vast and sometimes complicated standard libraries, where to go when those libraries are inadequate for your needs, where to find good quality reference material on the language, its library and ongoing developments in the industry...
There is a difference between being familiar enough to knock up a basic program or maintain someone else's simple code, and having a sufficiently broad and deep knowledge of the tool to write good code in realistic contexts independently. That difference is about 1-2 years of regular use backed up by a reasonable amount of reading around the subject, IME.
Any monkey with a keyboard can whip up "Hello, world!" in C++ as well, and usually with only two basic errors that will get past most compilers. The same monkey, asked to do a significant piece of work, would be a serious liability, particularly if they were arrogant enough to assume from their academic background that they understood the tool they were using and could do no wrong because they "knew how to program".
I think perhaps you're missing the point. Languages are just tools, and what matters to a developer (as opposed to an academic) isn't the fine print in a spec, it's what you can do with the the tool, and whether it helps you to do you job more or less effectively than any other.
In this case, a good IDE including good reference material makes a huge difference. A lot of syntax and complexity that would be awkward if your only tool was a simple text editor can become useful and powerful when your development environment helps.
The same goes for libraries. My long-held personal view is that a small "kernel" library to deal with basics and provide a framework for more advanced features works best, preferably combined with a public repository of extensions that integrate into those frameworks. Perl and CPAN is a good example; (La)TeX and CTAN is another.
Nevertheless, let's not kid ourselves here. People didn't switch to Java because it had GC, at least not just because of that. They switched because it had an enormous library that let you do a great deal of common, routine programming tasks with almost no code, and they did it when C++ was still trying to work out what a string was. For most developers working on so-called business apps -- and that's a very significant fraction of the development world -- such a library can be a huge time-saver. It may not be the best idea, but sometimes things are good enough, and that's what matters to people in that position.
I think reducing this discussion to merely comparing language technicalities would lose most of its value. Yes, the features of a language itself are important, but the relevant thing to developers is what you can do with the whole, not just theoretical advantages or disadvantages you see by comparing parts in isolation and out of context.
That's true. Actually, I find it quite ironic that the generics advocates slam C++ templates for "code bloat" and then compile everything, whether or not it's ever actually going to be useful. :o)
You're missing the point; the new VB.NET spec will be out just as soon as the search-and-replace has finished.
No, he was right the first time. It's undefined behaviour, which is pretty much always broken.
Sorry, couldn't resist.
Neither are C++ templates.
The cheap update deal expired at the end of September IIRC, at least here in the UK. It was being featured fairly prominently on the MS web site and doesn't appear to be there now, so presumably it's gone elsewhere as well.
FWIW, I've seen several sites that provide a similar feature for their fonts. The sizes are hard-coded to preserve the layout, but there's a set of buttons for "normal size", "large text" and "small text", which instantly switch the display as indicated. For sites that are quite clever with their layout, this seems a good compromise if you need to hard-code the text size but still want to cater for a variety of readers.
Unfortunately, that isn't strictly true. It's hard to read text beyond a few inches in width, the exact distance obviously varying with reading distance. That doesn't correspond to a given number of characters or words, however; font size (in pixels), viewable screen size, resolution and such all play a part as well.
The difference is vitally important in fluid design for web sites, because it means you can't insert hard-positioned <br> tags and such. Instead, you need to use tools like max-width (except that almost nothing supports it yet), and <nobr>.
Incidentally, who cares if the latter isn't official W3C standard? It works in pretty much every browser I've ever seen, and as such they should have made it part of standard HTML long ago. I'd far rather use something that's going to work than something that's theoretically standard but not actually supported for 95% of the visiting the site...
As usual, A List Apart offers interesting insights on what can theoretically be done with CSS. What a shame about the browsers.
I've recently been involved in a complete redesign of a fairly large club web site (several dozen pages, several thousand page hits per month). One of our goals was to move from an old, table-based and clunky design to a streamlined system based on XML --XSLT--> HTML and CSS.
We spent a considerable amount of time investigating how the pages rendered on CSS-capable browsers, and ensuring that the HTML degraded to at least a readable form on older browsers.
Almost every attempt to use CSS for anything non-trivial was a complete failure. To give a couple of examples...
Firstly, we have a list of links across the top of each page, and (pretty much as the ALA article describes) we were using an HTML list to represent the content, and then using CSS to format it as a simple horizontal list with dividing bars between the links. This works great...
...Until someone shrinks their browser window, so that it's not wide enough to fit everything on one line, and the list has to wrap. Or just display as complete rubbish, with the border settings that normally make the dividing bars completely mis-rendered, depending on how charitable you're prepared to be. I wouldn't even dream of trying the techniques in the ALA article on a production web site: even current browsers can't handle the underlying concept of using CSS to change how a list renders significantly yet.
Secondly, we're using some fairly standard CSS tricks to get a two-column layout, with a main text column and a second column to its right containing supporting "footnotes", links, etc. Aside from the usual IE-doesn't-understand-boxes and IE-doesn't-understand-float-margins bugs, and the usual workarounds for them, this is working nicely.
So here's an idea: let's have the club's logo as a feint background image behind our main text column. (The logo is a somewhat intricate image that isn't very clear if you shrink it enough to fit as a graphic on the title bar across the top of each page, but works really well as a watermark.) You can set up a watermark by using a CSS background image, and we can position it "fixed" to prevent it scrolling away and enhance the effect without being too distracting when scrolling is required.
No current browser -- not IE6, not the latest Gecko-based ones, none of them -- gets even close to rendering the simple combination of a fixed background image and the usual CSS floating-DIV-to-get-columns tricks correctly. Actually, I was really disappointed with Mozilla's handling: after all the hype about Gecko being so standards compliant, its performance here was worse than IE6 in several respects.
It's perhaps worth noting that with slight tweaks to the CSS, we could get several similar effects to what we wanted, which pretty much confirms that (a) we did understand how the CSS was meant to work, and were using it correctly, and (b) the rendering screw-ups were browser bugs.
So what can we learn from this experience?
Well, our XSLT now generates the menu bar output "raw", without the nicer effects the CSS should have allowed. We still get
but the |s are characters not borders, and you can't do any of the nice highlighting effects we were looking for cleanly. It does, however, wrap sensibly in browser windows too narrow to display it all on one line.
We abandoned the idea of using a watermark image. You can have one for a full-width page, but getting it anything close to correctly placed and left there where columns are involved was clearly beyond any current browser.
All in all, we were left with a very disappointed feeling. CSS has such potential, and I hope that the few really good sites (such as ALA) will continue to push the limits of what should be possible. Alas, for now what actually is possible is nothing like the same thing, and that's really the defining rule for any serious web site.