Slashdot Mirror

PithHelmet is much more powerful than Adblock, well worth the $10, and if you're a cheap bastard you can always just neglect to pay. The web inspector in WebKit nightlies beats the pants off Firefox's ugly and inconvenient DOM Element Inspector. And I'll proudly admit I'm not familiar with Firebug, but for debugging JavaScript, have a look at Drosera.

Yes, but it's not part of the OS. So it should be recompilable without changes. Which means that Apple would point you here when you asked for source code.

Sure, they may have reused some of the existing codebase - but it's unlikely.

Why is it that when apple does this kind of thing it's somehow "cool", but when Microsoft does it, it's somehow "evil"?

Because when Apple does it, it becomes a well documented, open API. Microsoft? Not so much.

I can't remember the specifics, but I'm sure Apple did something similar a while ago.

Not the same thing. Apple gave laptops to the top contributors to the WebKit open source project., not just people that had said nice things about them.

Yes, Konqueror, or better "KHTML" or WebKit http://webkit.org/ . Is being chosen by lots of companies as their web browser base, it is not tied in to anything (Apple removed the QT dependency) and is very efficient memorywise.

Nokia uses it in all it's S60 series and provides full source code: http://opensource.nokia.com/projects/S60browser/

It is the basis of Safari too and gives away its work on it now.

This is free (as in speech), cross-platform, light... what else do they need for the OLPC? I really do not see why they insist on using Gecko even with XULRunner, it will never be light enough.

Opera may be good, but Webkit passes ACID2 too and is free.

Apple may not have an official corporate blogging outlet like some enterprises, but some Apple employees do in fact blog in a (sometimes quasi-)official capacity.

Dave Hyatt's (now WebKit's) Surfin' Safari is one notable example of success, with Apple engineers being able to directly blog and communicate with end customers. It has now become a blog for all of WebKit, where other WebKit contributors - some within Apple and some not - can post as well.

Mac OS forge (and the hosted sites within it) is another recent example: Apple engineers, blogging, on servers owned and hosted by Apple. This wouldn't have happened a few years ago, and was a result of responses to community concerns about Apple's interaction with the open source community. (And no, it's still far from perfect, but the interaction is increasing, and that's a good thing.)

Both of these examples of Apple blogs are also open for comments, something some corporate "blogs" don't allow.

So are these "official Apple blogs" in every sense of the phrase, or in the vein that the article is intending to discuss? Maybe not, but it represents a lot more openness than Apple ever used to exhibit in this context. And anything greater than zero is "more open". Will Apple ever open up blogging to just anyone or blog about futures and abstract ideas? Unlikely. But there are notable exceptions to the blanket statement that "Apple doesn't blog".

WebKit is just a library. The S60 port of WebKit appears to do stuff but also mentions the need for a V3 (not a V2).

I'm not sure if you've seen this page though:
http://trac.webkit.org/projects/webkit/wiki/S60Web kit

It has instructions which mention build in a few places. It seems to be rather Windows biased and requires a large Nokia SDK download. It does mention that this is what ships with V3 so I assume that things should work fine for V2, but its not my phone. As an aisde I remember in my travels around Asia they freely talked of phone upgrades where all they did was update the firmware since the underlying hardware hasn't changed. The msot common example was the 3310 and 3315. You might also be able to upgrade the firmware on your phone to V3 assuming there were no hardware changes.

WebKit on its own does quite a lot, just appears that Nokia have screwed you in this version of the phone.

No, the blog post is just worded in a somewhat misleading manner. The text used, "WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.", is taken from the homepage of the WebKit project over at http://webkit.org/. It is most definitely the same thing used in Safari on Mac OS X.

Amazon still codes their pages so they come up "fast" on a 28.8 modem. Ebay is the same.

Doesn't sound like the Amazon and Ebay sites I visit on my 56K modem.

I ran a little test using Safari's show page test load window option from the debug menu, results below.

• Amazon UK:
  • Total (load) time: 79.275 seconds
• Ebay UK:
  • Total (load) time: 17.54 seconds

For development, I agree with you completely. Every page I author is written in a real XHTML templating language, but I do not serve XHTML. It's just not ready and serving XHTML as text/html is bad. Moreover, both the Gecko and WebKit developers recommend against serving XHTML and Trident (IE) doesn't support it.

tl;dr: XHTML is good for development, bad for serving and will remain that way till IE6 can be ignored.

Actually the KHTML incident was Apple giving back a whole heap of cluster patches from the original bit of source code they took out which was horrendously out of date, but if you actually look at things, WebKit is completely open source and available: http://webkit.org/ (which is what the GPL requires, funnily enough). If the KHTML people want a feature from WebKit, then they can just grab it off relevant subversion repository like every other project. Anyone can get to the source, I'm not sure what the problem is?

Try the latest WebKit nightly build. I think that the version of Safari that's going to ship with 10.5 is going to be a lot better, based on the changes I see.

The best part about running the tests on IE7 is that if one of the tests fails to load (as it did a couple times for me), instead of popping up the retry/cancel window, it will display an information bar stating that a scripted window has been blocked. You have to click on the information bar, "temporarily allow" the window, and then...RELOAD THE PAGE. The confirmation never appears unless you start everything over again. What a fucking stupid idea.

