Wow, I was reading your blog and I just notice a new entry, seeing an application from a major developer evolve in real time is cool :-) Reading that your fixing bug instead of trying to implement "cool" stuff before the final version is really appreciated.

Thanks for a great browser already.

I agree, laying the proper foundation must be priority one.

Can you comment on your plans for the abilities of the engine of Safari 1.0. Will it support MathML? How will its XML be? What about SVG?

Keep up the good work.

This is just my opinion. I don't want to be rude by pointing out obvious things, but by using Gecko, most of Safari's rendering issues would've been sold by now. The argument for using KHTML was its small and well-designed core. That was true a year ago. Today, KHTML is about to be bloated and polluted with quirk mode(s) right before our eyes. Wouldn't developers’ effort be better spent by refining Gecko? I have a feeling that AOL's interest in Netscape is waning, so Apple could've become one of the major Gecko players. Am I wrong?

There are arguments for and against the use of Gecko. In the end they decided for a variety of reasons KHTML was the way to go. Even if factors have changed since then it's still questionable whether it'd be worth the effort to even attempt moving again.

I'm primarily a programmer, but I do a lot of work with basic HTML/PHP stuff. Since most of what I do pretty much works on every browser without hassle (patially by design), I'm not mired in the browser standards quagmire. I'm basically an advanced browser user.

From that perspective, I couldn't be more thrilled about Safari, and its use of KHTML. I always assumed that if Apple came out with a browser, it would be either entirely home-grown or based on Gecko. KHTML seems to have given it the main advantages of both: The speed and solid integration of a home-grown solution and the compatibility of a time-tested browser. With every previous browser transition I've done, there has been an "acclimation period" where I use both the new browser and the old browser. With Safari, I dropped OmniWeb in a snap. I was actively irritated when OW launched in response to some external link. Everything I need works, and works fast. Sure, there are a couple of little neat things that other browsers have that Safari doesn't (chief on my list is OW's "shortcuts", from which I could seach a billion different sites with a simple command in the location bar), but there's nothing that I can't live without.

And the "bug reporting" function leads me to believe that Apple is committed to getting Safari to work properly with 99.999% of sites, i.e. no more periodic IE launches. I think they've done a fantastic job already, and the last mile will make things perfect.

What I would really like to see, though, is frequent "interim releases". Hide 'em, make 'em have gaudy "test build" splash screens/toolbar warnings, whatever, but make them available! Pleaaaase! ;)

I find it curious that people are discussing Gecko vs KHTML on David Hyatt's weblog. I suspect that Hyatt has already done all of this arguing a thousand times over, and there's not much worthwhile that anybody could add to that.

Yeah, I agree. If you want Gecko, you have plenty of options. The ol' phrase "beating a dead horse" comes to mind - not that Gecko is dead, just the argument in this particular forum. At any rate, I also would love to see nightly builds or something to that effect - even if they just go up on the developer site.

And thirdly, I'm totally impressed with Dave's openness about the project and willingness to accept comments, criticism and suggestions (*cough*bookmark exporting/syncing between Macs*cough*.) ;)

Safari rocks...

The problem that led to "almost standards" mode was that even the latest versions of Internet Explorer (and browsers going back to Mosaic, really) differ from standards-compliant layout of line boxes in that, if there is no text in the line box, they won't leave extra room for descenders. This meant that you could slice an image into bits and reassemble them in table cells leaving no gaps in between. This method became used on many, many sites.

Now, the proper standards-compliant way to do this is to use display: block on the offending images, or mess with some of the alignment properties to eliminate the descender space. Of course, nobody knew they had to do this until these carefully constructed layouts (often put together with standards-clueless tools) started developing gaps everywhere in Gecko, and, I think, Opera, even after they had been deemed safe on IE/Mac, which everyone had thought was wonderfully standards-compliant. I think the usual consensus is that this is an area the W3C overlooked while putting together CSS; they probably wouldn't have made this behavior standard if they realized this was going to happen.

There was a big argument in the early days between people who insisted on the W3C behavior, and people who said this was such an egregious problem that IE's way was better (and I think some people even said you could read the recommendation, which was somewhat obscure, in such a way that IE was correct, though that viewpoint did not ultimately carry the day with most).

