Surfin' Safari

Front Page  -  Technorati

Spell-checking settings for textareas will now be persistent. I know many people had been requesting this feature, so I'm here to deliver the good news. Direct your thanks to John for implementing it.

Enigmo is so addictive. Good thing I got overflow:auto working. ;)

Ok, I've got it working! It scrolls, tracks events properly, etc. I tested on Squidfingers.com and the high-tech look for Adactio.com. Both render perfectly.

And iht.com articles now display correctly! My guess is that the site was trying to set scrollLeft and scrollTop on the columns in order to position the overflow:hidden content. That didn't work before, but it does now, so the articles display properly!

Woo hoo! If you know of good overflow:auto/scroll/hidden tests (especially DHTML tests), post trackbacks. I'm disabling comments on this entry because I know the invitation to post tests will result in people posting unrelated bug reports, and I don't want to wade through those at the moment.

Ok, I have events going to the scrollbars properly. I can move the thumb around and push the arrow buttons, etc., and the scrollbars in the overflow block fully respect z-index etc., and only get events if the layout engine decides they're on top.

Now comes the fun part. I actually have to implement scrolling. Woo woo. Blitting and widget moving. Oh boy. Then I just have to do mouse wheeling, auto-scrolling for drag selection, arrow keys, proper tabbing navigation, proper event coordinate reporting, and the ability to set scrollLeft and scrollTop.

overflow: auto... my arch-enemy.

I now have scrollbars appearing and disappearing more or less on cue when overflow:auto is specified. There are still a few glitches though with inaccurate measurement.

I have fixed up clientWidth and clientHeight to take into account scrollbars added via overflow, and I have scrollLeft and scrollTop actually returning sensible values (and not the random number generation they do in v73). To address someone's issue in the comments, yes, you will be able to scroll even overflow:hidden blocks by setting scrollLeft and scrollTop and not just auto/scroll blocks.

My next task (after fixing the few layout glitches that remain) will be to get the scrollbars to show the right thumb proportion and to enable/disable properly in overflow:scroll mode.

After that, the real fun begins. Then I have to make the scrollbars actually scroll. This is pretty tricky in our system, since - in order to deal with z-index properly - we always send mouse events into KHTML first, so e.g., the scrollbars don't get the event. I have to send the event into the DOM first and only if it doesn't chew up the event will I let the event go to the scrollbars.

It would be really cool if someone Web-savvy could provide a reduction for iht.com and/or figure out why it misrenders in Safari. Use comments/talkbacks if you figure this out; no email please.

Today I began work I've been dreading for six months: the implementation of overflow: auto in KHTML. Feel my pain.

Get it while it's hot.

I have received a few complaints about Safari's default font size of 14px (instead of 16 px). I thought I'd kick off a discussion (either through trackbacks or comments) about this issue. I would especially like to hear the arguments in favor of using 16 px instead of 14px.

No new WebCore features to report. I've just been busy fixing rendering bugs. I fixed a few problems with floats (extra padding could get added below floats). Also a few line breaking bugs with <nobr> have been addressed.

Most of all though I've been working on tables, mainly reverse engineering (mostly by inspection) the algorithms used by WinIE to size tables and then trying to match it exactly. There have been a lot of table adjustments made, so the results should be more in line with WinIE now. In particular, excite.com is now fixed.

The next release of Safari will be fully embracing Web standards by dropping all support for tables. From now on, any pages that use tables will cause Safari to play a very loud raspberry sound and refuse to display the page.

Auto width tables will actually cause Safari to crash, accompanied by a loud explosion. Safari will then search your hard drive for all files that contain the word "table" and it will replace them with Egyptian hieroglyphics.

For all sites that attempt to nest tables more than four levels deep, Safari will play a loud flushing sound, and it will remove itself from the dock and erase itself from your system in order to protect itself from your bad taste.

I had the opportunity to announce my plans to drop table support to the WASP (We Annoy Safari Programmers), and they applauded the move. "It's high time someone took a stand and stopped supporting these unpredictable monstrosities," said John Feldman, one of the most outspoken members of the WASP. "Who really knows how to build a site using tables anyway?"

Unfortunately word also leaked to the TAG (Table Advocacy Group), and they were outraged. Jim Lerners-Lee had this to say. "I hate all this newfangled crap. XHTML2, XFORMS, CSS3. It's all so complicated. Me, I like tables. Good old-fashioned tables. Especially when used with the blink tag. Safari is obviously taking a dangerous stance by dropping support for tables, since everyone knows they are the backbone of the modern Web."

Despite protests from some individuals, we're not backing down. You'd better get those pages converted. You have been warned.