Surfin’ Safari

WebKit Excitement at WWDC

Posted by Maciej Stachowiak on Wednesday, May 30th, 2007 at 11:20 pm

For those of you attending the Apple World Wide Developer’s Conference in San Francisco, there will be much WebKit-related excitement. There will be many web technology related presentations, and many informal opportunities to meet WebKit developers from Apple and elsewhere. If you’re at WWDC, make sure to find us and say hi. And watch this space for info about more WebKit-related events at the Developer’s conference.

5 Responses to “WebKit Excitement at WWDC”

  1. kodybryson Says:

    I hope part of it has something to do with color profiles and how photos are displayed in Safari. I would love it if I could get a photo to look the same on a web page as it does in iPhoto without having to understand color theory.

    Of course, how many people post photos on the web? I mean really. [/sarcasm]

  2. Thinine Says:

    Well, since web photo’s rarely ever have color profiles embedded in them, it’s likely they’re being given some default profile they may not have been intended for. You could also give us a link to a sample of what you’re talking about. And please get rid of the stupid broken captcha.

  3. Mark Rowe Says:

    If you leave the embedded colour profile in your photos, then they will display identically in Safari and iPhoto but you will lose the ability to colour-match between colours in the photos and colours specified in your HTML and CSS. If you strip the colour profiles you will be able to colour-match with your HTML and CSS content at the expense of appearing different to the original image. Dave Hyatt wrote a post that mentions WebKit’s position on this a little while ago. The linked article goes into more detail.

  4. kodybryson Says:

    OK, so this _may_ not be a Safari problem, it may be a blogger and smugmug problem.

    Check out this link. The top photo matches iPhoto and the bottom two get progressively worse.

    There have been so many posts about this, one of which was referenced on this blog, and none of them seem to be talking about my issue. Or they are, but they have kind of ridiculous suggestions like changing the gamma setting on my Mac or something. (I tried this, and it didn’t work. All of the images are still different from each other, just differently different.)

    It looks like what literally needs to be done is that these blogger and smugmug should include color profiles in everything but their smallest thumbnails. And it looks like temporarily, the only way to avoid this problem is to export the size I want for the web directly from iPhoto and use imageshack for all my blog photo hosting. That’s such a bummer since I love smugmug, but if people aren’t seeing my photos how I intended then what’s the point? The thing is, smugmug claims that this difference does not exist on PCs (I think) so if that’s the case, then maybe it is a Safari problem. The Safari team claims there’s nothing they can do about it, so then how come nobody’s complaining about IE on Windows (with respect tot his issue only, of course)?

    If there is a way, even via an optional property, to make the second and/or third images look as good as the first, that would be great.

  5. Mark Rowe Says:

    I posted some details about how I believe the colour profiles relate to each image in the comments of the blog post you linked to. I believe that the difference between in appearance Safari and Internet Explorer is that Safari will respect an embedded colour profile if it is present, while Internet Explorer will not. The idea behind this is that if you have an embedded colour profile in your image you intend for it to affect how it is displayed to users — ignoring the profile would not give an accurate representation of the colours in the image. The only area in which this typically causes problems is, as I mentioned in my previous comment, when attempting to colour-match between your image and CSS/HTML. In my opinion Internet Explorer not honouring colour profiles when Safari does would more correctly be considered an IE bug than a Safari bug.