Ultimately the Gecko people gave in halfway, and put in almost-standards mode and an additional level of DOCTYPE sniffing as a stopgap.

Here's the bug report that gave birth to almost standards mode:

http://bugzilla.mozilla.org/show_bug.cgi?id=153032

You (David) probably figured this out already, so this is for the benefit of the peanut gallery.

The link http://lowmag.net/testsite/ shows this rendering anomaly in the tabs at the top of the page, and the word 'LINKS' should be attached to the sidebar. Well the word 'LINKS' my be my fault due to a bad em value in my code, but it renders right on top of the box everywhere else. It's an odd thing to be exactly one pixel off on everything, but I didn't report it as a bug since the xHTML and CSS I wrote was fairly new. It validates both in the xHTML and the CSS validator, even though the CSS portion gives colour warnings.

I'm glad to hear this is being worked on, and so far so good on rendering with em values (which several mozilla builds had a problem with in the past, IIRC)!

The one thing that I find sad is that there is so much controversy that apple "chose khtml over gecko". A friend of mine brought up an excellent point in the fact that shouldn't people be excited to see the open source model working? Why don't people look at the fact that it wasn't khtml over gecko, rather Apple had a CHOICE of using either KHTML or Gecko. That choice is what drives the open source model, and the fact that Apple is helping advance KHTML only means that we now have two browser choices that are (will be?) excellent and hopefully better than the Internet Explorer Juggernaught that so many people loathe on windows and the mac.

I applaud apple for safari. It's great; however, I also have a special spot on my dock for chimera. It's fantastic. The latest nightlies are faster than ever (competition seems to have made address page loading speeds sooner than they may have) and it renders more pages that I visit accurately. I love the experience that safari gives me though. It's quick as well, but extremely easy to use. Spartan, but in a good way.

While "Lars is working on a new CSS parser" maybe he could fix the following:
Put "overflow: hidden" in the style attribute of the HTML tag, resize the window - everything goes crazy!
Just one more, how do I set a DIV to fill the window vertically, with a 50px border. I either use Quirks mode "margin: 50px; height: 100%;" or with the CSS box model in Gecko, I use "position: absolute; top: 50px; right: 50px; bottom: 50px; left: 50px;". Neither work in Safari.

Hey, Mr. Hyatt.

Thanks for letting us live vicariously through you as superstar programmers. This is neat.

Sorry if off-topic. The following very useful site does not work in safari, click on the search button to check:

http://www.opodo.co.uk/otpbvpl/Homepage/Page/Homepage.jsp?Locale=uk

Its an online airline reservation service used by most my colleagues (academic). Joint service of the eight biggest airline companies in europe. Works in explorer. Feel like it should work in safari too (please)

"The argument for using KHTML was its small and well-designed core. That was true a year ago."

And a year ago is when the decision was made. If the Safari developers could have seen the future, they might have made a different choice, or perhaps not.

The point is that you make the best choice with the information you have at the time. A year later is not the time to switch rendering engines, rendering your year's worth of work useless.

Why are some of reporting bugs on this weblog?

You HAVE reported them already through Safari's built-in bug reporter right? If so, then why are you being redundant here and giving David more reading to do which takes away from his programming time? :)

Sorry to add a bug report, but I just noticed it when clicking on the comments link for this post.
I don't think I could send a screenshot of it.

Safari shows the "Comments (17)" bit normally,
but when the mouse is over the "17", I get
a 1/2" wide solid blue bar extending from window
top to window bottom, obscuring the text underneath.

A similar, narrower bar appears when the mouse
goes over the "ckB" in "TrackBack".

Actually, on further experimentation, it appears
that the mouse doesn't have to be over the text,
just in the same horizontal position as the text
I described. Even up at the top of the page in the whitespace under the blue bar. Very strange.

Wait, sorry, I'm a dumbass. I was using Chimera, not Safari. The problem doesn't occur in Safari.

(Distant rumble as millions apply fingers to forhead in 'L' shape.)

Mea culpa.

