I agree with you. This residual styles fix definitely should only apply to quirks mode.

Now, can you go fix some CSS bugs? Go check out that test page in the comments in a previous entry (I forget which) and play around there, there's some bugs shown there. There's others that I've bug-buttoned that haven't been fixed (well, not by v64 at least), and suchlikes.

Well, go ahead and submit it to Bugzilla.

Dave, I agree. Standards mode shouldn't fix tag salad.

You can't render *every* web page out there. Some are just terrible!

If standard mode is fixing up tag soup, then what the heck is the difference between standard and quirks mode? I hope it's just a bug.

Maybe this is why Gecko is so slow, because it renders tag mixups even when it should be in the fastest mode? I'd be happy to spend the extra 2mins (if that long) to make pages work in standards mode just for the speed for my users.

By the way, does your residual style fixes include an input tag (type=text) with style="border: none 0px;"? hehe

"Maybe I'm taking a hard-line stance here, but I view fixing up tag misnesting as a horrible quirk that should not be implemented in standards mode. If you don't behave strictly when in standards mode, how will people ever write valid HTML?"

That quirks mode and its ilk exist in so many mainstream browsers is appalling. Parsing malformed markup as if it made sense has only led to the proliferation of even worse markup and more counter-productive attempts to "fix" them client-side. It's an unfortunate market reality that this nonsense must be done for HTML. But playing games too with pages that flagrantly violate the *most basic requirements* of the markup language which its doctype claims adherance to...that's where a browser officially becomes useless.

When an author chooses to label their page as XHTML or XML, it is they who are accepting responsibility for any rendering errors that may result from their page's failure to conform to the DTD. Shifting the responsibility onto the browser to attempt to parse tag soup--*especiially* where the author's doctype promises that tag soup will not be present--does a disservice to ill-informed authors and unsuspecting surfers alike. Worse, we all suffer for it as browser performance and innovation is bogged down in ever-more code devoted to anticipating the infinite ways in which authors will screw up their pages.

Safari excells as a light, fast, elegant browser. Keep it that way.

"Hard-line?" Not remotely. Draw that line, Dave. Stand firm. Please.

Dave, standards mode in Mozilla has approximately the following effects:

1) Make CSS parser strict (completely)
2) Make layout a bit stricter
3) Not load quirk.css (this is most noticeable)
4) Make the parser parse comments per spec

#4 is the only effect it has on the parser. Changing that is nontrivial (the parser is very fragile code, and as you've discovered a number of pages out there claim to be XHTML or HTML4.01 Strict and don't come even close).

At this point, work on the HTML parser is has basically been suspended. It's taken the last 5 years to get it to a point where it "pretty much works" and making any changes is just as likely to break a slew of sites as to fix anything; this includes the quirks mode change. :(

Now _if_ the page Mozilla gets is XHTML (as determined by the MIME type) then it gets run through the XML parser instead of the HTML one, and that is a totally different story.

For all the people here who want to speed up pageload time for users by having a totally valid document, use an XML MIME type. That will radically speed up the parsing phase. ;)

rickg's original Parser design was that the [a href="http://lxr.mozilla.org/seamonkey/source/htmlparser/src/COtherDTD.cpp"]Strict DTD[/a]" would apply to pages in [a href="http://mozilla.org/docs/web-developer/quirks/"]standards mode[/a], but that isn't what happened, for [a href="news://news.mozilla.org/slrn8pj5br.she.dbaron@is01.fas.harvard.edu"]a number of reasons[/a]. Because that didn't happen, we ended up with things happening in standards mode that were really intended only for quirks mode.

