... if there were a Safari v62, and it did happen to leak to the public, and someone did happen to run it, and that person did happen to discover a bug with text-decoration, well then I would hypothetically be most grateful, and would in fact fix such a bug with the utmost expedience. In fact, it might even be fixed already, assuming of course there were such a build, and it did in fact have this problem.
I just watched the trailer for Bulletproof Monk. This movie has got to be the most obvious Matrix ripoff yet. Chow-Yun Fat is playing the role of Morpheus, Seann William Scott is Neo, and Jaime King is Trinity. Shameless.
Some more issues I fixed tonight:
I have integrated the CSS parser from the KHTML trunk into Safari. It uses the CSS2.1 grammar. Mark will no doubt be disappointed that it closes most of the sheet-content-related hacks. In particular, Safari is no longer vulnerable to the Safari Spacer hack, the Simplified Box Model Hack, the Star HTML bug, or the Inline High Pass filter. It is, however, still vulnerable (interestingly) to Fabrice's Inversion.
Note that some of these hacks really couldn't easily be left in, since using a correct grammar will just naturally close these hacks off. There's no way to easily pollute the grammar to support constructs like the Safari Spacer hack (nor should we).
Update: The answers have been revealed.
Ok, it's about that time of the year again. Here's another movie quiz.
An article about how NetNewsWire and Safari complement one another can be found at O'Reilly here.
I agree, although Safari really needs to be able to reuse windows for URLs sent from applications like NetNewsWire rather than always opening a new window every time.
Mike Pinkerton writes in his blog:
When I said we're not soliciting suggestions for new names, I really meant it. Right now Camino has passed the preliminary legal check and they are doing a more in-depth one. Expect resolution sometime next week and the 0.7 release very shortly after.
Doesn't exactly conjure up an image of speed, now, does it? I just think of "El Camino" and imagine something like this.
Not that Chimera was necessarily any better, but Camino just doesn't do it for me.
Boris Zbarsky writes about how he'd like to take a peek at the new inline box model I'm working on in Safari.
Summary of what I do know: KHTML is GPL, while Mozilla is MPL/LGPL/GPL tri-licensed; this means that I can't copy code from KHTML to Mozilla (while copying in reverse is perfectly fine). But the question is what the GPL covers. Is it the ideas (algorithms, approaches, etc)? Or the specific presentation of those ideas in source code form? The latter would mean that recoding the same algorithms in a different language is not a GPL violation, for example....
Actually, KHTML is LGPL, but other than that, you're right. Safari can take code from Mozilla and license it under the LGPL, but Mozilla cannot take code from KHTML.
I find it really strange that Mozilla's tri-license has created this situation. On the one hand, it encourages people to build applications using Mozilla code under the GPL, LGPL, or MPL, but at the same time it makes it impossible for anyone to really give the code back to Mozilla itself if that code doesn't use the MPL.
Safari already contains Gecko code. In particular the doctype sniffing code now exactly matches Mozilla, and the new inline box model actually has the same "Almost Standards" mode that Gecko does (although the new box model code is entirely unique).
The layer system in Safari (for dealing with positioning and clipping) is inspired by Gecko's view system (greatly simpified). You can even see Mozilla contributors in the Safari acknowledgments if you go looking for them.
Finally, Safari uses the NSPR arena code from Gecko and supports the same kind of recycling arena allocation on its RenderObjects (and many of the temporary objects they create).
Watch for more liberal borrowing of code, especially code that I wrote originally for Gecko (like the aforementioned arena code). I will eventually be implementing the rule tree in KHTML that I implemented in Gecko for reducing style footprint and speeding up style resolution (with a few extra goodies/cool capabilities that don't exist in Gecko's rule tree).
Anyway, I think an exchange of ideas is healthy, and I don't think you should be afraid to look at the Safari source code, Boris. In the end each engine benefits from examining the architecture of the other.
Zeldman writes about a mysterious background image problem that plagued his blog in Safari. I wrote up simple test cases and couldn't reproduce the problem. Yo, Zeldman, any chance you could place a reduced test case on your site somewhere so I can debug the problem and fix it?
Brad Choate complains about Safari's handling of backgrounds on inlines in this blog entry. Don't worry, Brad, the new inline box model (post-v60) handles your links perfectly . It even works when the links wrap to multiple lines.
I also got your fancy title tips to work. The transparency effect even works in Safari (how the heck are you accomplishing this?!). In case you want to work around the problem now, you just need to move the hookup of the of the makeNiceTitles event listener (the load handler on the window) to after the body element has been declared (i.e., put it in your body).
If you don't want to pollute the body of your document with a script in order to fix this now, you can wait for a subsequent release of Safari (which will contain the fix).
How did you accomplish that transparency effect without using -moz-opacity? I'm amazed this works in Safari! :)
[Update: Duh, PNGs. I get it.]
I see a lot of people blogging about XML support. Basically XML support breaks down into two camps: the IE camp and the Netscape camp. In Internet Explorer, when you load an XML file, you get a tree view of the document tree. This is ideal for unstyled documents, where you essentially just want to view the source. In Netscape 7, when you load an XML file, it is rendered as though the document has been styled. If you don't specify a stylesheet, everything will just run together, since the elements will be treated as though they're display: inline by default.
The latter (XML+CSS) is what we have implemented in KHTML. Ideally we will move to what Mozilla supports, which is to dynamically show a tree view when no stylesheets are present, but to render a styled document when stylesheets are present.
In the meantime, if you want to see the source of an XML document, just load it in the browser and then select View Source.
I've begun writing some documentation on WebCore, so that people interested in contributing patches to WebCore can start learning how KHTML and KWQ work. You can find rough drafts of what I've written so far here.
So go download it! v60 has most of the stuff in it that I've been babbling about in previous blog entries. What it does not have: the fixed :before/:after handling or the new inline box model (which is really sweet and fixes a whole slew of bugs).
[Note:: The opinions expressed in this blog entry are purely my own. Take them with the appropriate grain of salt.]
John Gruber has an excellent blog up about Opera's potential withdrawal from the Mac platform.
My earlier blog entry on the subject was a little more concise, consisting of... well, a one word response: "Wah."
Opera is playing the same game that Netscape played in the 4.x days. They call themselves "cross-platform", but what that really means is that they have a solid Windows offering, and then straggling offerings on other platforms.
Did Opera expect some sort of prize just for showing up? Any Mac user could tell you that just showing up is not enough. Nobody wants an afterthought for a browser, or a second-rate knockoff of your shining Windows star.
Being pissed I can understand. Fine, be pissed. But the way their CEO went on the record with news.com and directly insulted KHTML, calling it a "simple little browser," was really unprofessional. It was an insult to all the people who have worked on KHTML over the years (via Apple or KDE, on Safari or Konqueror).
(You'd think the CEO of Opera would be able to distinguish between a browser and a rendering engine, but ok, given his other comments, maybe not.)
mpt writes about my little experiment.
The real reason I caved and started using my blog as a GUI feedback zone was to try to stop people from emailing me, and it has worked.
Ever since the experiment went into effect I have only received one piece of email about Safari's GUI. Thank you, readers, for being good citizens and sticking to Trackback and Comments. Besides, this way the whole community can see your GUI feedback and respond, unlike email, which goes only to me.
To the one person who sent me email anyway, I am watching you.
[Update: The entire 800 comment page has been forwarded to the whole Safari team. Thanks again for the feedback.]
I just finished slogging through all 750 comments (and 36 trackbacks). Really great feedback. Given the bandwidth limitations, I've had to disable the comment posting.
I will continue to read Trackbacks for more GUI feedback, so if you have a blog of your own, you can give feedback that way by using Trackback on this entry.
Ok, so let's try an experiment. If you want to give me GUI feedback on Safari, post a comment or a trackback in response to this blog entry. I will read the comments and follow all trackbacks for information about what changes/additions you'd most like to see in Safari. If you have a non-GUI request, e.g., some specific CSS flaw or DOM flaw that you feel should be really high priority, you can post here too.
We've disabled comments for now, as it was driving our bandwidth use through the roof. -Admin
Please do not send me email (or post comments to this blog) asking if/when UI features are going to be implemented.
Also please stop asking me about release dates, when the next release of Safari will be, if there will be nightly builds, what the plans are for builds, etc. etc.
Some of the things I've been tinkering with in WebCore recently: