Dude, how 'bout fixing all the flaky random display bugs in beta2 first?

Flaky random display bugs? What do you mean?

I suppose this means overflow:scroll too? :-)

Perhaps they are caused by lack of overflow: auto support? :)

Probably the one mentioned here: http://forums.macnn.com/showthread.php?s=&threadid=149517&perpage=50&pagenumber=3#post1290548

Apparently fonts sometimes blow up to over 100 point randomly. Haven't seen it myself.

Those problems (I believe) are caused by some of the unsupported add-ons to Safari. They do nefarious (and evil) things to Safari's prefs and user agent stylesheet that make them potentially incompatible when you upgrade. What sucks about it is people then go to forums (and blogs) and blame Safari.

The International Herald Tribune website still misrenders. For example,

http://www.iht.com/articles/93246.html

This is pretty much the only failure I have encountered. Nice work.

Actually, what I meant to say is that I feel your pain...I just spent two weeks rotating photon polarization states around different axes as the photons propagated through from one scattering event to another. I bet overflow:auto is just like that.

Holy carp! I didn't realize such evil actually existed. Does this mean you're now in favor of regime change for the W3C? :-)

(For those who want to know what overflow: auto requires, check out this URL:

http://www.w3.org/TR/REC-CSS2/visufx.html#overflow-clipping

The overflow property has several possible values. "visible"
and "hidden" (basically clip to the box) are straight forward, "scroll" is an easy way out since you can put up the scroll bars (or what have you) even if there's not enough to cause scrolling. But "auto" *looks* like it's one of those DWIM mode things that could really ruin one's day if there's any dynamic content involved. You should get scroll bars when there's enough to scroll, but not get them when there isn't, and heaven help you if you clip anything outside the box...

I guess the good news is that at least it isn't the default value. I presume you guys have tools to figure out how commonly used overflow: auto is on the Wild World Web?

Our site, http://www.liberationmedia.com, still looks funky. See that text that sits on top of itself at the top? What is up with that...

Also, the damn Java API cookies still don't work.

Yay! The current behavior sucks cause theres noway to access the improperly hidden content.

But why are you taking time out to post this on your blog?

*cracks the whip*

(all in jest my friends, all in jest)

phpcollab still does not render properly.

You are a goddess.

Great work!

It'll get there, it sounds like some people want to get there by a different route and perhaps they think that there is a faster vehicle but I think you guys are doing great work.

I would ask one thing (there is always something with us isn't there!), can you please set an option up in Safari that will allow automatic spell checking in input controls? I know I can select the box and then turn on the option to check my spelling as I type. I would like to enable this permanently. I can't spell!

Anyhoo, keep up the good work.

Daniel

p.s. when typing in an input box that is overlapping the status bar (yes I turned it on), and the input carat is right on the status bar, vertical lines appear as you type and then don't seem to want to go away. I'll submit a bug report now. I just noticed that you don't have to be typing, just the cursor has to be right on the status bar.

The spell-checking bug is on file. It's not really my area, so I have no idea if it will be fixed by 1.0 or not.

Yea! That's the one bug I really wanted to be fixed.

First of all, great overall job on Safari guys. Tabs and autofill mean my default browser is now a toss up between Safari and Camino. Looking good for the 1.0 release.

On the subject of "Flaky random display bugs" still to fix though, I'm still waiting for the CSS 'drop cap' bug to be fixed, as found at http://www.exposition.co.uk/about.htm. This is an odd one, as the first public beta displayed differently than the second and third, yet both were/are wrong.

TIA

Andy W

Great work, Safari-team! I can now even view the standards-compliant Netscape Devedge site without crashing the browser every time!

I have one rendering bug that's not been fixed yet (it may be on your list as I submitted it through Safari's bug button).

CAPTION tags within a %-width table don't render properly. First, they occasionally render as wider than the table they're in; and - more importantly - when you resize a window, the CAPTION tag stays the same width, even though the rest of the table resizes.

Otherwise, great work!

I will be soooo happy when overflow: auto is implemented.

When I downloaded the newest public Beta, I had my fingers crossed, saying "please let overflow: auto be implemented, please let overlow: auto be implemented". That's one mouthful of a mantra to be repeating.

Luckily, my disappointment was eclipsed by all the other cool stuff that did get implemented in this release.

Here is a bug that I find truly annoying!

Above the Home and Autofill button there is a "dead spot" where you cannot drag and move the window. You put your mouse there and hold and it does nothing.

Be nice to see table-border-collapse working. Tables look like crap in Safari at the moment.

Small suggestion: Option to only loop Gif's once.

Outstanding. This is the only real showstopper bug that I still want fixed. Glad to see it's being worked on.

I to have seen the text on 1 page zoom to 2 or 3 times it's original size when hovering over a link. The text on this link is not smoothed, but when I hover the mouse above it the text is then smoothed and it becomes much bigger. Also because it gets bigger it disrupts the normal positioning of other elements on this page. I have not installed any additions to Safari. And because of v.64 I have reinstalled all my system. So this behavior is not caused by my irresponsibility.

i forgot to say that the people developing Safari have done a great job... thanks...

Look at the stylesheet at and the pre and pre.small rendering. You can see more in this post:
http://nslog.com/archives/2003/04/14/safari_10_beta_2.php

Can anyone point me to the location on W3 which proves that IEWin's implementation of the below test case is wrong, and kHTML/Gecko is right?

http://phrogz.net/tmp/sidefloattest.html

If anyone would like to take a quick peek at the small test page here:

http://www.stats.gov.nt.ca/oberst/tech/safaribugs/JavascriptFrameBug.html

This is an example of something we ran into here - setting the "location.href" from Javascript failed after the first try. It works with all other browsers, but I'm curious if there might be something suspect that Safari is being stricter about? (Also, it looks like something is broken with elements). I've bug-reported the page.

YA!!!

I am thinking that this will correct a lot of the rendering problems you are seeing in iht.com..

All the bugs I see at a quick glance, are all related to overflow...

Is it me or does Safari not handle font-variant: small-caps properly? Thanks!

The huge font thing and other display problems are caused by setting a style sheet in the Advanced preferences. (In my case it was the ad blocking style sheet mentioned on slashdot a couple of days ago.)

I filed several bug reports before figuring this out. I imagine that the apple bug reports for this version are going to be swamped with "false" reports because of people using these style sheets.

There IS a bug in safari that once you set the style sheet you cannot remove it. You can choose "None Selected" from the style sheet menu, however, safari still uses the old style sheet. If you delete the style sheet file, then safari will hang every time you load a page. (even while there is "None Selected") Presumably it is hanging while looking for the missing style sheet.

Dragging your safari preferences to the trash will exorcize the evil CSS beast and return you to browsing normality.

Jeff: why not just make the stylesheet empty?

That dead spot above the home and autofill buttons is weird as hell.. and yet.. I find it strangely amusing at the same time :)