(I assume there isn't a way to make this thing make links. Ugh.)

So what we need is some "i" software to allow the humans to create valid HTML, or a browser that has a validation mode that allows people to browse - and offers up what it sees as invalid HTML in another source tab - highlighting the invalid code and possibly- offering ways to correct. A browser that acts as a HTML mentor of sorts.. On second thought - seeing as how Safari in itself is a massive undertaking - I won't hold my breath - but its an intriguing idea.

Bottom line is validation needs to be easier - tweaking code to work around others mistakes is one thing - teaching them the values of proper HTML is completely another. I do understand the postion you are in however - most people won't understand that it's the page that is junk - not the browser.

On another note - I find it fascinating that you can take the time to explain the problems you come across - as well as fix them. You are obviously an exceptionally talented individual. Apple and it's users are fortunate to have you.

I think you're completely right, Dave. Don't try to "fix" bad code in any page which claims to be XHTML.

I'd like to have an indicator which allows one to see whether the HTML is valid, like iCal. Perhaps something subtle, similar to the lock icon for SSL. It doesn't have to jump out at you like the iCab smiley face.

What is this "quirks" mode? Is that like setting the DTD to transitional?

I agree completely, standards will never be followed if browser developers keep providing safety nets for garbage HTML or XHTML. Frankly, I think browser are already too forgiving, but at the same time, consumers should not have to suffer the mistakes of idiot web designers.

Matt, "quirks" mode is having no DTD at all.

xyz said:
"So what we need is...a browser that has a validation mode that allows people to browse - and offers up what it sees as invalid HTML in another source tab - highlighting the invalid code and possibly- offering ways to correct...I won't hold my breath - but its an intriguing idea."

Not such a pipe dream, after all. Essentially what you are describing is the built-in lint (not validator) which has been a feature of iCab for several years already. See for info.

It's be cool if someone would build a plugin that any browser could use to do on-the-fly (real) validation. Very useful for webmasters, an eye-opener for others.

iCab URL above got deleted. FWIW, it's http://icab.de/info.html

Adding my voice to the crowd, I agree completely. Please don't do kludges in standards mode. If someone puts a DTD on their document, they should be willing to code to it.

Tim said: "I'd like to have an indicator which allows one to see whether the HTML is valid, like iCal. Perhaps something subtle, similar to the lock icon for SSL. It doesn't have to jump out at you like the iCab smiley face."

I'd like to see that indicator too but I'd like to see 3 or 4 varieties of it indicating the severity of the tag-soup; a different icon for each severity.

on top of that, I'd also like to see the icon become more obvious (big or bright or something) as the soup gets worse. let people know that the site they are viewing is based on bad code. some of the site programmers might become ashamed enough to do something about their code.

could you place the icon next to the page title? add a label to the icon so that people know what it means; eg, "html Code: Good", "Average", "Soup", "A complete wacked up mess" ;-)

Here's a relevant URL:
http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp

I noticed something interesting about v60. The font in table cells was not behaving the same way as outside the table (the font was a couple sizes larger). After adding a DOCTYPE to the file, the font sizes in the cells matched the text outside the table.
I look forward to testing that with the next release version of Safari.

-Walter

Mozilla has been in the "let's put a 'this page is invalid' badge somewhere" business before. In the end, most were against it.

- Why should a user care if the page he's using doesn't follow some arbitrary standard he doesn't know anything about?

- How exactly is this going to force page authors to write better markup?

So some wanted to have Mozilla automatically send e-mail to the malformed pages' authors. Ugh. No. A browser that sends out spam like this might as well be blocked by even more sites around the world.

Instead, let's hope IE will soon support XHTML with an XML mime type. Then parsing is strict, and fast.

Yeah, it's totally true that Mozilla doesn't use the HTML parser for real XML files, and that's really the future, so maybe I'm overreacting here.

Is the problem that tag misnesting isn't handled in only a couple of places? (I'm ignorant of the parsing code in Mozilla actually.) The implementation that I cooked up for Safari is confined to only two methods that perform fixups at certain precise times, but it could be that my implementation (being in a fledgling state) isn't quite adequate to cover all the cases Mozilla is.

I do know all 18 of the bugs on my list were fixed by my implementation, so maybe the problem is pretty simple and the parser design in Mozilla makes fixing the problem harder?

>A browser that acts as a HTML mentor of sorts.

iCab does that, but of course, if you're a web developer, you should also check your markup using the w3c html validator and BBEdit's html checker.

I think that Safari shouldn't be too forgiving to bad html. It's in an unique position where it is able to influence the web. Soon, a majority of all Mac users will be using it. Mac users are very vocal about stuff they don't like, and many people responsible for sites with bad markup won't be able to just ignore them.

The idea of the browser being unfriendly to invalid pages is a bad one. Mozilla wasted years on this before coming to their senses.

If you want people to use your browser, it has to display web pages. It doesn't matter what you think of the web page. The user wants to see it.

In the end, all you are doing is forcing people to use other browsers.

here's a lame "me too"...

1: Don't make Safari too forgiving regarding bad HTML.

2: A "does this page contain good or bad code"-button can be very useful; let people activate it using the debug-menu if there's any doubt about if the masses would get confused about it.

I will not pretend I write 100% clean HTML, but I will also agree that pages that are badly designed aren't worth to be shown correctly.

Otherwise I could make a real bad page and demand you to make sure Safari loads it. You will have to make 1000s of exceptions to load all kind of bad code.

Maybe it would be nice to have the real bad things shown in the source editor, as Netscape Navigator does (at least my old 4.7 does blink bad source sometimes).

The browser could try to load xhtml-pages as xml. As it loads the page, it has a counter which counts how many major nesting errors are found. If at the end of page too many nesting errors were encountered, the browser reloads the page with quirks-mode on.

This way most xhtml-pages would load quickly, but malformed ones would have to be loaded twice. If most pages aren't be malformed, this might work quite well.

What about something simple as having safari showing a tiny indicator in green or red depending on the format being valid if the browser has to fix the code?
Everyone would see that the html was broken from developers to visitors.

Anyway, a person with an invalid site would proably get quite a few visitors pointing out the invalid code if it was a no-brainer to see it (you wouldn't need to know anything about html to see something is wrong).

The indicator should be tiny and easily ignored since a majority of sites probably will have a red light showing :)

> The browser could try to load xhtml-pages as xml.
> As it loads the page, it has a counter which
> counts how many major nesting errors are found.

