That is too bad that this is something you have to implement in Safari. As a web developer, I'd much prefer my browser to be very unforgiving in terms of trying to pass off invalid HTML code. It will help me to correct mistakes and in the long run, it will help to make this problem become almost obsolete. Or am I dreaming?...
Posted by dean at March 18, 2003 12:56 AMI feel with you buddy. But its great that you try to make safari work with shitty HTML since there is so much of it out there.
Posted by Peter G. at March 18, 2003 12:59 AMThis will only be implemented in quirks mode, so in strict mode Safari will not do this.
it would be nice for web developers like myself to be able to turn on strict mode to help us catch mistakes and to be able to turn it off for normal browsing...
(maybe a hidden mode of some sort) just like the debug menu is.
Posted by vinay venkatesh at March 18, 2003 1:01 AMI use several browsers when making web pages. I like to check my code and try to get it XHTML1.1 and CSS2 spec valid. It would be awsome if there were some way to get an info panel saying what the doctype is and how it validates (not going into specifics, but linking to the w3 validator).
Integrating this into Safari would probably be bloat, but there has to be an easier way to check!
On a different note: don't you hate it when the w3 validator is wrong?
Posted by Pokute at March 18, 2003 1:10 AM>it would be nice for web developers like myself to be able >to turn on strict mode to help us catch mistakes and to be >able to turn it off for normal browsing..
"strict mode" is when you specify a complete valid DTD declaration in your HTML/XHTML page.
on the other side, I just find stupid to waste so many time just to read BAD written html.
why do you simply do a MS word reader instead ?? O_o
if the code is so broken (mis-nested tags is just plain faulty ) than the browser can interpret like the stupid webdesigner thinks it's NORMAL and the webdesigners needs to LEARN THE HTML !
imagine if we do the same with C language or Pascal in the old days !!
"Ho yes ; I know, IF need a } end of statement, but you know, some people forget that, so we do tricky very clever long processing method to understand when someone want to end a IF statement....
beAah
nevertheless, KHTML is a very beautiful project.
Posted by Michel at March 18, 2003 1:12 AMseems to me that most people who misnest tags (myself included, admittedly) do so simply because they did it once, and looked in the browser and saw that it looked fine. so they assume they've done it right.
i would guess that most people who know html are self taught. they learn by trial and error. if all browsers were strict about these matters, then we would all learn to do it right.
just my two cents, of course. i understand, hyatt, why you're in the position of having to build safari to work around poorly built websites. i gues i'm just agreeing with you that it sucks.
Posted by sam at March 18, 2003 1:20 AMWe've got a site that's fairly complex, that works lovely in IE and others. It got launched the second it tested fine across the major browsers. Since then getting it to work on Safari has gone to the bottom of the list, despite me being anxious that it becomes perfect. Why? Because the others will put up with the dodgy code. Had IE or Netscape been fault intolerant, the site would have had to have been perfect before it was launched.
(http://www.underwired.com/enjoy/index.php)
I would have been much much happier had that been the case. Corner-cutting in a web design production situation is almost guaranteed by laxity in interpretation. Please please, if you want standards to improve, stick to them Dave.
If you visit (the top level of) our site in Safari you're directed to a vanilla page (which I quite like). I'd much rather our developers had been forced to create something that worked in the first place - "getting away with it" is not an approach that should be encouraged by providing the tools with which to do so.
Meantime, Safari's lovely. Now all I need is someone to have enough time to fix our bugs to meet its (currently fairly stringent) standards!
Um. What about some kind of error report like in iCab?
I really like iCab's error protocol - only problem is it doesn't work with CSS or XHTML ... :-(
The real shame about invalid HTML is this:
Because MS browsers support such errors and they are the vast majority, MS has essentially re-defined what valid HTML is. And poor Dave has got to spend good time and effort keeping up with a bad idea. Ouch.
Posted by Jason Horn at March 18, 2003 5:02 AMWhat I really, *really* want from a browser - and I'm not asking for it in Safari (I'm on Windows and Linux), or any other browser in particular, is an approach similar to Phoenix's pop-up whitelisting - force strict rendering on (be it the specified doctype [if it's valid] or <user-specified, default HTML 4.01> where unspecified or invalid), with quirks mode enabled on a per-site whitelist basis.
A UI notification, add-to-whitelist (eg Phoenix's status bar blob, with pop-up options on a double-click) and temporary toggle would be the icing on the cake.
Hey, I'm still allowed to dream, aren't I?
[Ech. Comments system bad - stripping < and > and contained text, and not giving it back in the preview, is quite evil]
Posted by Nik at March 18, 2003 5:12 AMIsn't all the code needed to handle tag soup what makes the other browsers so bloated? I would prefer that Safari implement the standards correctly and stay lean & mean!
Posted by andrew at March 18, 2003 6:24 AMiCab is slower than Safari and it does not support CCS2. But it is still my browser of choice for web development. Why? Because of the syntax checking icon on the window. I can tell at a glance if the page my PHP code is generating is close to correct HTML. If it is wrong a click on the icon will bring up an error report.
Turns out the pages should still be run through W3C's validators as each checker finds different errors. But the chances are really good that if the HTML passes iCab's checker it will pass W3C's too.
On another topic: The v60 version of Safari seems broken on a number of sites that use frames. The earlier version did not seem to mind. I assume that is a known bug and probably already fixed in the newer internal builds. Am I assuming correctly?
Posted by Tod at March 18, 2003 6:29 AMIf only people knew how to code _properly_, then this wouldn't be an issue.
And while I'm dreaming, I think I'd like a pony...
Posted by superhero at March 18, 2003 7:18 AMMost of the time I work on filesystem code. Imagine if the filesystems in an OS had to deal with invalid directory structures written by code that's not fully compliant ... or if a developer had to discover (the hard way) all the quirks of Microsoft's implementation because what passes for a standard is 8 years old and not very explicit.
Oh wait. They do, and I did. :-)
I feel your pain, Dave. It's a universal problem -- any two pieces of software that need to communicate will experience some issues with the protocol that binds them.
The difficulty is usually proportional to the number of implementations that live on the other side of the protocol from you. For filesystems, that's a handful, maybe a dozen or two at most. For a web browser ... thanks to human-edited code, you have hundreds of thousands of implementations that you need to work with. Not an easy job. The only thing you can do is what you're already doing - deconstruct the behavior one of the comparable impls that nearly everyone tests their code against, like Netscape or IE.
On the bright side, things have to just keep getting better as the bugs get fewer. Right? (Right?)
Posted by drew at March 18, 2003 7:33 AMThis was a huge problem with iCab. They tried to be "correct" but there are so many broken pages out there that won't render correctly with it not because of what iCab is doing wrong but due to errors in the page itself.
It looks like any web browser has to be "bug compatible" with IE and Mozilla.
I remember a huge controversy a few months ago on the Chimera mailing list about whether it should handle clicking a .dmg file as the user would expect, by downloading it, or simply doing the technically correct thing, which is to handle it as text/plain if no MIME type is supplied, which will end up displaying it in the browser.
Posted by Mike Cohen at March 18, 2003 7:56 AMI want a button right next to the bug button.
"Try very hard to send author of this web page an email indicating standards non-compliance."
Lots of different ways to approach this, and I recognize that some of them aren't going to be especially fruitful.... (say postmaster@host.domain is pointed to /dev/null) but I _would_ like something to at least _try_ to nudge people back onto a reasonable path.
Posted by Al Blue at March 18, 2003 8:10 AMAl Blue:
Unfortunately, the only really effective way to nudge people in the right direction is for the browser makers to turn around and say "hey, we're all going to turn strict processing on by default. This will break pages that are badly written. You can turn quirky rendering on, but we don't want you to".
Is Microsoft ever going to do that? Nope. Never. That'd be like admitting they've been wrong to support broken html for the last 8 years, or something.
On top of that, the reduced cost(?) of developing compliant-only renderers wouldn't match the huge support load of users ringing them to bitch about their browser suddenly not working, having ignored the "This page contains invalid HTML and may not be rendered correctly. You can change this by enabling compatibility mode. [ ] Check here if you don't want to see this warning again" message box.
If it weren't for those pesky users (and Microsoft supporting them. Stupid needing-to-earn/not-haemorrage-money), browsing the Intarweb would be a great experience.
Posted by Nik at March 18, 2003 8:36 AMAh, but what about the critical issues, like what happened to the rest of Dave's blog?
Posted by Pick me! Pick me! at March 18, 2003 9:01 AMI'd favor "fixing" the issues Dave discusses very, very slowly if at all. I see pages all the time where the first paragraph is a different font than the rest of the text. It's not that big a deal. The page is certainly not "broken". There will never be any reason to write valid HTML if all the browsers support the quirks. Which is a bad thing, IMO.
Posted by pb at March 18, 2003 9:02 AMaah! thank you for mentioning this! i hadn't had problems on any of my own pages with this - i am pretty anal about my code... but my livejournal.com "friend page" was coming out all bold and thanks to your post i knew to go hunt through how they peice together the code and put some paragraph tags around things.
glad i found your blog :)
one thing i noticed that i am not sure is just my slow computer or safari - when there are multiple animated gifs near each other on the page, it won't animate them all (see my web link). is it just me?
Posted by stephanie at March 18, 2003 9:04 AMDave,
What happened to all your other posts which are non-safari related?
I actually enjoyed reading some of those.
Posted by Jeff Hume at March 18, 2003 9:26 AMI vote (if I had a vote) for strict mode only. Please don't waste time bloating Safari and "enabling" bad html. How else are people ever going to learn? At the very least, do this later, after Safari supports *valid* html and css 1 and 2.
Posted by plw at March 18, 2003 9:33 AMYes, iCab is great with it's error checking capability. I have used it many times when doing web development on Macs. My "vote" is for the browser to stick to the standards. If the web page does not render it's bad code. Plain and simple. No if's and or buts about it. Like others have been saying, if they coded like this in the OS things would be a mess. Maybe ms does do that in windoze? ;)
Another analogy would be what if people drove their cars like red lights did not matter? Opps, bad analogy, people DO do that! :S
Anyways, I "vote" for Safari to be lean and mean and to stick to the code as it is presented. At the same time there should be a colored button on the toolbar the user could click on to see an error report explaining why the web page did not load. Sort of like in iCab.
Dave, save yourself some trouble and forget about cludging the code to accept poor code. If the code is bad the code is bad. No one should be helping "poor coders" by fixing their problems for them.
Posted by Ruairi McFarlane at March 18, 2003 9:36 AMEvery year I get friends who show me a site they made, but can't figure out why it doesn't work in Netscape 4.x. Almost 99% of the time, it was because they forgot to close (or poorly nest) a table tag. That is the one redeaming quality of that browser--it won't forgive sloppy code. Internet Explorer, amongst others, will let anything slide by.
I know you should not let Safari just fall apart when dealing with "Tag Soup", but maybe there is some sort of compromise to make. Try to display the page with the least amount of effort, but then have a status bar disclaimer like the one Nik mentioned. Spending too much development effort on trying to render poorly-coded pages would just make KHTML more bloated, take time away from other bug-fixes, and defeat the purpose of having true standards-based browsers.
Plus, having a 'suptle' disclaimer on a bad page would help coders learn from their mistakes and allow businesses to know if they hired an unskilled coder. Just be careful with what conditions set off that message.
Posted by Noah at March 18, 2003 9:39 AMWhen is the new safari going to be released.. Or is the answer it's ready when it's ready.. thanks
Posted by mblind at March 18, 2003 10:00 AM"If the web page does not render it's bad code. Plain and simple. No if's and or buts about it."
Unfortunately, that's not the case. Practically no one puts
around each text block. What are you going to do, not show it?What I was suggesting is that in examples like Dave's where enforcing validity doesn't damage rendering much, stay with stricter mode. Whether something is bold or not or is 12 point instead of 10 point is not a big deal.
Posted by pb at March 18, 2003 11:17 AMDave,
Before you and others in Safari team go implementing workarounds for "tag soup" issue, have you completed proper rendering of standards compliant codes?
I say make standards code rendering perfect first before moving on to taking care of the "tag soup."
Posted by Jin at March 18, 2003 11:28 AMSafari (and Mozilla) are taking the right approach: a "strict" mode that requires the markup to conform to the DTD declaration at the beginning of the document, and a "loose" mode that allows it to work with the 95% of the other web pages out there.
As David said in his post, if you want to work in the real world, you have to work with pages that were developed by idiots who only validate with IE. Otherwise people stop using your browser very quickly.
I *do* really love the iCab approach, with a highly visible indicator that lets the viewer know that a web site is using invalid markup. The best way to make web site developers write valid HTML is to make it easy and obvious to their viewers when it's not.
Posted by Michael Alderete at March 18, 2003 11:30 AMThat isn't really an option. From a user's perspective, sites that serve up tag soup but that render badly in Safari are "broken." Like it or not, that's how it's viewed, and we have tons of bugs on this issue.
Our priority with Safari is to work with as many Web sites as possible, and if that means bending over backwards to support invalid HTML so be it.
You can take the purist standpoint if you want to, but in the end, it simply isn't practical to avoid this issue. That's why Mozilla went and implemented solutions to the Residual Style problem. That's why Opera did as well. It's not something you can avoid.
I think people are underestimating just how many real-world sites are affected by this problem.
"It's a shame that so much time has to be spent dealing with invalid HTML, but if you want to work with the real-world Web, you don't have much choice."
This is a slippery slope. Trying to emulate the bad behaviour of IE bug-for-bug is what causes small, fast, standards-compliant browsers to become big and slow. Eventually you end up with a steaming pile of exceptions to the spec to handle badly formed HTML. We must hold web publishers (and bad web tool builders) to blame for creating bad HTML. There just is no excuse for not running your HTML through a verifier before publishing it.
I noticed the improper font tag nesting problem on numerous news related sites. They tend to override my font preferences with <font size="-1">, but because the tag is improperly nested, only the first paragraph appears in the diminished font size. Since I select my default font face and size for my own reading comfort, I would actually prefer that this "bug" remain unfixed. I would prefer to squint only at the first paragraph, and read the rest of the story comfortably, than to be forced to "Make Text Bigger", manually overriding some publisher's override of my preferences.
Posted by Brett Johnson at March 18, 2003 11:37 AMIt's an interesting question in terms of resource allocation. Should Dave concentrate on getting the most websites looking OK, or concentrate on getting the most valid websites looking great? Safari is clearly an app for everyone--most of whom don't give a rat's patoot about valid HTML.
That said, I'd like to see my own page rendered correctly in Safari, and it has pretty valid HTML.
Posted by Adam Rice at March 18, 2003 12:16 PMI think this is related to a bug I posted for Safari @ http://www.avannaproductions.com/safaribug.html
Where links bleed off into other regions of a web page if you do not close the P tag.
That's absurd! If some monkey wants to make a page with badly written tags, the browser should pop up a warning to say "This page was made by monkeys" and proceed to erase their hard drive! That'll teach people to write lame code... Why do people like you have to work late hours to deal with the laziness of others?
Like others have been saying, standards exist for a reason. THIS is how you code HTML. If you don't do it THIS way, then it's bad code and it won't work.
Hey, maybe I'll open up Apple Developer Tools and start writing an application with code that starts:
function onOpen (){
do whatever I want
}
I wonder if someone will develop a utility to deal with that?
Posted by Richard at March 18, 2003 12:55 PMDave,
I guess the reason I want Safari to have an icon indicating if the syntax is okay is because I want to use Safari in my web development tool chain. Only if the tools make checking a page quick, easy and automatic will standards compliance be achieved.
I strongly suspect that you are not using tools that make checking easy and automatic. The reason I say that?
iCab lists a bunch of errors on your blog page at http://www.mozillazine.org/weblogs/hyatt/archives/2003_03.htm, starting with
Error (43/1): The character '&' must be written as '&'.
Error (45/1): The tag is not part of "HTML 4.0 Strict".
And, out of curiosity I tried running the HTML validator at http://validator.w3.org/ on it as well. That validator threw up its hands and said it could not figure out how to check the page.
Posted by Tod at March 18, 2003 1:18 PMTo stephanie: It's not just you. I submitted a bug report about multiple animated GIFs a loooong time ago, hopefully it will be fixed soon... right? :( P.S. Still using v60 here.
Posted by LK at March 18, 2003 1:53 PMHmm, maybe a indicator that shows a green check (or something) if the Web Core didn't have to "auto correct" the page. Tell people that sites that get Green Check Indicator(TM) are better -- faster -- than non green checked sites.
Posted by Charles Gaudette at March 18, 2003 2:03 PMSomething like iCab's smiley is what is needed, only bolder. Unlike some, I don't necessarily want Safari to be my HTML debugger. What I'd like is a PROMINENT indicator that lights up when Safari has to enter tag-soup recovery mode, and which when clicked says something like "This Web Page does not follow the HTML standards. Safari has attempted to infer the intended result and render the page accordingly, but the results are not guaranteed to be what the page author intended owing to the HTML errors."
Posted by Michael at March 18, 2003 2:10 PMAs for a subtle reminder that the HTML is bad: I think that this could be like the "secure" page reminder in the top right corner of the Safari browser window. There could be a check-plus mark if it's good code, a check if it's okay code, and a check-minus if the code is just flub.
If you really wanted to get on this one, clicking on the checkmark would bring up an iCab style error log (somehow tied into the W3C validator?). That way it's out of the way for the average schmoe, but very powerful and useful for the people who want to use Safari for so much more.
JB
Posted by JB at March 18, 2003 2:33 PMi think supporting the soupy sites but naming and shaming them at the same time is the best way to go. green tick/red cross next to the site name in the menu bar would be a very quick and easy way of indicating compliance mode, eyes would be drawn to it. make it clickable with "this (tick/cross) means that... with a preference for turning it off would give the impression that apple and safari is doing its level best to compensate, but the fact of the matter is that the site is just plain shoddy :-)
Posted by lee underwood at March 18, 2003 2:53 PM99% of web surfers would do nothing with some sort of feature that displays validity.
I hope the Safari team will at least prioritize tag soup issues that are common and really bad much higher than those that are cosmetic and rare. Slowly but surely web pages will move towards validity.
Posted by pb at March 18, 2003 5:00 PMThat's the plan. At the moment I'm focusing on misnesting problems that send Safari into infinite loops or hangs.
I'm frankly amused at how many people have commented saying "Screw invalid Web sites." That's just an inane position to take when 90%+ of Web sites are invalid in some way.
My take is that Dave, I'd love to see more of your valuable time going towards moving Safari up the rankings in terms of strict CSS compliance as observed here: http://www.xs4all.nl/~ppk/css2tests/
HTML as badly written as the example you gave isn't worth the effort, and if Safari doesn't render some kludgy page perfectly, I'm happy to open up IE for such a rare occasion.
Odds are that anyone who has taken so little pride in their web design work probably doesn't have much of any interest to say anyway!
Posted by Leden at March 18, 2003 9:01 PMHonestly, I can't understand why you have waste valuable time trying to deal with workarounds for such poor HTML. I mean... This is REALLY basic stuff... I guess I don't represent the majority maybe? It would seem that at least SOME level of decent HTML code should be required, instead of making browsers so forgiving...
Posted by Mr. X at March 18, 2003 9:27 PMPlease note that there is a difference between writing "valid" code and writing "well-formed" HTML code. 99% of all web sites out there would NOT pass the W3C's validator. As an example, run Apple's web site through the validator and you'll see all kinds of error messages.
My sense is that ever since the days of oh... Netscape 2.0, we web designers/developers were never really encouraged to adhere to the standards. It was all about, hey! check out my blinking text... or my background color... none of that stuff was valid and in general, we didn't care. And so in some ways, we may be a bit guilty of [indirectly] propegating the problem of "tag soup."
In the mean time, poor Dave and other browser engineers have to deal with this and us web developers need to fix our legacy code and embrace web standards.
Sorry if I'm being too preachy... ;>
Posted by dean at March 18, 2003 10:32 PMNot that my opinion matters much, but I've seen people discussing UI more than backend processing solutions. All I'm going to say is *please* do not dirty/slow down the code that processes things correctly. Hand the bad HTML off to a delegate (or whatever) to be corrected. If you want font attributes or other inline elements to be carried across block attributes, or any other tag fixing you have in mind, pass it off to *that* module to correct by essentially re-tagging the HTML before passing it back to the fast/clean engine.
Posted by The Other Pink at March 18, 2003 11:01 PMI think that some rude dialog box or red "x" about bad HTML would not fly with the average person. They get enough confusing things thrown up at them from the Web. Keep it simple.
I also think that is doesn't matter that 99%, or even 99.9%, of people would ignore a good mark-up indicator. A simple green check (or something) could just sit there and look good, maybe even elegant. Good Web-Masters would be rewarded with a green check, and lazy Web-Masters would know in the back of their minds that their mark-up could be better formed. And maybe one day two CEOs will be sitting on an airplane comparing their corporate sites and one site will have a little green check and the other site wont and it will start the ball rolling in the right direction. As things are now no one outside an HTML purist has any hope of knowing if their mark-up is "in the know" or "in the soup".
That said, I don't think Safari should become a validator of proper HTML -- whatever that is. But rather the absence of a check would simply show if the mark-up had to be taken off the fast track and fixed before presentation.
If it is one of Safari's design goals to halt the slide of sites that only display well in MSIE for Win, then standards are Safari's friend, and Safari should be a friend to standards. Yet, of course, Safari must survive in the present real world of poor mark-up. The little green check would let Safari have its cake and eat it too.
Posted by Charles Gaudette at March 19, 2003 12:19 AMWelcome to the hell that is residual style, Dave. I still dream of thinking up a better way of doing this in Mozilla.... I have failed so far.
Posted by Boris at March 19, 2003 1:02 AMOk. My two cents.
Get the valid stuff out fast. Display what you have got.
If there are errors (that take extra checks to fix) delegate them (there is a tool called tidy-html, I suppose, I don't know if the license is cool enough), and re-render it.
You already do a repositioning algorithm for images (well done). Display the status bar in another color when re-rendering and (optionally) enable bug reporting to the webmaster including the ficed html. (But leave it turned off by default)
This approach would keep the speed (unless pages are really poor). While most pages are broken, not all bugs do slow rendering down. I have not looked into KHTML so I can't judge on how much it can do without breaking its sleek design.
I think that might work and encourage to write proper HTML.
Greetings,
iSee
Why would you, Mr. Hyatt, have to make Safari fault tolerant to other peoples crappy programming? That is stupid and plain wasted effort for and Apple. Why dont you have something instead that simply states that the HTML from the site that you are visiting has badly formed HTML and to report this to the web site administrator.
I don't make my programs make up for other peoples mistakes.... Why should you...
Cheers
Posted by Mike Jackson at March 19, 2003 6:55 AMI am in way advocating that Safari "break" on bad code. I AM advocating that Safari load web pages that have correct code and for those that have poor code , Safari would do it's best to render the page. At the same time, there should be a clearly visible indicator showing good code and bad code, like in iCab. I do not see how this will cause users to be confused. A static icon/button/indicator is unobtrusive. Look at iCab. It has a smiley face icon that changes moods and colors depending on the status of the web page code. IF a user wants to, they can click on the icon to see what it has to say. IF they do not click on the icon, they learn nothing and loose nothing. In the iCab perferences there is a setting for controling the "validator". Thus, for those in the know, they can adjust the settings/sensitivity.
If browsers continue to fix our mistakes, the web will continue to degrade in quality to the point of it being unusable except by only the latest and greatest technology. Who does this benefit? Only the hardware manufacturers and their coffers.
We need to promote good valid code and "spank" those that can not do it.
A simple icon/indicator is all that is needed. When clicked, more info is displayed. Fairly simple solution.
So, yes render correct code and TRY to render incorrect code, but let there be known what is good and what is bad. If the browser does not teach the developer how to write proper code, who or what will?
PS : the CEO analogy is excellent! :)
Posted by Ruairi McFarlane at March 19, 2003 10:18 AMSure sure, you'll call this Micorsoft bashing but .... The thing I find interesting is that MS Word "save as HTML" writes improperly nested code like the example give so consitantly that Macromedia could come up with a "Clean up Word HTML" function in their Dreamweaver product.
I wonder if MS FrontPage flaunts the standards that obviously as well. And IE seems to accept that you say? Astonishing.
Posted by Lyle Turner at March 21, 2003 3:49 PM