Fix the scrolling first

A BASIC Major bug in Safari.

I can not get any other app to do this. I have confirmed this bug with many others who see the same thing.

Find a web page that is at least a few screens of scrolling in length now spin your mouse wheel to scroll down. (for me I roll wheel towards me) AND AT THE SAME TIME move your mouse towards you also. Faster the better doing at same time.

Scrolling stutters or scrolls some and jumps back or doesn't scroll at all.

Same thing happens when i scroll up and move mouse at the same time away from me.

Nick: You mean delete the contents of the style sheet but leave the empty file on disk? That was one approach I simply didnt think of. There was nothing precious in my preferences anyway.

It didn't take me long to get rid of the style sheet once I identified that it was the problem.

I downloaded a couple of the ad blocking style sheets mentioned on slashdot and tried them out, but decided not to use them. I had "None Selected" for my style sheet for several hours while I got rendering problem after rendering problem.

It took me a while to connect the display problems with the style sheet I installed from the Slashdot article, especially because I thought that I had disabled it in the interface. When I went to google and it didn't render properly, I knew that the problem was local and not with Safari.

While you're in the scrolling code, please consider DHTML support. The following things are quite critical:

1) correct scrollHeight/Width reporting

2) ability to do programmatic scrolling

This is exposed by assignment to div.scrollLeft/Top in Moz and IE

3) scrolling support for overflow:hidden regions

Many people don't realize that elements with scrollbars aren't the only things that should be able to scroll. Take for example the Windows Explorer header bar. Introduce horizontal scrolling and you'll see that it scrolls with the body. Introduce vertical scrolling and note that the headerBar is, in fact, a separate scrolling region from the body, which does not have scrollbars.

The other reason to allow scrolling on regions that have no CSS scrollbars is to enable custom DHTML scrollbars.

The most straightforward way to address this is provide scrolling support (ability assign to scrollLeft/Top, correct scrollHeight reporting) on overflow:hidden regions. This is what IE does.

Thanks

Frames still dont work properly. Click on my Name (link) and try the gallery on Kristinna Lokens website (Terminatrix in T3). When thumbnails is clicked the target frame goes white. Reload helps, but that should not be nescessary.

Why does frames work so bad in Safari???

Try again. Click on my name to go to the corrct Kristanna Loke site with frames.

This time its the winner. Sorry!!!

while perhaps not a core safari bug, i think it's important to address the lack of support for Java applet javascript communication. perhaps this could be implemented using Sun's HotPlug API?

see link for source and examples. from the page: "Physlets are written using Java code that runs on Microsoft, Netscape, and Sun browsers.  Unfortunately, Physlets require not only a Java enabled browser, but also JavaScript to Java applet communication.  Current Macintosh browsers do not support both Java 1.1 and this communication."

overall safari is shaping up to be a great browser. thanks for all your hard work, Dave (and the rest of the safari team). and a big thank you to dave for providing this communication outlet. mad props.

Actually, I'd say that IE's treatment of overflow:hidden is in clear violation of the "no access to the overflowing content" language in the CSS spec...

HALLELUJAH!!! E-mail me an address and I'll hook you up with some caffeine or music to help the work yo!!

Interesting. My previous post is missing.

For some reason, there are certain GIFs that Safari cannot seem to display properly. My web site (http://www.wrong-keyhole.org) uses GIFs for title banners on each page. For some reason, Safari does not display these GIFs, despite the fact that these GIFs seem to display perfectly on other browsers and operating systems (IE for Win/Mac; Mozilla and its variants [Camino, Firebird, etc.] on Win/Mac/Linux).

This is the only major gripe I have with Safari.