]You are correct in what you're saying about this. The problem is that the browser should be able to detect these problems, and push the rest of the page down to accommodate them.
This is exactly the sort of problem that slows down browsers with bloat. This is the [well, a] reason why Internet Explorer has been messed up for so long, and why it has so many rendering problems (hopefully to be addressed more in IE8). When the browser has to check for poor design or coding it has to do it routinely while browsing, and all of this adds up. This is why most modern browser developers refuse to do much of this at all (be it Webkit or Mozilla).
There's another snag to worry about here... if Safari corrected this they would be causing CSS to behave in a nonstandard way. It may work great at Macworld but on other sites would certainly lead to unexpected behavior which would, in turn, be reported as browser bugs (and rightfully so). If you set a float element as relative and it becomes too big it is supposed to kick down to the line below. If there's an item there with a static location, the two overlap. I'm not sure how the engineers could program around that without causing other problems.
It is too bad Macworld ignores the issue. Maybe if more people wrote them?
Quote:
Originally Posted by melgross
]The bigger problem in my mind is the column with error in Safari, which seems to not addressed by most people here. Fonts are something that can be resolved by changing sizes, but nothing can be done about the hidden right side of the column. That's much more serious, as information is hidden, and can't be retrieved.
CSS gives the author complete control over these things -- and the ability to mess them up, too. Some of these problems are hot discussion topics among web designers, but the problem is these things aren't really discussed in college. Web design is more than knowing code and cross-platform compatibility, but companies either don't realize this, or aren't willing to pay the right fees to retain a true professional.
What's sad is that it shouldn't take more than an hour to fix a problem like this, depending on familiarity with and quality of the style sheets that already exist. If they've got someone working in-house -- which they probably do -- they should be able to address this without much trouble.
One thing many sites do when there are menu elements which would break if resized is offer in-page resizing capabilities (ala wired.com and others). This gives the site author control over how resizing works and what is actually resized, thus allowing large font sizes to be displayed without breaking anything. This would require much more dedicated work, though, and possibly a site redesign if Macworld is depending on old code or HTML for too much presentation.
This is exactly the sort of problem that slows down browsers with bloat. This is the reason why Internet Explorer has been messed up for so long, and why it has so many rendering problems (hopefully to be addressed more in IE8). When the browser has to check for poor design or coding it has to do it routinely while browsing, and all of this adds up. This is why most modern browser developers refuse to do much of this at all (be it Webkit or Mozilla).
There's another snag to worry about here... if Safari corrected this they would be causing CSS to behave in a nonstandard way. It may work great at Macworld but on other sites would certainly lead to unexpected behavior which would, in turn, be reported as browser bugs (and rightfully so). If you set a float element as relative and it becomes too big it is supposed to kick down to the line below. If there's an item there with a static location, the two overlap. I'm not sure how the engineers could program around that without causing other problems.
It is too bad Macworld ignores the issue. Maybe if more people wrote them?
The difficulty here is that many web developers will NEVER bother to correct these problems. If Macworld can't check to see if Safari is having a problem, then who else will bother?
Because of this, I, as a user, don't give the traditional rats' ass how much trouble it is for the browser programmers. I want to have a good experience, and damn the work. That's what they're paid for.
The problem with standards is that if everyone doesn't adhere to them, they aren't standard.
If Firefox gets around most of these problems, then Apple's product should be able to as well. Many times Apple modifies their OS to work with certain programs, they can certainly take a look at these problems, and fix them. We know it can be done.
Quote:
CSS gives the author complete control over these things -- and the ability to mess them up, too. Some of these problems are hot discussion topics among web designers, but the problem is these things aren't really discussed in college. Web design is more than knowing code and cross-platform compatibility, but companies either don't realize this, or aren't willing to pay the right fees to retain a true professional.
What's sad is that it shouldn't take more than an hour to fix a problem like this, depending on familiarity with and quality of the style sheets that already exist. If they've got someone working in-house -- which they probably do -- they should be able to address this without much trouble.
One thing many sites do when there are menu elements which would break if resized is offer in-page resizing capabilities (ala wired.com and others). This gives the site author control over how resizing works and what is actually resized, thus allowing large font sizes to be displayed without breaking anything. This would require much more dedicated work, though, and possibly a site redesign if Macworld is depending on old code or HTML for too much presentation.
I won't argue this, but as I said, firefox handles it without a problem, so there's no reason why Safari couldn't.
It's far better for the user to expect that their one program can render the thousands of sites they visit, properly, than to expect those thousands of sites to fix their problems.
The difficulty here is that many web developers will NEVER bother to correct these problems. If Macworld can't check to see if Safari is having a problem, then who else will bother?
Sadly, many sites which don't even deploy for an OS X userbase do a much better job. Macworld's poor approach to this matter should not be considered representative of the whole.
Quote:
Originally Posted by melgross
Because of this, I, as a user, don't give the traditional rats' ass how much trouble it is for the browser programmers. I want to have a good experience, and damn the work. That's what they're paid for.
It has nothing to do with how much work they put in. It has to do with quality of product. You, the user, do care about how fast your browser is, and you will care when patchwork breaks another of your favorite sites.
Quote:
Originally Posted by melgross
The problem with standards is that if everyone doesn't adhere to them, they aren't standard.
1) You're talking about two different meanings of the word here. A standard is presented and people may choose to adhere to it, but simply because one group choses to ignore it (frequently Microsoft), that doesn't mean it isn't a standard.
2) You can ask all you want for people to do this sort of thing, but unless you are willing to educate yourself in the mechanics behind what is happening here -- and admittedly, it takes more than an evening of study to understand CSS2 -- you're not going to be in a good position to dictate terms to experienced engineers. This is like telling Apple to patch OS X to expect certain major bugs because a software developer can't be bothered to update their software. It just doesn't work that way.
I want Macworld to work great too. It doesn't, though, and it is because they can't be bothered to put some small effort into correcting their site. That content has to go somewhere, though, and the choices are:
1) Don't resize the text.
2) Overlap horizontally (good luck).
3) Overlap based on standards (what is happening here).
4) Override style sheet instructions and move static elements (bad idea).
5) Let people mess up their own web pages (also something that is happening here).
Quote:
Originally Posted by melgross
If Firefox gets around most of these problems, then Apple's product should be able to as well. Many times Apple modifies their OS to work with certain programs, they can certainly take a look at these problems, and fix them. We know it can be done.
Firefox doesn't come out much better, looking at it now. It survives the first font size increase but things get ugly after two. The spacing is inconsistent and it is tough to identify the source of a problem like that. The code would have to be studied. At least the overlap isn't anywhere near as bad.
What it boils down to, though, is that you are asking the webkit developers to address an obscure issue which relies primarily on the site designer(s). If this particular problem was widespread they should indeed consider their approach, but if it is not we should not expect much from them.
If this really bothers you and you must have your font size increased at Macworld you might consider getting members here to write them or starting a petition. Or, everyone bothered by this can start going to that page, duplicating the problem, and clicking on the bug report button in Safari to send a screenshot and description to the developers behind Webkit/Safari. If they identify a solution relative to their own code which does not require breaking standards they'll likely fix it up. But they're probably not going to give it much thought if it isn't reported to them. I'll submit my report to them now to do my part.
Quote:
Originally Posted by melgross
It's far better for the user to expect that their one program can render the thousands of sites they visit, properly, than to expect those thousands of sites to fix their problems.
Are there thousands of sites breaking like this in Safari when font sizes are increased but not breaking in other browsers? That is the question to ask here. There are thousands of sites out there breaking when font sizes are increased but this is due to the difficulties of designing a complicated commercial site with support for universal font size increases. The only sure-fire solution to this is page zooming (as done on the iPhone and in Opera).
Sadly, many sites which don't even deploy for an OS X userbase do a much better job. Macworld's poor approach to this matter should not be considered representative of the whole.
Unfortunately, Macworld is far from being the only offender. If it were, I wouldn't even bother to mention it.
Quote:
It has nothing to do with how much work they put in. It has to do with quality of product. You, the user, do care about how fast your browser is, and you will care when patchwork breaks another of your favorite sites.
We've all had our quality of product woes over the years with Safari. It seems stable now, but it isn't the only stable browser out there.
Quote:
1) You're talking about two different meanings of the word here. A standard is presented and people may choose to adhere to it, but simply because one group choses to ignore it (frequently Microsoft), that doesn't mean it isn't a standard.
2) You can ask all you want for people to do this sort of thing, but unless you are willing to educate yourself in the mechanics behind what is happening here -- and admittedly, it takes more than an evening of study to understand CSS2 -- you're not going to be in a good position to dictate terms to experienced engineers. This is like telling Apple to patch OS X to expect certain major bugs because a software developer can't be bothered to update their software. It just doesn't work that way.
I understand two things.
1 What a "standard" is. But, you have to understand that if a standard isn't being applied across most systems, it isn't really a standard. It doesn't matter how many bodies give their approval. Like it or not, IE's "standards" have been the web's standards as well, as most sites hewed to them. When something is not defined as a standard, but is used as such, then it is the defacto standard, like it or not.
2 I understand what is happening here. That doesn't mean that I either like it, or agree with it.
Sometimes, in the course of events, decisions must be made that lead to a non "pure" system, because of factors that are beyond your control. This is one of those cases. It rarely pays to be alone, wandering in the dark, simply because you think you are right, as Apple often does.
Quote:
I want Macworld to work great too. It doesn't, though, and it is because they can't be bothered to put some small effort into correcting their site. That content has to go somewhere, though, and the choices are:
1) Don't resize the text.
2) Overlap horizontally (good luck).
3) Overlap based on standards (what is happening here).
4) Override style sheet instructions and move static elements (bad idea).
5) Let people mess up their own web pages (also something that is happening here).
Unfortunately, some of that only works for some elements, and others aren't under our control at all.
Quote:
Firefox doesn't come out much better, looking at it now. It survives the first font size increase but things get ugly after two. The spacing is inconsistent and it is tough to identify the source of a problem like that. The code would have to be studied. At least the overlap isn't anywhere near as bad.
Yes, you have go to more extreme settings before the problem sets in. That means that it rarely does set in.
Quote:
What it boils down to, though, is that you are asking the webkit developers to address an obscure issue which relies primarily on the site designer(s). If this particular problem was widespread they should indeed consider their approach, but if it is not we should not expect much from them.
If this really bothers you and you must have your font size increased at Macworld you might consider getting members here to write them or starting a petition. Or, everyone bothered by this can start going to that page, duplicating the problem, and clicking on the bug report button in Safari to send a screenshot and description to the developers behind Webkit/Safari. If they identify a solution relative to their own code which does not require breaking standards they'll likely fix it up. But they're probably not going to give it much thought if it isn't reported to them. I'll submit my report to them now to do my part.
Are there thousands of sites breaking like this in Safari when font sizes are increased but not breaking in other browsers? That is the question to ask here. There are thousands of sites out there breaking when font sizes are increased but this is due to the difficulties of designing a complicated commercial site with support for universal font size increases. The only sure-fire solution to this is page zooming (as done on the iPhone and in Opera).
It's a widespread issue. Not every site has the problem, but many do. As I said, if it were only Macworld, I would only bother them.
But, as I also said, that's an annoyance, but not a major problem. It's the problem with the columns that constitutes the real problem, as nothing I have ever done has been able to correct it, other than to go to Firefox.
I have to agree with everyone else: Safari 3 is much worse than Safari 2 in terms of stability. I've actually switched back to Firefox more than half the time!!!! It crashes WAY too much. And when are they going to add features? They haven't added anything since 0.8 except Tabs, RSS, and now WebClips (which is pretty cool.) Maybe I'm missing something but it just seems like the development is glacial.
I mean how many more years is going to take for a History and Downloads window that are actually useful, can catch up to IE from oh say almost a DECADE ago. It's, well, embarrassing. Safari is the application I use or used to use the most. This is probably true for a lot of other people. I feel like Apple is devoting a lot less people to it than they could or probably should. When it came out it was like hey the Bookmarks library is awesome! But the crashing, slow performance, bugs, and incompatibility continue to be present and in fact have become much worse in 3. I hear 3.1 has a ton of improvements in these areas and I actually have high hopes for 3.1, and I hope I can replace Firefox with Safari once again in my Dock.
The only time Safari 3 has ever crashed on me is when my CS3 package got messed up. Whenever I tried to download a PDF Acrobat failed to launch properly and Safari locked up when things didn't pan out. Aside from that, it has been great.
Quote:
Originally Posted by melgross
1 What a "standard" is. But, you have to understand that if a standard isn't being applied across most systems, it isn't really a standard. It doesn't matter how many bodies give their approval. Like it or not, IE's "standards" have been the web's standards as well, as most sites hewed to them. When something is not defined as a standard, but is used as such, then it is the defacto standard, like it or not.
IE's behavior hails back to the days of IE vs. Netscape in which there were no standards. Nobody who remembers the consequences of that could ever hope for it to return. Since then, IE has done very little to support unified features across browsers. In fact, when Netscape died IE development screeched to a crawl and they hardly even bothered to progress with new features. It was only when things got ugly that they got off their behinds again and got to work.
I cannot see how you can call that a standard by any stretch of the word.
Websites were jacked up because people designed only for IE (why bother when they had a 90%+ market share?) and left everything else to its own devices. Microsoft worked hard to make sure all sorts of broken code worked in their browser. The Web Standards Project, and other initiatives, helped to turn this around, and helped to bring alternatives like Firefox into prominence. This is a good thing, and so is change.
And in the world of the internet, you've never been able to please everyone.
Quote:
Originally Posted by melgross
Sometimes, in the course of events, decisions must be made that lead to a non "pure" system, because of factors that are beyond your control. This is one of those cases. It rarely pays to be alone, wandering in the dark, simply because you think you are right, as Apple often does.
Decisions like this are made all the time. A web author, for example, can have browsers clean up after their mistakes by leaving out a doctype. That places browsers in quirks mode, slows them down, and prompts them to look for mistakes that need to be cleaned up. When a designer includes a doctype it tells the browser how strict it should be with rendering, speeding it up in the process. That doesn't apply directly to this problem as it is more a matter of poor code (on that note I checked Macworld's code, and it is indeed poor) but it is representative of the efforts these people try to make.
Back to the discussion at hand, there is no browser which zooms in this way which does it elegantly of pages designed to fit in static confines. Some pages fail more gracefully in one browser than the other (anyone remember what used to happen at Roughly Drafted when you zoomed in using Firefox?) but it is tough to say which browser fails on more. It is something that could be considered. I think the only reasonable expectation we could make of the engineers behind our beloved Apple browser is that they continue looking for ways to make their zooming technology a little more graceful across the board.
But under no circumstance does this forgive a page designer for producing bad code.
Quote:
Originally Posted by melgross
Unfortunately, some of that only works for some elements, and others aren't under our control at all.
I should have specified. I was outlining the software engineers' choices.
Quote:
Originally Posted by melgross
Yes, you have go to more extreme settings before the problem sets in. That means that it rarely does set in.
If we're to entertain a valid discussion about this we have to identify a failure which Safari is making consistently across pages that Firefox, for example, is not. The way in which Macworld fails is not going to be of much use to us as it is the result of bad design. And there's no sense in asking the Safari engineers to 'do it like Firefox does'.
Are you really noticing more problems in Safari than Firefox?
I just went to a bunch of sites I know well -- including many which I know a lot about -- and the failures were pretty consistent across both browsers. The only times I see major failures tend to be in cases where there is a glaring mistake or oversight in the site design or code.
Quote:
Originally Posted by melgross
But, as I also said, that's an annoyance, but not a major problem. It's the problem with the columns that constitutes the real problem, as nothing I have ever done has been able to correct it, other than to go to Firefox.
Do you know a little bit about CSS2? Or floats? You could jot a note in your user style sheet to fix it up pretty darn fast. Unfortunately that's about all we could hope to do short of getting them off their behinds.
If this really bothers you and you must have your font size increased at Macworld you might consider getting members here to write them or starting a petition. Or, everyone bothered by this can start going to that page, duplicating the problem, and clicking on the bug report button in Safari to send a screenshot and description to the developers behind Webkit/Safari. If they identify a solution relative to their own code which does not require breaking standards they'll likely fix it up. But they're probably not going to give it much thought if it isn't reported to them. I'll submit my report to them now to do my part.
Or we could just fix the Macworld.com CSS and send them a fixed stylesheet.
I had a brief look though and they're just making a couple of basic assumptions wrong which trickle through and cause problems when font sizes change.
One of the features I've always wanted in Safari is site by site CSS substitution so I can redesign existing sites. You can probably do it with a Firefox plugin but I really can't stand Firefox - it's just not a good OSX citizen.
Mel, the reason it takes two font size changes to create a similarly large problem in Firefox is because Firefox renders the font smaller in the first place as they don't use Apple's system wide smoothing and kerning for text. They also substitute the wrong font when the real font is available and don't pick up on font hints. It's one of the things that drives me potty with Firefox and why I won't touch the thing professionally until testing rounds. At that point I may find Firefox renders things subtly differently to Safari but that's their loss. IE on the other hand can still be a major pain in the arse and I'll fix for that, but rarely do I try to match Firefox up exactly, pixel for pixel with Safari.
Or we could just fix the Macworld.com CSS and send them a fixed stylesheet.
That's an option.
I messed around with it for a moment. A better solution could be devised to solve the red bleed-down under the black-background links (rather than overflow) and there is probably a better solution for the descriptive paragraph up there near the top than to give it a fixed width, but this is a start at least:
(It would really be easy for someone familiar with their style sheet.
I didn't even look at it -- I just applied some patches.)
This lets you zoom in a level without anything breaking. If someone sat down with the style sheet, figured out how it worked, and edited it, they could easily fix not only the immediate issue of things breaking so quickly, but they could also make it so the second menu dropped beneath in an attractive way without breaking the site at all. And they could maintain that level of compatibility across all browsers.
Melgross, save that as a user style sheet (blah.css) and load it in Safari. See how easy it is for the designer of this site to make a few tweaks, thus making all the difference in solving a problem like this? If they were to implement a fix they wouldn't have to be anywhere near as specific in their style sheet as I was here (I did it to make sure this wouldn't interfere with other sites as a user style sheet). They could find ways to solve problems without conflicting with other browsers (should be easy) and they could do their browser testing -- but this really isn't complicated. It just requires a site designer who actually cares about their product.
Quote:
Originally Posted by aegisdesign
Mel, the reason it takes two font size changes to create a similarly large problem in Firefox is because Firefox renders the font smaller in the first place as they don't use Apple's system wide smoothing and kerning for text.
The only time Safari 3 has ever crashed on me is when my CS3 package got messed up. Whenever I tried to download a PDF Acrobat failed to launch properly and Safari locked up when things didn't pan out. Aside from that, it has been great.
IE's behavior hails back to the days of IE vs. Netscape in which there were no standards. Nobody who remembers the consequences of that could ever hope for it to return. Since then, IE has done very little to support unified features across browsers. In fact, when Netscape died IE development screeched to a crawl and they hardly even bothered to progress with new features. It was only when things got ugly that they got off their behinds again and got to work.
I cannot see how you can call that a standard by any stretch of the word.
Websites were jacked up because people designed only for IE (why bother when they had a 90%+ market share?) and left everything else to its own devices. Microsoft worked hard to make sure all sorts of broken code worked in their browser. The Web Standards Project, and other initiatives, helped to turn this around, and helped to bring alternatives like Firefox into prominence. This is a good thing, and so is change.
And in the world of the internet, you've never been able to please everyone.
Decisions like this are made all the time. A web author, for example, can have browsers clean up after their mistakes by leaving out a doctype. That places browsers in quirks mode, slows them down, and prompts them to look for mistakes that need to be cleaned up. When a designer includes a doctype it tells the browser how strict it should be with rendering, speeding it up in the process. That doesn't apply directly to this problem as it is more a matter of poor code (on that note I checked Macworld's code, and it is indeed poor) but it is representative of the efforts these people try to make.
Back to the discussion at hand, there is no browser which zooms in this way which does it elegantly of pages designed to fit in static confines. Some pages fail more gracefully in one browser than the other (anyone remember what used to happen at Roughly Drafted when you zoomed in using Firefox?) but it is tough to say which browser fails on more. It is something that could be considered. I think the only reasonable expectation we could make of the engineers behind our beloved Apple browser is that they continue looking for ways to make their zooming technology a little more graceful across the board.
But under no circumstance does this forgive a page designer for producing bad code.
I should have specified. I was outlining the software engineers' choices.
If we're to entertain a valid discussion about this we have to identify a failure which Safari is making consistently across pages that Firefox, for example, is not. The way in which Macworld fails is not going to be of much use to us as it is the result of bad design. And there's no sense in asking the Safari engineers to 'do it like Firefox does'.
Are you really noticing more problems in Safari than Firefox?
I just went to a bunch of sites I know well -- including many which I know a lot about -- and the failures were pretty consistent across both browsers. The only times I see major failures tend to be in cases where there is a glaring mistake or oversight in the site design or code.
Do you know a little bit about CSS2? Or floats? You could jot a note in your user style sheet to fix it up pretty darn fast. Unfortunately that's about all we could hope to do short of getting them off their behinds.
Again, I'm not disagreeing with what you say should be done, you are definitely correct, and you do agree with me about IE, though you don't realize it. You made my point.
Unfortunately, what do end users do? They (we) have little, or no control, over these problems.
I used to design web pages at my company, but not for the past three years, or so, since we sold it, and I've retired. I'm familiar with most of the coding, but am not up to snuff, so to speak. I don't really want to get back into the trenches. When I did my own work, I would have agreed that the designers should all do it correctly, all of the time, and not act in a hurried, or lazy manner, but I have always seen that that isn't and won't ever be, true for too many.
There is pressure on these people, just in every business. Deadline loom, and the code must be finished, so shortcuts are taken. Clumsy as it may have been, IE was good at reading sites with problems.
Mel, the reason it takes two font size changes to create a similarly large problem in Firefox is because Firefox renders the font smaller in the first place as they don't use Apple's system wide smoothing and kerning for text. They also substitute the wrong font when the real font is available and don't pick up on font hints. It's one of the things that drives me potty with Firefox and why I won't touch the thing professionally until testing rounds. At that point I may find Firefox renders things subtly differently to Safari but that's their loss. IE on the other hand can still be a major pain in the arse and I'll fix for that, but rarely do I try to match Firefox up exactly, pixel for pixel with Safari.
Perhaps, but the font sizes are the same and I'm seeing, right now, that Safari has already started to overlap, and Firefox hasn't. If I move up one more size, Safari is almost unreadable, and Firefox has just started to overlap on the box.
I admittedly don't pay attention to whether the proper font is being used, because as long as it works, I don't care much. I'm willing to believe that most others would agree.
Ars used to have the same problem with columns for the articles, but with the site re-design, it's been fixed.
My whole point is the question of why users should have to be concerned about this?
Someone should look at the problem and try to solve it at the local level, that is at the one point where many problems can be solved at once, and that place is the browser.
I know the arguments against it, they won't go away, and in a perfect world, everyone would do the correct thing.
But, Xian made a suggestion to me that I should write my own code to solve a problem that I shouldn't see in the first place. It's no solution to tell a user to write their own code to solve these problems.
This remindes me of a problem I had years ago with Powerpoint, I don't remember the version offhand.
MS put out the upgrade, which most everyone quickly went to. The problem with it, as it turned out, was that it screwed imagesetters and film recorders, both of which we had. I thought it might only be my machines. When I called MS, I found that it affected everyone!
MS's response was that the manufacturers would have to re-write their drivers. That would be dozens, if not hundreds of machines. Impossible!
We all went back to the older versions until they finally decided to fix it.
But, Xian made a suggestion to me that I should write my own code to solve a problem that I shouldn't see in the first place. It's no solution to tell a user to write their own code to solve these problems.
There are too many variables for them to control rendering on this level. I suppose it simply comes down to the two of us disagreeing about how web browser development should be conducted. It sounds like you support the old method of browsers taking extra time and facing extra bugs in favor of trying to render around mistakes and oversights of designers and developers, as opposed to the movement (which was in full swing while you were coding) for standards, fast rendering, fewer bugs, and cross-browser compatibility.
Problem here is that this doesn't even really come down to that argument. I don't see how they could program a browser to anticipate a problem like this without creating ten new problems for every problem solved. They would have to instruct CSS to behave in a way it is not meant to behave. And after 'fixing' it above, it really did come down to a matter of pixels. It isn't really that Safari is doings things very differently from Firefox in this case, it is just that they render anti-aliased text differently and, thus, text takes up different amounts of space.
I guess there's no use fussing about it. The engineers behind Webkit would be no more interested in programming around designer mistakes than the folks of Mozilla would be (if you've read their bug reports and responses you know how they handle it). Fortunately, awareness of these problems and expectations are becoming more and more important in browsers today.
(And a deadline is no excuse for this oversight. It would have taken ten minutes to fix during initial development.)
There are too many variables for them to control rendering on this level. I suppose it simply comes down to the two of us disagreeing about how web browser development should be conducted. It sounds like you support the old method of browsers taking extra time and facing extra bugs in favor of trying to render around mistakes and oversights of designers and developers, as opposed to the movement (which was in full swing while you were coding) for standards, fast rendering, fewer bugs, and cross-browser compatibility.
Problem here is that this doesn't even really come down to that argument. I don't see how they could program a browser to anticipate a problem like this without creating ten new problems for every problem solved. They would have to instruct CSS to behave in a way it is not meant to behave. And after 'fixing' it above, it really did come down to a matter of pixels. It isn't really that Safari is doings things very differently from Firefox in this case, it is just that they render anti-aliased text differently and, thus, text takes up different amounts of space.
I guess there's no use fussing about it. The engineers behind Webkit would be no more interested in programming around designer mistakes than the folks of Mozilla would be (if you've read their bug reports and responses you know how they handle it). Fortunately, awareness of these problems and expectations are becoming more and more important in browsers today.
(And a deadline is no excuse for this oversight. It would have taken ten minutes to fix during initial development.)
But, I've said that I agree with you that it should be done properly at the web site level. No argument there.
The problem is that is isn't being taken care of there.
It's like saying that all roads should be perfectly flat and smooth. Since that's the standard, car makers shouldn't make shocks to take care of all those roads that aren't, because it's not up to the car makers to try to fix a problem that rightly should be taken care of by the construction companies making the road. And by doing so, cars are more complex, and will break down more often, as well as cost more.
If Macworld.com just used percentages and ems instead of fixed px sizes, they'd not have a lot of the problems they have, plus adding background images that are big enough to scale when the font increases.
All fairly basic stuff that anyone with a copy of Zeldman would understand. It just looks like they rushed a design based on slicing up a photoshop of how they wanted it.
Speaking of Zeldman, and fonts, here's his complaints with Firefox's font rendering...
Man, I am getting tired of people always blaming Unsanity for matters. Are you an Apple employee?
I'm not blaming Unsanity. When I used it I had no such issues with it, then again, I've never had any Safari issues. But I've seen it cause issues in the past. And as one would expect from the added complexity in the way APE interacts with Safari. It's not hate, just a logical question based on my experience of users asking for assistance over the years.
Safari's autofill and Keychain support is seriously bugged on both my step father and my machines. Sometimes both work, and sometimes they don't.
Take for instance a popular education Site: Blackboard. Safari refuses to remember or even ask if I want to remember the user name and password. Firefox remembers this information no problem.
Some may already have read the news but a new version of Acid, a web standard compliance test, has been released recently and the current Safari version behaves actually a lot worse than the competition (apart from IE). Safari passes 39/100 tests while Firefox and Opera are in the 50-60 range. So, even if writing compliant web sites there's always the risk that Safari will fail to render it properly due to suboptimal standard support.
On the bright side: The latest build of WebKit gets a whooping 90/100 so let's hope it will be integrated soon in one of the Safari releases.
Comments
]You are correct in what you're saying about this. The problem is that the browser should be able to detect these problems, and push the rest of the page down to accommodate them.
This is exactly the sort of problem that slows down browsers with bloat. This is the [well, a] reason why Internet Explorer has been messed up for so long, and why it has so many rendering problems (hopefully to be addressed more in IE8). When the browser has to check for poor design or coding it has to do it routinely while browsing, and all of this adds up. This is why most modern browser developers refuse to do much of this at all (be it Webkit or Mozilla).
There's another snag to worry about here... if Safari corrected this they would be causing CSS to behave in a nonstandard way. It may work great at Macworld but on other sites would certainly lead to unexpected behavior which would, in turn, be reported as browser bugs (and rightfully so). If you set a float element as relative and it becomes too big it is supposed to kick down to the line below. If there's an item there with a static location, the two overlap. I'm not sure how the engineers could program around that without causing other problems.
It is too bad Macworld ignores the issue. Maybe if more people wrote them?
]The bigger problem in my mind is the column with error in Safari, which seems to not addressed by most people here. Fonts are something that can be resolved by changing sizes, but nothing can be done about the hidden right side of the column. That's much more serious, as information is hidden, and can't be retrieved.
CSS gives the author complete control over these things -- and the ability to mess them up, too. Some of these problems are hot discussion topics among web designers, but the problem is these things aren't really discussed in college. Web design is more than knowing code and cross-platform compatibility, but companies either don't realize this, or aren't willing to pay the right fees to retain a true professional.
What's sad is that it shouldn't take more than an hour to fix a problem like this, depending on familiarity with and quality of the style sheets that already exist. If they've got someone working in-house -- which they probably do -- they should be able to address this without much trouble.
One thing many sites do when there are menu elements which would break if resized is offer in-page resizing capabilities (ala wired.com and others). This gives the site author control over how resizing works and what is actually resized, thus allowing large font sizes to be displayed without breaking anything. This would require much more dedicated work, though, and possibly a site redesign if Macworld is depending on old code or HTML for too much presentation.
This is exactly the sort of problem that slows down browsers with bloat. This is the reason why Internet Explorer has been messed up for so long, and why it has so many rendering problems (hopefully to be addressed more in IE8). When the browser has to check for poor design or coding it has to do it routinely while browsing, and all of this adds up. This is why most modern browser developers refuse to do much of this at all (be it Webkit or Mozilla).
There's another snag to worry about here... if Safari corrected this they would be causing CSS to behave in a nonstandard way. It may work great at Macworld but on other sites would certainly lead to unexpected behavior which would, in turn, be reported as browser bugs (and rightfully so). If you set a float element as relative and it becomes too big it is supposed to kick down to the line below. If there's an item there with a static location, the two overlap. I'm not sure how the engineers could program around that without causing other problems.
It is too bad Macworld ignores the issue. Maybe if more people wrote them?
The difficulty here is that many web developers will NEVER bother to correct these problems. If Macworld can't check to see if Safari is having a problem, then who else will bother?
Because of this, I, as a user, don't give the traditional rats' ass how much trouble it is for the browser programmers. I want to have a good experience, and damn the work. That's what they're paid for.
The problem with standards is that if everyone doesn't adhere to them, they aren't standard.
If Firefox gets around most of these problems, then Apple's product should be able to as well. Many times Apple modifies their OS to work with certain programs, they can certainly take a look at these problems, and fix them. We know it can be done.
CSS gives the author complete control over these things -- and the ability to mess them up, too. Some of these problems are hot discussion topics among web designers, but the problem is these things aren't really discussed in college. Web design is more than knowing code and cross-platform compatibility, but companies either don't realize this, or aren't willing to pay the right fees to retain a true professional.
What's sad is that it shouldn't take more than an hour to fix a problem like this, depending on familiarity with and quality of the style sheets that already exist. If they've got someone working in-house -- which they probably do -- they should be able to address this without much trouble.
One thing many sites do when there are menu elements which would break if resized is offer in-page resizing capabilities (ala wired.com and others). This gives the site author control over how resizing works and what is actually resized, thus allowing large font sizes to be displayed without breaking anything. This would require much more dedicated work, though, and possibly a site redesign if Macworld is depending on old code or HTML for too much presentation.
I won't argue this, but as I said, firefox handles it without a problem, so there's no reason why Safari couldn't.
It's far better for the user to expect that their one program can render the thousands of sites they visit, properly, than to expect those thousands of sites to fix their problems.
The difficulty here is that many web developers will NEVER bother to correct these problems. If Macworld can't check to see if Safari is having a problem, then who else will bother?
Sadly, many sites which don't even deploy for an OS X userbase do a much better job. Macworld's poor approach to this matter should not be considered representative of the whole.
Because of this, I, as a user, don't give the traditional rats' ass how much trouble it is for the browser programmers. I want to have a good experience, and damn the work. That's what they're paid for.
It has nothing to do with how much work they put in. It has to do with quality of product. You, the user, do care about how fast your browser is, and you will care when patchwork breaks another of your favorite sites.
The problem with standards is that if everyone doesn't adhere to them, they aren't standard.
1) You're talking about two different meanings of the word here. A standard is presented and people may choose to adhere to it, but simply because one group choses to ignore it (frequently Microsoft), that doesn't mean it isn't a standard.
2) You can ask all you want for people to do this sort of thing, but unless you are willing to educate yourself in the mechanics behind what is happening here -- and admittedly, it takes more than an evening of study to understand CSS2 -- you're not going to be in a good position to dictate terms to experienced engineers. This is like telling Apple to patch OS X to expect certain major bugs because a software developer can't be bothered to update their software. It just doesn't work that way.
I want Macworld to work great too. It doesn't, though, and it is because they can't be bothered to put some small effort into correcting their site. That content has to go somewhere, though, and the choices are:
1) Don't resize the text.
2) Overlap horizontally (good luck).
3) Overlap based on standards (what is happening here).
4) Override style sheet instructions and move static elements (bad idea).
5) Let people mess up their own web pages (also something that is happening here).
If Firefox gets around most of these problems, then Apple's product should be able to as well. Many times Apple modifies their OS to work with certain programs, they can certainly take a look at these problems, and fix them. We know it can be done.
Firefox doesn't come out much better, looking at it now. It survives the first font size increase but things get ugly after two. The spacing is inconsistent and it is tough to identify the source of a problem like that. The code would have to be studied. At least the overlap isn't anywhere near as bad.
What it boils down to, though, is that you are asking the webkit developers to address an obscure issue which relies primarily on the site designer(s). If this particular problem was widespread they should indeed consider their approach, but if it is not we should not expect much from them.
If this really bothers you and you must have your font size increased at Macworld you might consider getting members here to write them or starting a petition. Or, everyone bothered by this can start going to that page, duplicating the problem, and clicking on the bug report button in Safari to send a screenshot and description to the developers behind Webkit/Safari. If they identify a solution relative to their own code which does not require breaking standards they'll likely fix it up. But they're probably not going to give it much thought if it isn't reported to them. I'll submit my report to them now to do my part.
It's far better for the user to expect that their one program can render the thousands of sites they visit, properly, than to expect those thousands of sites to fix their problems.
Are there thousands of sites breaking like this in Safari when font sizes are increased but not breaking in other browsers? That is the question to ask here. There are thousands of sites out there breaking when font sizes are increased but this is due to the difficulties of designing a complicated commercial site with support for universal font size increases. The only sure-fire solution to this is page zooming (as done on the iPhone and in Opera).
Sadly, many sites which don't even deploy for an OS X userbase do a much better job. Macworld's poor approach to this matter should not be considered representative of the whole.
Unfortunately, Macworld is far from being the only offender. If it were, I wouldn't even bother to mention it.
It has nothing to do with how much work they put in. It has to do with quality of product. You, the user, do care about how fast your browser is, and you will care when patchwork breaks another of your favorite sites.
We've all had our quality of product woes over the years with Safari. It seems stable now, but it isn't the only stable browser out there.
1) You're talking about two different meanings of the word here. A standard is presented and people may choose to adhere to it, but simply because one group choses to ignore it (frequently Microsoft), that doesn't mean it isn't a standard.
2) You can ask all you want for people to do this sort of thing, but unless you are willing to educate yourself in the mechanics behind what is happening here -- and admittedly, it takes more than an evening of study to understand CSS2 -- you're not going to be in a good position to dictate terms to experienced engineers. This is like telling Apple to patch OS X to expect certain major bugs because a software developer can't be bothered to update their software. It just doesn't work that way.
I understand two things.
1 What a "standard" is. But, you have to understand that if a standard isn't being applied across most systems, it isn't really a standard. It doesn't matter how many bodies give their approval. Like it or not, IE's "standards" have been the web's standards as well, as most sites hewed to them. When something is not defined as a standard, but is used as such, then it is the defacto standard, like it or not.
2 I understand what is happening here. That doesn't mean that I either like it, or agree with it.
Sometimes, in the course of events, decisions must be made that lead to a non "pure" system, because of factors that are beyond your control. This is one of those cases. It rarely pays to be alone, wandering in the dark, simply because you think you are right, as Apple often does.
I want Macworld to work great too. It doesn't, though, and it is because they can't be bothered to put some small effort into correcting their site. That content has to go somewhere, though, and the choices are:
1) Don't resize the text.
2) Overlap horizontally (good luck).
3) Overlap based on standards (what is happening here).
4) Override style sheet instructions and move static elements (bad idea).
5) Let people mess up their own web pages (also something that is happening here).
Unfortunately, some of that only works for some elements, and others aren't under our control at all.
Firefox doesn't come out much better, looking at it now. It survives the first font size increase but things get ugly after two. The spacing is inconsistent and it is tough to identify the source of a problem like that. The code would have to be studied. At least the overlap isn't anywhere near as bad.
Yes, you have go to more extreme settings before the problem sets in. That means that it rarely does set in.
What it boils down to, though, is that you are asking the webkit developers to address an obscure issue which relies primarily on the site designer(s). If this particular problem was widespread they should indeed consider their approach, but if it is not we should not expect much from them.
If this really bothers you and you must have your font size increased at Macworld you might consider getting members here to write them or starting a petition. Or, everyone bothered by this can start going to that page, duplicating the problem, and clicking on the bug report button in Safari to send a screenshot and description to the developers behind Webkit/Safari. If they identify a solution relative to their own code which does not require breaking standards they'll likely fix it up. But they're probably not going to give it much thought if it isn't reported to them. I'll submit my report to them now to do my part.
Are there thousands of sites breaking like this in Safari when font sizes are increased but not breaking in other browsers? That is the question to ask here. There are thousands of sites out there breaking when font sizes are increased but this is due to the difficulties of designing a complicated commercial site with support for universal font size increases. The only sure-fire solution to this is page zooming (as done on the iPhone and in Opera).
It's a widespread issue. Not every site has the problem, but many do. As I said, if it were only Macworld, I would only bother them.
But, as I also said, that's an annoyance, but not a major problem. It's the problem with the columns that constitutes the real problem, as nothing I have ever done has been able to correct it, other than to go to Firefox.
I mean how many more years is going to take for a History and Downloads window that are actually useful, can catch up to IE from oh say almost a DECADE ago. It's, well, embarrassing. Safari is the application I use or used to use the most. This is probably true for a lot of other people. I feel like Apple is devoting a lot less people to it than they could or probably should. When it came out it was like hey the Bookmarks library is awesome! But the crashing, slow performance, bugs, and incompatibility continue to be present and in fact have become much worse in 3. I hear 3.1 has a ton of improvements in these areas and I actually have high hopes for 3.1, and I hope I can replace Firefox with Safari once again in my Dock.
I have to agree with everyone else: Safari 3 is much worse than Safari 2 in terms of stability.
I feel bad for everyone's stability issues. I use the Safari betas and WebKit nightly builds and rarely have a crash.
Are you all using Unsanity and other such things with Safari?
1 What a "standard" is. But, you have to understand that if a standard isn't being applied across most systems, it isn't really a standard. It doesn't matter how many bodies give their approval. Like it or not, IE's "standards" have been the web's standards as well, as most sites hewed to them. When something is not defined as a standard, but is used as such, then it is the defacto standard, like it or not.
IE's behavior hails back to the days of IE vs. Netscape in which there were no standards. Nobody who remembers the consequences of that could ever hope for it to return. Since then, IE has done very little to support unified features across browsers. In fact, when Netscape died IE development screeched to a crawl and they hardly even bothered to progress with new features. It was only when things got ugly that they got off their behinds again and got to work.
I cannot see how you can call that a standard by any stretch of the word.
Websites were jacked up because people designed only for IE (why bother when they had a 90%+ market share?) and left everything else to its own devices. Microsoft worked hard to make sure all sorts of broken code worked in their browser. The Web Standards Project, and other initiatives, helped to turn this around, and helped to bring alternatives like Firefox into prominence. This is a good thing, and so is change.
And in the world of the internet, you've never been able to please everyone.
Sometimes, in the course of events, decisions must be made that lead to a non "pure" system, because of factors that are beyond your control. This is one of those cases. It rarely pays to be alone, wandering in the dark, simply because you think you are right, as Apple often does.
Decisions like this are made all the time. A web author, for example, can have browsers clean up after their mistakes by leaving out a doctype. That places browsers in quirks mode, slows them down, and prompts them to look for mistakes that need to be cleaned up. When a designer includes a doctype it tells the browser how strict it should be with rendering, speeding it up in the process. That doesn't apply directly to this problem as it is more a matter of poor code (on that note I checked Macworld's code, and it is indeed poor) but it is representative of the efforts these people try to make.
Back to the discussion at hand, there is no browser which zooms in this way which does it elegantly of pages designed to fit in static confines. Some pages fail more gracefully in one browser than the other (anyone remember what used to happen at Roughly Drafted when you zoomed in using Firefox?) but it is tough to say which browser fails on more. It is something that could be considered. I think the only reasonable expectation we could make of the engineers behind our beloved Apple browser is that they continue looking for ways to make their zooming technology a little more graceful across the board.
But under no circumstance does this forgive a page designer for producing bad code.
Unfortunately, some of that only works for some elements, and others aren't under our control at all.
I should have specified. I was outlining the software engineers' choices.
Yes, you have go to more extreme settings before the problem sets in. That means that it rarely does set in.
If we're to entertain a valid discussion about this we have to identify a failure which Safari is making consistently across pages that Firefox, for example, is not. The way in which Macworld fails is not going to be of much use to us as it is the result of bad design. And there's no sense in asking the Safari engineers to 'do it like Firefox does'.
Are you really noticing more problems in Safari than Firefox?
I just went to a bunch of sites I know well -- including many which I know a lot about -- and the failures were pretty consistent across both browsers. The only times I see major failures tend to be in cases where there is a glaring mistake or oversight in the site design or code.
But, as I also said, that's an annoyance, but not a major problem. It's the problem with the columns that constitutes the real problem, as nothing I have ever done has been able to correct it, other than to go to Firefox.
Do you know a little bit about CSS2? Or floats? You could jot a note in your user style sheet to fix it up pretty darn fast. Unfortunately that's about all we could hope to do short of getting them off their behinds.
If this really bothers you and you must have your font size increased at Macworld you might consider getting members here to write them or starting a petition. Or, everyone bothered by this can start going to that page, duplicating the problem, and clicking on the bug report button in Safari to send a screenshot and description to the developers behind Webkit/Safari. If they identify a solution relative to their own code which does not require breaking standards they'll likely fix it up. But they're probably not going to give it much thought if it isn't reported to them. I'll submit my report to them now to do my part.
Or we could just fix the Macworld.com CSS and send them a fixed stylesheet.
I had a brief look though and they're just making a couple of basic assumptions wrong which trickle through and cause problems when font sizes change.
One of the features I've always wanted in Safari is site by site CSS substitution so I can redesign existing sites. You can probably do it with a Firefox plugin but I really can't stand Firefox - it's just not a good OSX citizen.
Mel, the reason it takes two font size changes to create a similarly large problem in Firefox is because Firefox renders the font smaller in the first place as they don't use Apple's system wide smoothing and kerning for text. They also substitute the wrong font when the real font is available and don't pick up on font hints. It's one of the things that drives me potty with Firefox and why I won't touch the thing professionally until testing rounds. At that point I may find Firefox renders things subtly differently to Safari but that's their loss. IE on the other hand can still be a major pain in the arse and I'll fix for that, but rarely do I try to match Firefox up exactly, pixel for pixel with Safari.
Or we could just fix the Macworld.com CSS and send them a fixed stylesheet.
That's an option.
I messed around with it for a moment. A better solution could be devised to solve the red bleed-down under the black-background links (rather than overflow) and there is probably a better solution for the descriptive paragraph up there near the top than to give it a fixed width, but this is a start at least:
(It would really be easy for someone familiar with their style sheet.
I didn't even look at it -- I just applied some patches.)
#wrapper #navigation #linkContainer #contentLinks ul li {
padding-right: 0 !important;
height: 33px !important;
}
#wrapper #navigation #linkContainer #contentLinks ul li.search {
padding-left: 3px !important;
padding-top: 5px !important;
}
#wrapper #navigation #linkContainer #contentLinks #productLinks {
overflow: hidden;
}
#wrapper #navigation #linkContainer #hotTopics {
font-size: .9em !important;
}
#wrapper #navigation #printLogo + p {
width: 140px !important;
}
This lets you zoom in a level without anything breaking. If someone sat down with the style sheet, figured out how it worked, and edited it, they could easily fix not only the immediate issue of things breaking so quickly, but they could also make it so the second menu dropped beneath in an attractive way without breaking the site at all. And they could maintain that level of compatibility across all browsers.
Melgross, save that as a user style sheet (blah.css) and load it in Safari. See how easy it is for the designer of this site to make a few tweaks, thus making all the difference in solving a problem like this? If they were to implement a fix they wouldn't have to be anywhere near as specific in their style sheet as I was here (I did it to make sure this wouldn't interfere with other sites as a user style sheet). They could find ways to solve problems without conflicting with other browsers (should be easy) and they could do their browser testing -- but this really isn't complicated. It just requires a site designer who actually cares about their product.
Mel, the reason it takes two font size changes to create a similarly large problem in Firefox is because Firefox renders the font smaller in the first place as they don't use Apple's system wide smoothing and kerning for text.
I think you pegged it on the head here.
Are you all using Unsanity and other such things with Safari?
No, but I've been accused of it.
The only time Safari 3 has ever crashed on me is when my CS3 package got messed up. Whenever I tried to download a PDF Acrobat failed to launch properly and Safari locked up when things didn't pan out. Aside from that, it has been great.
IE's behavior hails back to the days of IE vs. Netscape in which there were no standards. Nobody who remembers the consequences of that could ever hope for it to return. Since then, IE has done very little to support unified features across browsers. In fact, when Netscape died IE development screeched to a crawl and they hardly even bothered to progress with new features. It was only when things got ugly that they got off their behinds again and got to work.
I cannot see how you can call that a standard by any stretch of the word.
Websites were jacked up because people designed only for IE (why bother when they had a 90%+ market share?) and left everything else to its own devices. Microsoft worked hard to make sure all sorts of broken code worked in their browser. The Web Standards Project, and other initiatives, helped to turn this around, and helped to bring alternatives like Firefox into prominence. This is a good thing, and so is change.
And in the world of the internet, you've never been able to please everyone.
Decisions like this are made all the time. A web author, for example, can have browsers clean up after their mistakes by leaving out a doctype. That places browsers in quirks mode, slows them down, and prompts them to look for mistakes that need to be cleaned up. When a designer includes a doctype it tells the browser how strict it should be with rendering, speeding it up in the process. That doesn't apply directly to this problem as it is more a matter of poor code (on that note I checked Macworld's code, and it is indeed poor) but it is representative of the efforts these people try to make.
Back to the discussion at hand, there is no browser which zooms in this way which does it elegantly of pages designed to fit in static confines. Some pages fail more gracefully in one browser than the other (anyone remember what used to happen at Roughly Drafted when you zoomed in using Firefox?) but it is tough to say which browser fails on more. It is something that could be considered. I think the only reasonable expectation we could make of the engineers behind our beloved Apple browser is that they continue looking for ways to make their zooming technology a little more graceful across the board.
But under no circumstance does this forgive a page designer for producing bad code.
I should have specified. I was outlining the software engineers' choices.
If we're to entertain a valid discussion about this we have to identify a failure which Safari is making consistently across pages that Firefox, for example, is not. The way in which Macworld fails is not going to be of much use to us as it is the result of bad design. And there's no sense in asking the Safari engineers to 'do it like Firefox does'.
Are you really noticing more problems in Safari than Firefox?
I just went to a bunch of sites I know well -- including many which I know a lot about -- and the failures were pretty consistent across both browsers. The only times I see major failures tend to be in cases where there is a glaring mistake or oversight in the site design or code.
Do you know a little bit about CSS2? Or floats? You could jot a note in your user style sheet to fix it up pretty darn fast. Unfortunately that's about all we could hope to do short of getting them off their behinds.
Again, I'm not disagreeing with what you say should be done, you are definitely correct, and you do agree with me about IE, though you don't realize it. You made my point.
Unfortunately, what do end users do? They (we) have little, or no control, over these problems.
I used to design web pages at my company, but not for the past three years, or so, since we sold it, and I've retired. I'm familiar with most of the coding, but am not up to snuff, so to speak. I don't really want to get back into the trenches. When I did my own work, I would have agreed that the designers should all do it correctly, all of the time, and not act in a hurried, or lazy manner, but I have always seen that that isn't and won't ever be, true for too many.
There is pressure on these people, just in every business. Deadline loom, and the code must be finished, so shortcuts are taken. Clumsy as it may have been, IE was good at reading sites with problems.
O
Mel, the reason it takes two font size changes to create a similarly large problem in Firefox is because Firefox renders the font smaller in the first place as they don't use Apple's system wide smoothing and kerning for text. They also substitute the wrong font when the real font is available and don't pick up on font hints. It's one of the things that drives me potty with Firefox and why I won't touch the thing professionally until testing rounds. At that point I may find Firefox renders things subtly differently to Safari but that's their loss. IE on the other hand can still be a major pain in the arse and I'll fix for that, but rarely do I try to match Firefox up exactly, pixel for pixel with Safari.
Perhaps, but the font sizes are the same and I'm seeing, right now, that Safari has already started to overlap, and Firefox hasn't. If I move up one more size, Safari is almost unreadable, and Firefox has just started to overlap on the box.
I admittedly don't pay attention to whether the proper font is being used, because as long as it works, I don't care much. I'm willing to believe that most others would agree.
Ars used to have the same problem with columns for the articles, but with the site re-design, it's been fixed.
My whole point is the question of why users should have to be concerned about this?
Someone should look at the problem and try to solve it at the local level, that is at the one point where many problems can be solved at once, and that place is the browser.
I know the arguments against it, they won't go away, and in a perfect world, everyone would do the correct thing.
But, Xian made a suggestion to me that I should write my own code to solve a problem that I shouldn't see in the first place. It's no solution to tell a user to write their own code to solve these problems.
This remindes me of a problem I had years ago with Powerpoint, I don't remember the version offhand.
MS put out the upgrade, which most everyone quickly went to. The problem with it, as it turned out, was that it screwed imagesetters and film recorders, both of which we had. I thought it might only be my machines. When I called MS, I found that it affected everyone!
MS's response was that the manufacturers would have to re-write their drivers. That would be dozens, if not hundreds of machines. Impossible!
We all went back to the older versions until they finally decided to fix it.
Unfortunately, we can't do that here.
But, Xian made a suggestion to me that I should write my own code to solve a problem that I shouldn't see in the first place. It's no solution to tell a user to write their own code to solve these problems.
There are too many variables for them to control rendering on this level. I suppose it simply comes down to the two of us disagreeing about how web browser development should be conducted. It sounds like you support the old method of browsers taking extra time and facing extra bugs in favor of trying to render around mistakes and oversights of designers and developers, as opposed to the movement (which was in full swing while you were coding) for standards, fast rendering, fewer bugs, and cross-browser compatibility.
Problem here is that this doesn't even really come down to that argument. I don't see how they could program a browser to anticipate a problem like this without creating ten new problems for every problem solved. They would have to instruct CSS to behave in a way it is not meant to behave. And after 'fixing' it above, it really did come down to a matter of pixels. It isn't really that Safari is doings things very differently from Firefox in this case, it is just that they render anti-aliased text differently and, thus, text takes up different amounts of space.
I guess there's no use fussing about it. The engineers behind Webkit would be no more interested in programming around designer mistakes than the folks of Mozilla would be (if you've read their bug reports and responses you know how they handle it). Fortunately, awareness of these problems and expectations are becoming more and more important in browsers today.
(And a deadline is no excuse for this oversight. It would have taken ten minutes to fix during initial development.)
There are too many variables for them to control rendering on this level. I suppose it simply comes down to the two of us disagreeing about how web browser development should be conducted. It sounds like you support the old method of browsers taking extra time and facing extra bugs in favor of trying to render around mistakes and oversights of designers and developers, as opposed to the movement (which was in full swing while you were coding) for standards, fast rendering, fewer bugs, and cross-browser compatibility.
Problem here is that this doesn't even really come down to that argument. I don't see how they could program a browser to anticipate a problem like this without creating ten new problems for every problem solved. They would have to instruct CSS to behave in a way it is not meant to behave. And after 'fixing' it above, it really did come down to a matter of pixels. It isn't really that Safari is doings things very differently from Firefox in this case, it is just that they render anti-aliased text differently and, thus, text takes up different amounts of space.
I guess there's no use fussing about it. The engineers behind Webkit would be no more interested in programming around designer mistakes than the folks of Mozilla would be (if you've read their bug reports and responses you know how they handle it). Fortunately, awareness of these problems and expectations are becoming more and more important in browsers today.
(And a deadline is no excuse for this oversight. It would have taken ten minutes to fix during initial development.)
But, I've said that I agree with you that it should be done properly at the web site level. No argument there.
The problem is that is isn't being taken care of there.
It's like saying that all roads should be perfectly flat and smooth. Since that's the standard, car makers shouldn't make shocks to take care of all those roads that aren't, because it's not up to the car makers to try to fix a problem that rightly should be taken care of by the construction companies making the road. And by doing so, cars are more complex, and will break down more often, as well as cost more.
That's all true, but cars still need shocks.
All fairly basic stuff that anyone with a copy of Zeldman would understand. It just looks like they rushed a design based on slicing up a photoshop of how they wanted it.
Speaking of Zeldman, and fonts, here's his complaints with Firefox's font rendering...
http://www.zeldman.com/2006/11/27/safari-beats-firefox/
Are you all using Unsanity and other such things with Safari?
Nope, plain vanilla 10.5.2, just installed it in fact. It was also unstable (perhaps even more so) in 10.4.11, again, plain vanilla.
I feel bad for everyone's stability issues. I use the Safari betas and WebKit nightly builds and rarely have a crash.
Are you all using Unsanity and other such things with Safari?
Man, I am getting tired of people always blaming Unsanity for matters. Are you an Apple employee?
Man, I am getting tired of people always blaming Unsanity for matters. Are you an Apple employee?
I'm not blaming Unsanity. When I used it I had no such issues with it, then again, I've never had any Safari issues. But I've seen it cause issues in the past. And as one would expect from the added complexity in the way APE interacts with Safari. It's not hate, just a logical question based on my experience of users asking for assistance over the years.
Safari's autofill and Keychain support is seriously bugged on both my step father and my machines. Sometimes both work, and sometimes they don't.
Take for instance a popular education Site: Blackboard. Safari refuses to remember or even ask if I want to remember the user name and password. Firefox remembers this information no problem.
See for example http://bugs.webkit.org/show_bug.cgi?id=16027#c10
> security change in Safari 3
Security may be the reason for Keychain support not offering itself in some circumstances.
On the bright side: The latest build of WebKit gets a whooping 90/100 so let's hope it will be integrated soon in one of the Safari releases.
http://www.webstandards.org/action/acid3