The first such error is a fatal error in an XML parser, forcing abortion of the parsing process. Unless you hand-code your own XML parser (pretty pointless, given all the off-the-shelf ones available), you won't be able to recover from such an error in any useful fashion.

Lint does *not* belong in a general purpose browser! If there's sufficient demand for such a product, let a developer customize WebCore for such. But don't put any if this error checking in the primary Safari distribution.

In fact, that's what iCab should switch to: a WebCore distribution with the iCab innovations.

I am really liking both the universal plugin, and the status - rating ideas. (The former obviously requiring a much larger scale effort..)

I was going to mention BBEdit, but they just raised their prices a bit high, and the low end Wrangler supposedly doesn't do HTML. Which doesn't leave a good low priced HTML validator that I am aware of. (I am not saying BBEdit isn't a great program worth the money - but that it's a bit pricey..)

The comments Boris wrote:
"At this point, work on the HTML parser is has basically been suspended. It's taken the last 5 years to get it to a point where it "pretty much works" and making any changes is just as likely to break a slew of sites as to fix anything; this includes the quirks mode change. :("
is pretty much the logical conclusion of what will happen in the long run and not a real inspiring situation, whereas helping or even pointing out bad HTML will help to make this mess we call an internet a better - faster - place..

I really feel sticking to the defined standards (give or take a little), and point out the garbage which should be fixed by the individual(s) who wrote it would be the most helpful scenario for all of us..

For those who want an easier way for web authors to validate their code, check out favelets/bookmarklets. You can use them right now. I use lots of them, frequently. The validation favelets are great.

http://tantek.com/favelets/
http://www.favelets.com
(same site)

Seems to me that (prominent, high-quality, and easy to use) validators need to be built into all HTML-editing applications. (And maybe even somehow also in HTML-generating apps; altho' what app is actually going to put up a sign saying the code it just wrote is invalid? Probably none, unfortunately. Hello, Microsoft [altho they're not alone].)

Having some subtle indicator in web browsers seems like an OK idea, as long as it doesn't confuse your average clueless newbie.

Browsers need to serve the public masses as well as possible. If that happens to conflict with the needs of web developers, web developers need to find their own apps to meet their specific needs.

>The idea of the browser being unfriendly to invalid pages is a bad one.
>Mozilla wasted years on this before coming to their senses.

We're not talking about all pages, just those that *claim to be valid*. If you allow invalid pages to claim to be valid and *still* display correctly, the whome freaking mess we're in right now will never go away!

>altho' what app is actually going to put up a
>sign saying the code it just wrote is invalid?
>Probably none, unfortunately.

Well, Dreamweaver MX...

>altho' what app is actually going to put up a
>sign saying the code it just wrote is invalid?
>Probably none, unfortunately.

GoLive does this. It displays warning flags for all un-kosher elements, including its own.

Make it a browser option. Problem solved.

> Well, Dreamweaver MX...

> GoLive does this. It displays warning flags
> for all un-kosher elements, including its own.

This is great, of course.

Sorry that I didn't make myself clearer. In the parenthtical portion of my comments, I was talking about applications that are not HTML editors but are able to generate HTML. This includes a huge number of word processing, page layout, database, image processing, and I'm sure many other types of applications. These apps are not HTML editors but are the source of a LOT of web pages. Any many of them generate terrible, non-standard HTML. (Hello, Microsoft, altho' they are certainly not alone.) But do any of these apps include an (X)HTML or CSS validator? This needs to happen, but probably won't. (Hello, webstandards.org.)

The real trouble is that for Mozilla or any other browser to replace IE in any significant manner, it needs to be able to render any page that IE will render as the page's creator intended, even if the HTML is *&^%.

As it is, most people don't look at the code of a webpage when it doesn't render as expected, but they blame the browser instead. Since IE is the (unfortunate) de facto standard, "as expected" means how IE renders it. And there are plenty of people out there making websites that they don't bother to test outside of the latest IE on Windows.

If IE didn't handle this terrible code, the Mozilla developers would probably feel no need to support it and the KHTML developers wouldn't either.

Matt posted:
"
What is this "quirks" mode? Is that like setting the DTD to transitional?
"

Which was incorrectly answered:
"
Matt, "quirks" mode is having no DTD at all.
"

The correct answer can be found here:
http://css-discuss.incutio.com/?page=DoctypeSwitch

WC3 needs to set up a Hall of Fame/Name and Shame page where junk pages like this get reported.

It's not enough to have people voluntarily badge their pages with the XHTML 1.0 compliant logo (who cares?) but designers would get upset enough to do something about it if they get named on a major public site...

I am only a surfer and expect things to open. I'd like to know if the code is bad, but I want these pages to open regardless, even if I have to make an extra click or two to make it happen. Surfers expect prgramers to be briliant and create pages that open with plugins we already possess ...we do not understand and don't want to! I spend 6+ hours a day on my G4, surf on Safari and cuss when things don't open ... my peers are less sophisticated.

wow