hey Dave, thanks for work on a great browser from a great Company. Looking forward to the final release!

-Brad

p.s. (I'm on a PC currently, and i have to load your blog in Mozilla for it to display properly. IE doesn't like it! Was this your doing? :) heh heh)

Something tells me we shouldn't be surprised if comments will be disabled again pretty soon...

I think it's actually good for the Web in the long run that Apple chose something other than Gecko.

The whole point of standards is that we should try to author to something other than a particular engine's rendering. Right now Gecko is more standards compliant than everyone else, and IE isn't that bad; but if we take it to mean that we should simply code to IE and Gecko, and take Gecko rather than the specification itself as the gold standard of correct behavior, we're back in a new version of the brittle two-browser world that has prevailed for so long. If Gecko has a CSS bug that people code to, it may never be noticed or fixed, and others might start trying to emulate it.

It's better if there are multiple bodies of more or less standards-compliant code competing with one another, as long as there is the understanding that, in the browser engine (as opposed to the UI), correctness is more desirable than unique features. There are already a few things that KHTML arguably does more correctly than Gecko (I found one myself), and over time there will probably be more. Eventually the various teams will learn from one another and everyone will benefit.

I think it's vital that Safari supports the standards... and only the standards, except where this renders pages unusable. I'm a long-time web developer and I'm fed up with creating several different versions of pages that use CSS and Javascript extensively just to make them look right only to find IE on Windows renders it differently to IE on Mac, and Gecko browsers and now KHTML browsers.

I'm trying to go standards only, and now IE 6 in the most part allows for this, I think it would be great if Safari remains really standards-only. That way, it stays fast, avoids bloat and just works. I think web-developers are coming round to this idea.

In regards to Henry Blackman's comments regarding standards compliant browsers, I couldn't agree more. I too design my sites to be standards compliant, trying to use only features that I know work consistently across browsers and systems.

It doesn't really matter to me whether Gecko or KHTML is better, but if one can get the job done better, than that's fantastic. I'm really excited that Apple is taking a stab at it's own browser. Although it doesn't render my site very well at the moment, I'm eagerly looking forward to when those glitches are solved.

In regard to Henry and Kevin's comments re: standards, I advocate a less hard-line approach. I would like to see Safari support the standards as completely as possible, but I would also like to see Safari be bug-for-bug compatible with IE. My girlfriend and I share this computer-- she's no dummy; she's an ear-nose-and-throat surgeon, but she's not a computer nerd like me-- and I would like to be able to tell her that she can use Safari for 100% of her browsing needs.

I think an okay example of this is the IE-only, non-standard "document.all" API. A year or so ago I was tasked with doing whatever it took to get some old front-end code working with Mozilla for UNIX. The old code was written with IE-for-Windows in mind, and so made extensive use of document.all. I was able to work around it easily enough, by implementing document.all as a function inside a browser-specific block of JavaScript, but it would have been great if I hadn't had to. If we hadn't had to support UNIX-- specifically, SGI IRIX-- we probably wouldn't have bothered making the change at all, leaving Mozilla-for-Windows users out in the cold.

If I were king of the world, I would ordain that Safari should support web standards going forward, but that it should also be 100% compatible with IE.

Then again, I am *not* king of the world... yet...

Hiya,

i love the browser - but i have to go back to Netscape to get my school site to work

I am in the graduate program at UMUC and I log into the system at least 3 times a day via browser, and Safari has a few problems in there.

1) At the login screen you can not click on Login and have it take you into the site. If you click Login, then change the server (using their drop down box) it will log you in without a problem.

2) They use quite a lot of Java, and the tools for creating messages, replying etc within the site do not even show up.

Thanks

Keep up the great work !

Jim

>I either use Quirks mode "margin: 50px; height:
>100%;" or with the CSS box model in Gecko, I use
>"position: absolute; top: 50px; right: 50px;
>bottom: 50px; left: 50px;". Neither work in
>Safari.

Percentual height is bugged in Safari in this regard. Use position: relative to avoid the problem. See http://dhtmlkitchen.com/experiment/safari/index.html
No. 16 "CSS: Incorrect and incosistent handling of percentual heights."