Have you done any serious web design? I mean hand coding, XHTML 1.0 valid code

If you're doing that nonsense, then the chances are good that your website won't work properly in any browser, because it either gets loaded as quirky HTML 4.01 or as XML, which the browser won't render. The HTML validator lies to you about whether your XHTML is valid XHTML, because it only looks at content not the server-supplied MIME type.

Application should not have to deal with HTML rendering on their own

I totally agree with this. The OS provides a libraries to make application developers life's easier, so they should be using what is on offer. On MacOS X you have WebKit, based in KHTML for this and with KDE you have KHTML. Since so many people clamour about Firefox, is Gecko available as an easily linkable stand alone library? I know for sure that the guys working on WebKit are trying to make it work on other platforms as a standalone library.

Actually, WebKit is considered to be superior to both the generic Mozilla/SeaMonkey engine and the fork of it used by Firefox. It was the first engine to pass the Acid2 test and I personally find it to be considerably faster than Firefox.

Apple should hurry up and fix those Javascript bugs in Safari already so that stuff like Writely will finally work.

WebKit (Safari) Nightly Builds

They don't actually use KHTML. Instead, they use a codebase called WebKit, a forked derivitive of KHTML.

Apple doesn't use much new code from KTHML anymore, but does contribute some back, although merging it into the KHTML tree is hard, because of the way the WebKit team makes patches. See the Wikipedia article on KHTML for more info.

If you want stuff fixed in Safari, report bugs to the WebKit team.

They don't actually use KHTML. Instead, they use a codebase called WebKit, a forked derivitive of KHTML.

Apple doesn't use much new code from KTHML anymore, but does contribute some back, although merging it into the KHTML tree is hard, because of the way the WebKit team makes patches. See the Wikipedia article on KHTML for more info.

If you want stuff fixed in Safari, report bugs to the WebKit team.

Chances are it works fine on a current Safari nightly. The current release version of Safari really sucks in terms of DOM implementation; the nightlies work much, much better.

Did you even read the Bugzilla page you linked to? Or are you suggesting that users should be required to download, compile, and install an unstable development version of Gecko--"fixed in CVS"--in order to get something Safari supports out of the box? That's utterly retarded.

I wonder if you're aware how glib your pooh-poohing is of the opacity: and text-shadow: properties. As I said, opacity at the very least would allow authors to finally do away with 1990s-era workarounds like serving redundant PNGs based on browser sniffing. It's very unimaginative of you to maintain that these properties are useless. Don't even get me started on your inane recommendation to use -moz-inline-block as a buggy, unpredictable workaround for inline-block. This is perhaps Gecko's most glaring shortcoming (in a sea of glaring shortcomings).

Finally, I'm not sure what your point is about "they have, after all, made the tools available to help." Perhaps it has escaped your noticed that WebKit is open source. Besides, why would I want to join a team as demonstrably tasteless and unconcerned for comprehensive aesthetics of design as the Firefox development project?

That screenshot is of a development branch, not the latest stable release. It's the same as if I pointed out that the WebKit nightly includes better support for namespaces and SVG--good news, certainly, but not yet very relevant.

as well as Safari as soon as it gets SVG.

Just so you know, it's in the nightlies.

Since you don't know how to google, you can download the source like this:
svn checkout svn://anonsvn.opensource.apple.com/svn/webkit/trun k WebKit

you can also grab the latest nightly build of Safari here: http://nightly.webkit.org/
(look at the icon and download it if you don't believe me)

http://webkit.opendarwin.org/ has more info.

Ultimately we would like WebKit to be nothing more than the embedding APIs for a given platform and infrastructure/glue code that is needed to tie into a specific platform. All of the remaining logic should move to WebCore.

Or download a nightly build of Safari with SVG (for those who're not afraid of beta).

There is a website full of Safari nightlies for the download. It is sort of a pain to get to, so I recommend bookmarking it or something.

Unfortunately, I tried Safari first and it didn't work for some reason. I guess they aren't far enough along yet.

Calm down! SVG is a standard that will probably appear in the next major version of Safari. It's already in Webkit (available in in the latest nightlies).

What an overstatement. I find it hard to imagine a website where unstyled form buttons would be anything more than a mild annoyance. In fact, I've found Safari's CSS support to be better than Firefox 1.0's (inline-block, anyone? absolute positioning inside table cells? etc...); I'm not sure how many of the problems I encountered have been fixed in Firefox 1.5. At any rate, the latest builds of Webkit switch to custom-drawn buttons when you specify styles that are incompatible with the Aqua button.

You can grab nightly builds of Safari here:
http://nightly.webkit.org/builds/

It's still Apple, but they've moved the CVS to a more public area. Aside from one person (Anders Carlsson) everyone working on Safari and WebKit are Apple employees.

SVG is similar: a well-defined standard, with LOTS of potential for the web, but yet Microsoft ignore it. Hell, Mozilla has ignored it, too. It's available for Mozilla as an add-on, but why isn't it IN there now? What about Konqueror and Safari?