ancient cathedral's in the middle ages show they have thicker glass on the bottom side of all of the window's
You obviously did not read any of the 3 articles I linked to.
Plate glass used to be made by dipping a tube into molten glass (1000 degrees Fahrenheit or so), gathering up a blob, blowing that blob into a bubble, poking a hole in the bubble, and spinning the tube so that the bubble's hole opens up. Done correctly it makes a flat circle of glass with the end of the tube in the center. This glass is relatively even in thickness but it is still thicker in the middle then at the sides.
They let the glass cool and then cut it into squares with one side closer to the middle. This side is thicker than the rest of the piece and was usually placed toward the bottom of the window because it was reasoned that the heaviest part and strongest part should be at the base. It was not until the Float Glass process was invented in 1959 that truly flat glass was available. Up until then there would almost always be some parts of plate glass that were thicker or wavy, giving rise to the flowing glass myth.
Check youre windows, you will find they are larger at the bottom as it drips.
That's a fallacy. The flow rate of ordinary plate glass is so slow that it would take billions of years before there would be a measurable change in thickness. Here aresome articleson the subject.
Of course, this could have been gotten around by using Bundles, which is a folder that acts like a double-clickable application...When you double-click, it uses whatever binary is appropriate for the system. Unfortunately, this doesn't work for Frameworks, which lack the notion of platform.
Ahh, but that is what fat binaries are for. A fat binary allows you to package up several different versions of a program optimized for different runtime architectures.
Macintoshes have been able to use fat binaries for some time, it was one of the things that allowed the fairly seamless transition from 68k processors to PowerPc processors.
Here is more information on optimizing for the G5, if you look towards the bottom there is notes on packaging an app to run on different processors.
In short: The dock accomplishes all of the functions of most OS' taskbars, menus and so forth in a much simpler, much more powerful, much more intuitive and above all CUSTOMIZABLE fashion. It kicks ass.
I'll tell ya the truth, I really do like the Dock. However, I do think it can be improved.
I think it does too much for one bar. Honestly, I think that the Dock should be split into an open application/document(window) palette and a favorites application/document palette. You should be able to place these two palettes to any side of the screen, pinned to a corner of that side.
The trash should appear on the open items palette, closest to the corner. Applications and documents should be split like they currently are in the Doc. If you put both palettes on the same side of the screen then they have to be pinned to opposite corners, if they grow large enough to touch then they will stay separated by a decent amount of space and they will shrink as items are added to them, just like the Dock does now.
Make both of these Dock palettes appear by user preference and allow both of them to hide and appear just as the Dock does currently. You could also add a user preference that causes an icon to come up onto either palette which calls up the other palette if it is hidden. That way you could, for example, only have the open items palette visible but if you drag an item onto the "unhide" icon the favorites palette will pop up and you can drop the object you are dragging onto it or an item in it.
By separating the Dock into its two different functions you will reduce clutter and confusion. Right now I have a lot of favorite applications, folders, and documents in the Dock for convenience but they clutter up the dock and make it hard to see what is running or minimized. If the Dock was split into these two palettes then it would definitely make life simpler.
How is Quicktime part of this discussion? Apple's iTMS is in AAC format. The iPod supports AAC, MP3, Audible, AIFF, and WAV except WMA.
Actually Apple's iTMS music is in MPEG-4 format, which is virtually identical to the Quicktime container format. The MPEG-4 format was adopted from the Quicktime format. The music in the container format is AAC which has been encrypted by FairPlay, a DRM encryption scheme.
If you look at the files you download from iTMS they have the file extension ".m4p" which stands for MPEG-4 Protected. Tunes that you encode yourself using iTunes AAC are given the extension ".m4a" which stands for MPEG-4 Audio.
The iPod supports both MPEG-4 Protected and MPEG-4 Audio. Both formats use AAC to encode the audio signal. iPods also can play MP3, Audible, AIFF, and WAV.
Windows, Mac OS X, and Linux operating systems all have "licensing nonsense". In fact, the operating system license that probably has the least amount of "nonsense" is the BSD License.
If you look at a page in Safari and OmniWeb, you'll notice that they're different looking though basically the same. I believe OmniWeb does some font work or something like that.
I believe most of the differences are because they are both using a different set of default fonts. I've copied over the font settings that are used in OmniWeb and Safari and now the two look pretty much 100% identical to me. It looks like Lucidia Grande is just a much better font for the job than whatever it was that Safari uses for a default (Times Roman I believe).
And I'm not saying that the folks over at OmniWeb would never have decided to switch to a different rendering library. I'm just saying that once Apple made KHTML so readily available it became almost irresistible to switch to. Prior to that the OmniGroup could have switched to KHTML on their own, it's just that they already had something that mostly worked and the effort of switching to a different rendering engine vs fixing their own engine was too close. Apple's easily available WebKit tilted the balance toward switching for sure.
..and they had the best rendering on the platform. If you have access to a Puma (10.1) system, have a look at IE and OmniWeb side by side.
The rendering was great, I won't dispute that. The problem was the handing of non-standard HTML coding practices. The special cases of buggy code or people writing to IE-specific display errors was the Achilles heal of OmniWeb's (and many other's) rendering. It is extremely difficult to guess exactly what a HTML author wanted the page to look like, given the errors on a page.
This was not much a problem in IE because most pages are tested against IE. If the page rendered incorrectly in IE the page author would fix it until it looked right in IE. However, this means that all other browsers not only have to follow proper HTML parsing rules but also have to accurately emulate IE bugs. This is an extremely difficult task and one in which the authors of OmniWeb were fighting against. Add in the missing CSS and JavaScript features and you can see that even though rendering was great-looking in OmniWeb prior to WebKit, it still had a long way to go.
I think the only thing stopping them prior to Safari and WebCore is that the frameworks didn't exist to allow them to just make use of the system HTML renderer (what were they going to do, use the renderer from the pre-Panther Help viewer? Talk about slow and buggy...).
Well, nothing was stopping them from using the KHTML libraries or one of the other open-source HTML rendering libraries that were out there even before Apple decided to do so. I mean, that's what Apple did. Apple had their own rendering libraries prior to adapting KHTML and they decided that it would be a leap forward to use KHTML rather than continue on with their own internal libraries.
I think the world of OmniGroup, I really do. However, the fact is they stuck with their own internal renderers until the holy grail came along with Apple's announcements of WebCore and JavaScriptCore. Maybe the OmniGroup were considering switching to an open-source library at the time but they didn't make any moves toward using one until after most of the work was already done for them by Apple. There is nothing wrong with that, but you can't say that rendering frameworks didn't exist prior to WebCore because there were several.
what irks me is that prior to the introduction of Safari, Omni could not get a stable browser out the door.
OmniWeb 4 was actually pretty stable and rendered fairly well even before they switched to using WebCore. The only thing that was really missing was some of the CSS support and some of the JavaScript stuff. The main problem the Omni Group had was that they were spending a lot of time chasing sloppy coding that worked in Internet Explorer because people only checked their code in Internet Explorer or they coded to some of the quirks in IE and that broke the rendering in other browers.
The Omni Group finally realized that they were trying to master too many disciplines and they were spending time re-inventing the wheel. They made a smart choice and decided to let someone else worry about rendering web content while they concentrated on solid UI and application design. The merging of the Omni Group's great UI-sense and KHTML's excellent rendering is a dream and they combine to make a wonderful product that is well-worth throwing a few bucks at. Not to mention that you can use the product indefinitely for free and all you'll see a single funny nag message out of a series of a dozen or so every few days.
Now you want me to try and find the story I want by choosing one from a bunch of identical images? No thanks, the blurb in the page title is at least *unique*, I'd like to go by that, please.
If you look at the implementation that OmniWeb 5 is using you will see that it gives you the choice of using either thumbnails or titles. This choice is good because there are many sites that use identical titles for their pages, even when the content is different. With the choice of thumbnails or titles, the user is in control of how they use the "tab" interface that OmniWeb 5 will have.
humans would just naturally adapt to being awake in the PM.
The problems that humans have with too little light are hard-coded into our physical makeup and DNA. Since the human genome hasn't changed substantially in over 10,000 years it is very unlikely that we would evolve quickly enough to offset the effects of not keeping proper Earth-time.
Yes the most extreme effects of losing a second every year would take a considerable amount of time to build up. However, adding a second for every year that needs it is so easy, why not just take the easy way out and adjust our time to match Earth-time. It only makes sense.
Why is this a big deal again? Because human beings are incapable of associating PM with the morning due to our tiny little brains?
It's a big deal for several reasons. First of all, since more people would be driving in the dark to work, half awake, there would be even more accidents than usual. You think that morning commute is bad now?
Secondly, humans are biologically tuned to having a certain amount of daylight each day. It has been shown that people will generally be more sick and less productive if they don't get a shot of daylight right around the start of their day. In fact just the less light we get during the winter causes a sickness called SAD (Seasonally Afflicted Disorder) which causes people to feel listless, depressed, susceptible to colds, and even homicidal and suicidal in extreme cases.
Lastly, there are many outdoor jobs that rely on getting 8 hours of sunlight to accomplish. The people who work these jobs would have to skew their work schedule later and later throughout their career in order to keep pace with the sunlight. Right now an outdoor worker can count on working in the range of 6 AM to 6 PM and then have time to be with their family, friends, etc. By not keeping our time at pace with Earth time there would be a lot more people who would be displaced with regards to the rest of society.
There are other reasons but I think you get my point. We avoid all these problems at the possible cost of a second or two every year that no one but the scientists and engineers really notices. Hmm, seems like a small cost to avoid all these problems.
Being "off" by a few seconds in terms of the Earth's orbit is really no big deal.
It will be a big deal when the sun is overhead at 6PM and it's pitch black when you are driving into work at 6AM. Yes this won't happen for a while, but it will eventually happen if you let the extra seconds add up.
It's much easier to tack on an extra second at the end of the years that need it than adding on an extra minute or hour every so often. This way we are on target for astronomical events. Just think back to the mistake the engineers made when they sent that probe to Mars and they mixed metric and english units up. That was an easy mistake to make but it will be much easier for someone to forget that this year we are off by 47 seconds, thus creating another disaster by not firing a rocket at the right time.
These sort of concerns will only get more important as we become a spacefaring society. Accurate timekeeping, especially in relation to a planet's local time, will be of utmost importance for safety and costs.
Actually I have nothing against Democrats. Both Democrats and Republicans (and every other political party) have their good and their bad. I posted it because I personally think that Hillary Clinton does spew gibberish.
I'm sure that there are Republicans that do the same. Now that I think about it, Rush Limbaugh is a Republican who falls into the "gibberish spewer" category. On the Democrat side I feel that Joe Lieberman is an example of a Democrat who says some very intelligent things and is a positive example of the party. Too bad he had to run for Vice President with that doorstop, Al Gore.
So don't be so quick to assume this is an attack on Democrats, it's not.
I came very close to buying OmniWeb 4.x, but two things really killed it for me: the lack of tabbed browsing, and the lack of integration with the keychain. There are a few very bad crashers, too.
I've had a few crashes with the latest versions of OmniWeb, but nothing to write home about. I'd say I get maybe a crash a week, under very heavy use.
I use the keychain with OmniWeb all the time, there doesn't seem to be any negative issues there. Seems to work great.
Tabs, yeah that's something not in OmniWeb and I'm not sure when or if it will ever be. I could give or take tabs though, the benefits of OmniWeb outweigh the lack of tabs - at least for me.
The best thing though is the responsiveness of the people over at The Omni Group. If I send in feedback they are great about asking me for more details and I've even had a few features added that I (and probably quite a few others) thought would be cool. I paid like $20 for OmniWeb 2 years ago and that purchase is still good for full updates and everything. I don't know if it will apply for version 5.0 but I really wouldn't mind giving them a little more cash, I've definitely gotten my use out of that $20.
Konq doesn't pass basic CSS tests that I have written.
Well I'm not using Konqueror but I am using OmniWeb, which uses WebCore, a Mac OS X port of KHTML. That example CSS page renders exactly the same as your reference image. I also tried Safari, another browser which uses WebCore, and it also rendered you web page identically to your reference image.
So it seems that the KHTML-based applications can handle your CSS tests properly. Perhaps Konqueror is doing something odd that is causing problems with CSS or maybe there is some other kind of interference with the test but I wouldn't dismiss it entirely. Bug it to the Konqueror people, I'm sure it's something that can be fixed up quick if KHTML is already handling this stuff properly.
Of course you can enable some of these features on Safari through the hidden Debug menu and add-ons, but it is much less complicated just to get OmniWeb and have these features supported and easy to get at.
Like I said, Safari is nice but OmniWeb is similar to Safari Pro when compared to Safari. If OmniWeb included a tabbed browsing option it would pretty much surpass Safari in almost every way. OmniWeb is not as lean, simple, or quick as Safari but the advantages that Safari has over OmniWeb are very small.
many of the things you list are there natively in Konqueror; I wonder, then, why Apple left them out
Apple didn't port Konqueror, they ported KHTML and its associated libraries. This became WebCore, the rendering and JavaScript engine that now comes as a part of Mac OS X. WebCore is used by Safari, OmniWeb, and several other application to handle their rendering and some other jobs that a web browser needs to handle.
So I'm sure that Konqueror is quite a bit different than Safari or OmniWeb, although they all use the same or similar rendering engines they are all quite different front ends to that renderer. They all sound like they are great programs, but each has its own features/disadvantages.
omniweb is safari in drag. and konqueror, although nice it is finally ported, is more or less for proof of concept. opera for mac isn't even up to 7.0 yet if i remember right, with opera being all pissed at apple releasing safari. so that really leaves you with safari, and the mozilla browsers.
OmniWeb may use the same underlying rendering and scripting engine that Safari uses but it is actually quite different than Safari. They are both great products but OmniWeb by far provides you with more functionality
About the only thing that Safari has over OmniWeb is tabbed browsing. OmniWeb has many more options than Safari such as regex filtering of content from sites, the ability to easily masquerade as any type of browser running on any type of operating system, autofilling of forms, tons of display options, the ability to set up shortcuts for the url input line ("google something" starts a Google search for something, "dict something" looks up something in dictionary.com, etc), and much more.
I'm not knocking Safari, it's a really nice, lean browser but its feature set is almost too lean. OmniWeb is kind of like a full-featured version of Safari.
keep an eye out for out-of-hours connections to the wireless access point and block their MAC address.
Right, my main point is that there is no simple answer like keeping the access point 100% open thinking that you'll automatically spot an abuser. You really need some sort of router between the access point and the internet which has the ability to log accesses, limit connection times and bandwidth use, and provide some sort of accountability in case some one does abuse your connection to do something nasty.
When the feds come knocking on your door claiming you just tried to hack into NORAD you want to be able to point to your logs and say, "It's not me playing Global Thermonuclear War, it's this guy!"
Slashdot Mirror
You obviously did not read any of the 3 articles I linked to.
Plate glass used to be made by dipping a tube into molten glass (1000 degrees Fahrenheit or so), gathering up a blob, blowing that blob into a bubble, poking a hole in the bubble, and spinning the tube so that the bubble's hole opens up. Done correctly it makes a flat circle of glass with the end of the tube in the center. This glass is relatively even in thickness but it is still thicker in the middle then at the sides.
They let the glass cool and then cut it into squares with one side closer to the middle. This side is thicker than the rest of the piece and was usually placed toward the bottom of the window because it was reasoned that the heaviest part and strongest part should be at the base. It was not until the Float Glass process was invented in 1959 that truly flat glass was available. Up until then there would almost always be some parts of plate glass that were thicker or wavy, giving rise to the flowing glass myth.
That's a fallacy. The flow rate of ordinary plate glass is so slow that it would take billions of years before there would be a measurable change in thickness. Here are some articles on the subject.
Uh, I don't know what Americans you've been talking to but I haven't heard anything like that from any American that I know of.
You might want to check your sources again, maybe they weren't really Americans at all...
Ahh, but that is what fat binaries are for. A fat binary allows you to package up several different versions of a program optimized for different runtime architectures.
Macintoshes have been able to use fat binaries for some time, it was one of the things that allowed the fairly seamless transition from 68k processors to PowerPc processors.
Here is more information on optimizing for the G5, if you look towards the bottom there is notes on packaging an app to run on different processors.
I'll tell ya the truth, I really do like the Dock. However, I do think it can be improved.
I think it does too much for one bar. Honestly, I think that the Dock should be split into an open application/document(window) palette and a favorites application/document palette. You should be able to place these two palettes to any side of the screen, pinned to a corner of that side.
The trash should appear on the open items palette, closest to the corner. Applications and documents should be split like they currently are in the Doc. If you put both palettes on the same side of the screen then they have to be pinned to opposite corners, if they grow large enough to touch then they will stay separated by a decent amount of space and they will shrink as items are added to them, just like the Dock does now.
Make both of these Dock palettes appear by user preference and allow both of them to hide and appear just as the Dock does currently. You could also add a user preference that causes an icon to come up onto either palette which calls up the other palette if it is hidden. That way you could, for example, only have the open items palette visible but if you drag an item onto the "unhide" icon the favorites palette will pop up and you can drop the object you are dragging onto it or an item in it.
By separating the Dock into its two different functions you will reduce clutter and confusion. Right now I have a lot of favorite applications, folders, and documents in the Dock for convenience but they clutter up the dock and make it hard to see what is running or minimized. If the Dock was split into these two palettes then it would definitely make life simpler.
Actually Apple's iTMS music is in MPEG-4 format, which is virtually identical to the Quicktime container format. The MPEG-4 format was adopted from the Quicktime format. The music in the container format is AAC which has been encrypted by FairPlay, a DRM encryption scheme.
If you look at the files you download from iTMS they have the file extension ".m4p" which stands for MPEG-4 Protected. Tunes that you encode yourself using iTunes AAC are given the extension ".m4a" which stands for MPEG-4 Audio.
The iPod supports both MPEG-4 Protected and MPEG-4 Audio. Both formats use AAC to encode the audio signal. iPods also can play MP3, Audible, AIFF, and WAV.
Keep calling them out and I'll keep adding them to my foes list, good call!
Right, and Linux has no "licensing nonsense" at all, does it?
Windows, Mac OS X, and Linux operating systems all have "licensing nonsense". In fact, the operating system license that probably has the least amount of "nonsense" is the BSD License.
I believe most of the differences are because they are both using a different set of default fonts. I've copied over the font settings that are used in OmniWeb and Safari and now the two look pretty much 100% identical to me. It looks like Lucidia Grande is just a much better font for the job than whatever it was that Safari uses for a default (Times Roman I believe).
And I'm not saying that the folks over at OmniWeb would never have decided to switch to a different rendering library. I'm just saying that once Apple made KHTML so readily available it became almost irresistible to switch to. Prior to that the OmniGroup could have switched to KHTML on their own, it's just that they already had something that mostly worked and the effort of switching to a different rendering engine vs fixing their own engine was too close. Apple's easily available WebKit tilted the balance toward switching for sure.
The rendering was great, I won't dispute that. The problem was the handing of non-standard HTML coding practices. The special cases of buggy code or people writing to IE-specific display errors was the Achilles heal of OmniWeb's (and many other's) rendering. It is extremely difficult to guess exactly what a HTML author wanted the page to look like, given the errors on a page.
This was not much a problem in IE because most pages are tested against IE. If the page rendered incorrectly in IE the page author would fix it until it looked right in IE. However, this means that all other browsers not only have to follow proper HTML parsing rules but also have to accurately emulate IE bugs. This is an extremely difficult task and one in which the authors of OmniWeb were fighting against. Add in the missing CSS and JavaScript features and you can see that even though rendering was great-looking in OmniWeb prior to WebKit, it still had a long way to go.
Well, nothing was stopping them from using the KHTML libraries or one of the other open-source HTML rendering libraries that were out there even before Apple decided to do so. I mean, that's what Apple did. Apple had their own rendering libraries prior to adapting KHTML and they decided that it would be a leap forward to use KHTML rather than continue on with their own internal libraries.
I think the world of OmniGroup, I really do. However, the fact is they stuck with their own internal renderers until the holy grail came along with Apple's announcements of WebCore and JavaScriptCore. Maybe the OmniGroup were considering switching to an open-source library at the time but they didn't make any moves toward using one until after most of the work was already done for them by Apple. There is nothing wrong with that, but you can't say that rendering frameworks didn't exist prior to WebCore because there were several.
OmniWeb 4 was actually pretty stable and rendered fairly well even before they switched to using WebCore. The only thing that was really missing was some of the CSS support and some of the JavaScript stuff. The main problem the Omni Group had was that they were spending a lot of time chasing sloppy coding that worked in Internet Explorer because people only checked their code in Internet Explorer or they coded to some of the quirks in IE and that broke the rendering in other browers.
The Omni Group finally realized that they were trying to master too many disciplines and they were spending time re-inventing the wheel. They made a smart choice and decided to let someone else worry about rendering web content while they concentrated on solid UI and application design. The merging of the Omni Group's great UI-sense and KHTML's excellent rendering is a dream and they combine to make a wonderful product that is well-worth throwing a few bucks at. Not to mention that you can use the product indefinitely for free and all you'll see a single funny nag message out of a series of a dozen or so every few days.
OmniWeb can use the same plug-ins that work on Mozilla or Netscape. So I would say no, you don't need to pay to develop for OmniWeb.
If you look at the implementation that OmniWeb 5 is using you will see that it gives you the choice of using either thumbnails or titles. This choice is good because there are many sites that use identical titles for their pages, even when the content is different. With the choice of thumbnails or titles, the user is in control of how they use the "tab" interface that OmniWeb 5 will have.
The problems that humans have with too little light are hard-coded into our physical makeup and DNA. Since the human genome hasn't changed substantially in over 10,000 years it is very unlikely that we would evolve quickly enough to offset the effects of not keeping proper Earth-time.
Yes the most extreme effects of losing a second every year would take a considerable amount of time to build up. However, adding a second for every year that needs it is so easy, why not just take the easy way out and adjust our time to match Earth-time. It only makes sense.
It's a big deal for several reasons. First of all, since more people would be driving in the dark to work, half awake, there would be even more accidents than usual. You think that morning commute is bad now?
Secondly, humans are biologically tuned to having a certain amount of daylight each day. It has been shown that people will generally be more sick and less productive if they don't get a shot of daylight right around the start of their day. In fact just the less light we get during the winter causes a sickness called SAD (Seasonally Afflicted Disorder) which causes people to feel listless, depressed, susceptible to colds, and even homicidal and suicidal in extreme cases.
Lastly, there are many outdoor jobs that rely on getting 8 hours of sunlight to accomplish. The people who work these jobs would have to skew their work schedule later and later throughout their career in order to keep pace with the sunlight. Right now an outdoor worker can count on working in the range of 6 AM to 6 PM and then have time to be with their family, friends, etc. By not keeping our time at pace with Earth time there would be a lot more people who would be displaced with regards to the rest of society.
There are other reasons but I think you get my point. We avoid all these problems at the possible cost of a second or two every year that no one but the scientists and engineers really notices. Hmm, seems like a small cost to avoid all these problems.
It will be a big deal when the sun is overhead at 6PM and it's pitch black when you are driving into work at 6AM. Yes this won't happen for a while, but it will eventually happen if you let the extra seconds add up.
It's much easier to tack on an extra second at the end of the years that need it than adding on an extra minute or hour every so often. This way we are on target for astronomical events. Just think back to the mistake the engineers made when they sent that probe to Mars and they mixed metric and english units up. That was an easy mistake to make but it will be much easier for someone to forget that this year we are off by 47 seconds, thus creating another disaster by not firing a rocket at the right time.
These sort of concerns will only get more important as we become a spacefaring society. Accurate timekeeping, especially in relation to a planet's local time, will be of utmost importance for safety and costs.
Actually I have nothing against Democrats. Both Democrats and Republicans (and every other political party) have their good and their bad. I posted it because I personally think that Hillary Clinton does spew gibberish.
I'm sure that there are Republicans that do the same. Now that I think about it, Rush Limbaugh is a Republican who falls into the "gibberish spewer" category. On the Democrat side I feel that Joe Lieberman is an example of a Democrat who says some very intelligent things and is a positive example of the party. Too bad he had to run for Vice President with that doorstop, Al Gore.
So don't be so quick to assume this is an attack on Democrats, it's not.
There are several other books that are also filled with undecipherable gibberish that no one can understand. Here is another famous example.
I've had a few crashes with the latest versions of OmniWeb, but nothing to write home about. I'd say I get maybe a crash a week, under very heavy use.
I use the keychain with OmniWeb all the time, there doesn't seem to be any negative issues there. Seems to work great.
Tabs, yeah that's something not in OmniWeb and I'm not sure when or if it will ever be. I could give or take tabs though, the benefits of OmniWeb outweigh the lack of tabs - at least for me.
The best thing though is the responsiveness of the people over at The Omni Group. If I send in feedback they are great about asking me for more details and I've even had a few features added that I (and probably quite a few others) thought would be cool. I paid like $20 for OmniWeb 2 years ago and that purchase is still good for full updates and everything. I don't know if it will apply for version 5.0 but I really wouldn't mind giving them a little more cash, I've definitely gotten my use out of that $20.
Well I'm not using Konqueror but I am using OmniWeb, which uses WebCore, a Mac OS X port of KHTML. That example CSS page renders exactly the same as your reference image. I also tried Safari, another browser which uses WebCore, and it also rendered you web page identically to your reference image.
So it seems that the KHTML-based applications can handle your CSS tests properly. Perhaps Konqueror is doing something odd that is causing problems with CSS or maybe there is some other kind of interference with the test but I wouldn't dismiss it entirely. Bug it to the Konqueror people, I'm sure it's something that can be fixed up quick if KHTML is already handling this stuff properly.
Of course you can enable some of these features on Safari through the hidden Debug menu and add-ons, but it is much less complicated just to get OmniWeb and have these features supported and easy to get at.
Like I said, Safari is nice but OmniWeb is similar to Safari Pro when compared to Safari. If OmniWeb included a tabbed browsing option it would pretty much surpass Safari in almost every way. OmniWeb is not as lean, simple, or quick as Safari but the advantages that Safari has over OmniWeb are very small.
Apple didn't port Konqueror, they ported KHTML and its associated libraries. This became WebCore, the rendering and JavaScript engine that now comes as a part of Mac OS X. WebCore is used by Safari, OmniWeb, and several other application to handle their rendering and some other jobs that a web browser needs to handle.
So I'm sure that Konqueror is quite a bit different than Safari or OmniWeb, although they all use the same or similar rendering engines they are all quite different front ends to that renderer. They all sound like they are great programs, but each has its own features/disadvantages.
OmniWeb may use the same underlying rendering and scripting engine that Safari uses but it is actually quite different than Safari. They are both great products but OmniWeb by far provides you with more functionality
About the only thing that Safari has over OmniWeb is tabbed browsing. OmniWeb has many more options than Safari such as regex filtering of content from sites, the ability to easily masquerade as any type of browser running on any type of operating system, autofilling of forms, tons of display options, the ability to set up shortcuts for the url input line ("google something" starts a Google search for something, "dict something" looks up something in dictionary.com, etc), and much more.
I'm not knocking Safari, it's a really nice, lean browser but its feature set is almost too lean. OmniWeb is kind of like a full-featured version of Safari.
Right, my main point is that there is no simple answer like keeping the access point 100% open thinking that you'll automatically spot an abuser. You really need some sort of router between the access point and the internet which has the ability to log accesses, limit connection times and bandwidth use, and provide some sort of accountability in case some one does abuse your connection to do something nasty.
When the feds come knocking on your door claiming you just tried to hack into NORAD you want to be able to point to your logs and say, "It's not me playing Global Thermonuclear War, it's this guy!"