>Now, the proper standards-compliant way to do
>this is to use display: block on the offending
>images

http://devedge.netscape.com/viewsource/2002/img-table/

More problems with inheritance inline boxes.
http://dhtmlkitchen.com/experiment/safari/index.html
see No. 15

This sounds great. My one question is why Apple doesn't allow us read-only access to the WebCore CVS repository. That way, we could make our own nightly builds.

"...Meanwhile Lars is working on a new CSS parser on the KHTML trunk that we'll be taking back into Safari once it's baked a bit longer..."

As I understand the Safari 1.0 development cycle, Apple took up the KHTML/KJS code and very quietly worked on the code in-house to make it fit Apple's needs. The improvements were then given back to the larger community. Kudos to Apple on that, but we have seen that model before.

Now from the quote above, I see that Apple is actually commissioning work that will benefit the larger community first. Again, this isn't exactly a new idea, but I think we'll see that Apple reaps big rewards from this 'Outside The Walls' development scheme.

By the time that David's team picks up the code for internal use, it will be reasonably well-debugged, and Apple's own testers can carry the debugging process to truly professional levels before being included in Safari. I expect to see really solid feature gains in Safari in the near future.

BTW, as someone who works for a certain Redmond company, I want to thank David and Apple for making life more exciting. The Mac community will benefit from friendly competition.

[quote]I think an okay example of this is the IE-only, non-standard "document.all" API.[/quote]

I think this is a REALLY bad idea. Microsoft is phasing out the "document.all" DOM structure and embracing the W3C way of doing things (document.getElementById()). The W3C DOM has been implmented since IE 5.0. Although you can still use document.all in the latest IE, you have no penalty for using document.getElementById, and it is compatible with Mozilla (and it seems Safari) also.

Also, one plus with MS pushing everyone to upgrade their Windows releases is that most Windows users are already using IE 5.0+, so by using the W3C DOM, you can actually reach the majority of the web browsing market.

-B

> "...Meanwhile Lars is working on a new CSS parser on the KHTML trunk
> that we'll be taking back into Safari once it's baked a bit longer..."

> Now from the quote above, I see that Apple is actually commissioning work
> that will benefit the larger community first.

Hmm, don't think so. Lars (Knoll) is one of the original Konqueror volunteer hackers, and the new CSS parser has been in gestation for some time now, way before Apple announced Safari. AFAIK Apple has nothing to do with it, the work was done solely for Konqueror 3.2, on a volunteer basis. Apple have contributed some really good speedups and not a few bugfixes (and one or two regressions too ;) to the main KHTML codebase, but this isn't one of them.

Interesting 'it's a small world' fact: Lars' day job is with Trolltech, who are based in the same building in Oslo as Opera Software. It must be something in the water...

Twirlip said:

"In regard to Henry and Kevin's comments re: standards, I advocate a less hard-line approach. I would like to see Safari support the standards as completely as possible, but I would also like to see Safari be bug-for-bug compatible with IE."

Not even Gecko quirks mode is 100% bug-for-bug compatible with anything, though it tries to hit the biggest highlights of assumed traditional tag-soup rendering. It's an impossible goal, since not all bugs in IE are even known, and they vary from version to version of IE and between Macs and PCs. The only way to replicate all the bugs in even one version would be by replicating the actual implementation, which is of course illegal and wrong.

I would be *particularly* against trying to replicate the bugs that IE exhibits while in standards mode; standards mode should not have intentional bugs in it at all. IE/Windows 6 has a particularly terrible one having to do with background repainting with negative right margins; I had to compromise my whole page layout to deal with it. I'd hate to see that enshrined as a de facto layout standard.

Finally, consider that if everyone tried to remain 100% compatible with the bugs in IE, the IE developers *themselves* would probably feel bound to retain them going forward. Since bug behavior tends to be more illogical and complex than the standard, this would lead to even more new rendering bugs in the resulting messy code, which would have to be retained as well, and every browser would accumulate rendering bugs until Web layout development became as annoying as it was in 1997. We don't want to move in that direction.

That Windows IE background repainting bug also occurs for negative bottom margins as well as right margins.