php-horde-feed 2.0.1-4 / usr / share / php / tests / Horde_Feed / Horde / Feed / fixtures / lexicon / http-weblogs.mozillazine.org-hyatt-blogger_rss.xml

<?xml version="1.0" encoding="iso-8859-1"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns="http://purl.org/rss/1.0/">

<channel rdf:about="http://weblogs.mozillazine.org/hyatt/">
<title>Surfin&apos; Safari</title>
<link>http://weblogs.mozillazine.org/hyatt/</link>
<description>Dave Hyatt&apos;s Weblog</description>
<dc:language>en-us</dc:language>
<dc:creator></dc:creator>
<dc:date>2005-06-30T11:37:29-08:00</dc:date>
<admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=3.32" />

<items>
<rdf:Seq>
<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008424" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008321" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008285" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008281" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_05.html#007507" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008011" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007977" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007981" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007980" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007973" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007962" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007958" />

<rdf:li rdf:resource="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007956" />
</rdf:Seq>
</items>

</channel>


<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008424">
<title>Moving Time</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008424</link>
<description><![CDATA[<p>Now that WebKit has its own web site on OpenDarwin, it's time for this blog to change.  For starters, Surfin' Safari has now moved to <a href="http://webkit.opendarwin.org/blog/">here</a>.  Another big change is that I will no longer be the only person talking to you about Safari and WebKit changes.  Some of the other members of the team will be posting about what they're working on as well.</p>

<p>I will leave this blog up here so that all the links remain valid, but all subsequent posts will be to the new blog.  Update your bookmarks. :)<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-06-30T11:37:29-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008321">
<title>Nokia Uses WebCore</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008321</link>
<description><![CDATA[<p><a href="http://press.nokia.com/PR/200506/998214_5.html">Nokia uses WebCore in a new mobile browser for the Series 60 platform.</a></p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-06-13T00:50:14-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008285">
<title>The Improved Web Kit</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008285</link>
<description><![CDATA[<p>We've already received and committed several patches from external contributors and the repository has only been live for a few hours!</p>

<p>As some of you have already noticed (those of you that built), the new Web Kit not only passes Acid2, but it's also substantially faster at loading Web pages and at handling JavaScript.  It contains a number of additional performance improvements that went in post-Tiger.</p>

<p>One question people have asked is "Does this have to replace my system frameworks?" The answer is "No."  You can run this custom version of Web Kit with a particular instance of Safari without replacing your system frameworks.  The <tt>run-safari</tt> script we provided does this for you.  If you study what it does, you'll see that you can easily try out your own WebKit apps with the new frameworks as well.  We in fact encourage you to do this so that you can make sure your apps are functioning properly with the latest WebKit.<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-06-07T10:10:08-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008281">
<title>Say Hello to WebKit!</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_06.html#008281</link>
<description><![CDATA[<p>As some of you may have heard at WWDC Monday, the Safari team is proud to announce that we are making significant changes in the way we operate, and these changes start today.</p>

<p>Here is what we are launching:</p>

<p>1. <A href="http://webkit.opendarwin.org/">webkit.opendarwin.org</a>, the new web site for WebKit, WebCore and JavaScriptCore.<br />
2. Full CVS access to WebCore and JavaScriptCore, our frameworks based on khtml and kjs.  This repository includes the complete history of the project, so all patches past and present can be viewed.<br />
3. WebKit, the Objective-C API that wraps WebCore, is also being open sourced.  It is in the same CVS repository.<br />
4. This repository is live.  You can pull and build it today.  As we improve the frameworks you can pull and run the latest and greatest.  If you want to run a version of Safari that passes the Acid2 test, now you can.<br />
5. This repository is open.  We welcome contributions.<br />
6. From now on bugs in these frameworks will be tracked in public at <a href="http://bugzilla.opendarwin.org">bugzilla.opendarwin.org</a>.   You can submit bugs in the open, view the status of our work, attach patches to bugs, and test code fixes to those bugs.<br />
7. A new public mailing list, <A href="mailto:webkit-dev@opendarwin.org">webkit-dev@opendarwin.org</a>, for development discussion of WebKit, WebCore, and JavaScriptCore.<br />
8. A new public IRC channel - <tt>#webkit</tt> on <tt>irc.freenode.net</tt>.</p>

<p>And finally, going forward we will be engaging actively with the community.  Find us on IRC and on the mailing list, jump in, and get involved!</p>

<p>Build. Run. Test. It's live!<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-06-07T00:00:58-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_05.html#007507">
<title>Implementing CSS (Part 1)</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_05.html#007507</link>
<description><![CDATA[<p>One of the most interesting problems (to me at least) in browser layout engines is how to implement a style system that can determine the style information for elements on a page efficiently.  I worked on this extensively in the Gecko layout engine during my time at AOL and I've also done a lot of work on it for WebCore at Apple.  My ideal implementation would actually be a hybrid of the two systems, since some of the optimizations I've done exist only in one engine or the other.</p>

<p>When dealing with style information like font size or text color, you have both the concept of back end information, what was specified in the style rule, and the concept of front end information, the computed result that you'll actually use when rendering.  The interesting problem is how to compute this front end information for a given element efficiently.</p>

<p>Back end information can be specified in two different ways.  It can either be specified using CSS syntax, whether in a stylesheet or in an inline style attribute on the element itself, or it is implicitly present because another attribute on the element specified presentational information.  An example of such an attribute would be the <i>color</i> attribute on the <i>font</i> tag.  Both WebCore and Gecko use the term <i>mapped attribute</i> to describe an attribute whose value (or even mere presence) maps to some implicit style declaration.</p>

<p>A <i>rule</i> in CSS consists of two pieces.  There is the <i>selector</i>, that bit of information that says under what conditions the rule should match a given element, and there is the <i>declaration</i>, a list of property/value pairs that should be applied to the element should the selector be matched.  </p>

<p>All back end information can ultimately be thought of as supplying a declaration.  A normal rule in a stylesheet that is matched has the declaration specified as part of the rule.  An inline style attribute on an element has no selector and is simply a declaration that always applies to that element.  Similarly each individual mapped attribute (like the <i>color</i> and <i>face</i> attributes on the <i>font</i> tag) can be thought of as supplying a declaration as well.</p>

<p>Therefore the process of computing the style information for an element can be broken down into two phases.  The first phase is to determine what set of declarations apply to an element.  Once that back end information has been determined, the second phase is to take that back end information and quickly determine the information that should be used when rendering.</p>

<p>WebCore (in upcoming Safari releases) has a really cool optimization that I came up with to avoid even having to compute the set of declarations that apply to an element.  This optimization in practice results in not even having to match style for about 60% of the elements on your page.</p>

<p>The idea behind the optimization is to recognize when two elements in a page are going to have the same style through DOM (and other state) inspection and to simply share the front end style information between those two elements whenever possible.</p>

<p>There are a number of conditions that must be met in order for this sharing to be possible:<br />
(1) The elements must be in the same mouse state (e.g., one can't be in :hover while the other isn't)<br />
(2) Neither element should have an id<br />
(3) The tag names should match<br />
(4) The class attributes should match<br />
(5) The set of mapped attributes must be identical<br />
(6) The link states must match<br />
(7) The focus states must match<br />
(8) Neither element should be affected by attribute selectors, where affected is defined as having any selector match that uses an attribute selector in any position within the selector at all<br />
(9) There must be no inline style attribute on the elements<br />
(10) There must be no sibling selectors in use at all.  WebCore simply throws a global switch when any sibling selector is encountered and disables style sharing for the entire document when they are present.  This includes the + selector and selectors like :first-child and :last-child.</p>

<p>The algorithm to locate a shared style then goes something like this.  You walk through your previous siblings and for each one see if the above 10 conditions are met.  If you find a match, then simply share your style information with the other element.  Such a system obviously assumes a reference counting model for your front end style information.</p>

<p>Where this optimization kicks into high gear, however, is that it doesn't have to give up if no siblings can be located.  Because the detection of identical style contexts is essentially O(1), nothing more than a straight pointer comparison, you can easily look for <i>cousins</i> of your element and still share style with those elements.</p>

<p>The way this works is that if you can't locate a sibling, you can go up to a parent element and attempt to find a sibling or cousin of the parent element that has the same style pointer.  If you find such an element, you can then drill back down into its children and attempt to find a match.</p>

<p>This means that for HTML like the following:</p>

<p>&lt;table&gt;<br />
&lt;tr class='row'&gt;<br />
&lt;td class='cell' width=300 nowrap&gt;Cell One&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;tr class='row'&gt;<br />
&lt;td class='cell' width=300 nowrap&gt;Cell Two&lt;/td&gt;<br />
&lt;/tr&gt;</p>

<p>In the above example, not only do the two rows share the same style information, but the two cells do as well.  This optimization works extremely well for both old-school HTML (in which many deprecated presentational tags are used) and newer HTML (in which class attributes might figure more prominently).</p>

<p>Once the engine determines that a style can't be shared, i.e., that no pre-existing front end style pointer is available, then it's time to figure out the set of declarations that match a given element. It is obvious that for inline style attributes and mapped attributes that you can find the corresponding declaration quickly.  The inline style declaration can be owned by the element, and the mapped attributes can be kept in a document-level hash.  WebCore has a bit of an edge over Gecko here in that it treats each individual mapped attribute on an element as a separate declaration, whereas Gecko hashes all of the mapped attributes on an element as a single "rule."  This means that Gecko will not be able to share the mapped attribute declaration for the following two elements:</p>

<p>&lt;img width=300 border=0&gt;<br />
&lt;img width=500 border=0&gt;</p>

<p>WebCore creates three unique declarations and hashes them, one for a width of 300, one for a width of 500, and one for a border of 0.  Gecko creates two different "rules," one for (width=300,border=0) and another for (width=500,border=0).  As you can see in such a system, you will frequently not be able to treat the identical border attributes as the same.</p>

<p>Aside from this difference in mapped attribute handling, the two engines employ a similar optimization for quickly determining matching stylesheet rules called <i>rule filtering</i>.  All rules that are potentially matchable by any element (i.e., that have the correct media type) are hashed based on the contents of the rightmost simple selector in the rule.</p>

<p>A selector in CSS can be either simple (meaning that all of the contents of that selector apply only to a single element) or compound (meaning that you may examine multiple elements like parents or siblings of that element).  A compound selector is essentially a chain of simple selectors, so the following rule:</p>

<p>tr > td { color: blue }</p>

<p>has two simple selectors, <tt>tr</tt> and <tt>td</tt>.  The rightmost simple selector in the rule is the one that we will use for the rule filtering optimization.</p>

<p>The rightmost simple selector falls into four categories.</p>

<p>(1) The selector uses an ID.  (Example: #foo)<br />
(2) The selector doesn't have an ID but uses a class.  (Example: .foo)<br />
(3) The selector has no class or ID but specifies a tag name.  (Example: div)<br />
(4) The selector specifies none of these things.  (Example: *[disabled])</p>

<p>The rule is placed into one of four hashtables depending on which category it falls into.  The idea behind these categorizations is to always filter out more specific information first.  For example, if an element has a specific ID, then obviously any rules whose rightmost selector uses a different ID cannot match.  Technically the last category can just be a list and not a hashtable, since those rules must always be examined by all elements.</p>

<p>Each hashtable, therefore, consists of a mapping from a given atomic string to a set of rules that match.  The class attribute is exceptional in that you must put the rule into the hashtable multiple times if multiple class attributes are used.</p>

<p>When determining the set of rules that match a given element, you only examine rules that correspond to the correct hash entry based off your ID, classes and tag name.  This optimization basically eliminates 95+% of the rules up front so that they need not even be considered during the matching process.</p>

<p>Each rule is then examined in detail, with all selectors being checked, to determine if it is a match, and the set of matches is collected.  The set of matches can then be sorted by priority and specificity such that all the declarations are in the proper application order.</p>

<p>This brings us to the final phase of the style computation, which is taking the set of matches and quickly computing the appropriate front end style information.  It is here that Gecko really shines.  What I implemented in Gecko was a data structure called the <i>rule tree</i> for efficient storing of cached style information that can be shared *even when* two elements are not necessarily the same.</p>

<p>The idea behind the rule tree is as follows.  You can think of the universe of possible rules in your document as an alphabet and the set of rules that are matched by an element as a given input word.  For example, imagine that you had 26 rules in a stylesheet and you labeled them A-Z.  One element might match three rules in the sheet, thus forming the input word "C-A-T" or another might form the input word "D-O-G."</p>

<p>There are several important observations one can make once you formulate the problem this way.  The first is that words that are prefixes of a larger word will end up applying the same set of rules.  All additional letters in the word do is result in the application of more declarations.  Thus the rule tree is effectively a lexicographic tree of nodes, with each node in a tree being created lazily as you walk the tree spelling out a given word.</p>

<p>This system allows you to cache style information at each node in the tree.  This means that once you've looked up the word "C-A-T-E-R-W-A-U-L", and cached information at all of the nodes, then looking up the word "C-A-T" becomes more efficient.</p>

<p>In order to make the caching efficient, properties can be grouped into categories, with the primary criterion for categorization being whether the property inherits by default.  It's also important to group properties together that would logically be specified together, so that when a fault occurs and you have to make a copy of a given struct, you do so knowing that the other values in the struct were probably going to be different anyway.</p>

<p>Once you have the properties grouped into categories like the border struct or the background struct, then you can either store these structs in the rule tree or as part of a style tree that more or less matches the structure of the document.  Inheritance has to apply down the style tree and tends to force a fault, whereas non-inherited properties can usually be cached in the rule tree for easy access.</p>

<p>WebCore doesn't contain a rule tree, but it is smart enough to refcount the structs and share them as long as no properties have been set in the struct.  In practice this works pretty well but is not as ideal as the rule tree solution.</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-05-02T14:57:16-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054">
<title>Safari and KHTML</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008054</link>
<description><![CDATA[<p>KHTML developers respond to my posting of the WebCore Acid2 patches <a href="http://www.kdedevelopers.org/node/view/1001">here</a> and <a href="http://www.kdedevelopers.org/node/view/1006">here</a>.  </p>

<p>For what it's worth, the patches I posted are to <i>WebCore</i>, which consists of both KHTML and KWQ (our port of Qt).  They are posted to illustrate all the WebCore bugs that had to be fixed in Safari to pass the Acid2 test.  They are not solely KHTML patches.  The antialiasing bug was in KWQ, and so doesn't even apply to KHTML.  The better object element support necessarily involves KWQ as well, since the plugin code is (obviously) platform-specific.</p>

<p>What do you think Apple could be doing better here? Comment or trackback. I'll read it all.<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-30T21:26:28-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042">
<title>Safari Passes the Acid2 Test (Updated)</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042</link>
<description><![CDATA[<p><img alt="acid-victory.png" src="http://weblogs.mozillazine.org/hyatt/images/acid-victory2.png" width="196" height="240" align=left style="border:3px solid black; margin: 0 5px"/> Safari now passes the Acid2 test.  There were two issues left that needed to be resolved.</p>

<p>The first issue involved implementing a few enhancements to the object element.  I needed to support fallback content when invalid MIME types were specified or when bad status codes were returned for HTTP requests (like 404).  After fixing these bugs and a couple of other problems with intrinsic sizing of plugins, the eyes of the face showed up.</p>

<p>The second issue involved improper antialiasing of the border corners.  Antialiasing was enabled for the drawing of the corner polygons, and this resulted in a bleed-through of the background.  Because the two corners were drawn separately, the antialiasing was actually incorrect, since it was disrupting the join of the corners by letting the background show.</p>

<p>Here are the patches for all of the problems fixed in Safari to make the test pass.</p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid.txt">Fix parsing of the REL attribute on links.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid2.txt">Disallow TABLE inside P in strict mode.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid3.txt">Add support for min/max-width/height for positioned elements.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid4.txt">Fix the rendering glitch that causes the reference page to paint garbage.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid5.txt">Make sure that percentages that go to auto don't mess up the self-collapsing block check.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid6.txt">Implement SGML-style comment parsing for HTML in strict mode.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid7.txt">Make sure empty tables honor CSS-specified height in strict mode.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid8.txt">Fix baseline alignment within table cells to use the bottom of empty blocks.  Fix floats to not grow if child floats overhang but the height of the outer float is auto.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid9.txt">Make sure percentage min-height goes to 0 and not auto when the percentage does not apply.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid10.txt">Implement fallback content for the object element and fix intrinsic sizing to work properly when images are specified in the object element.</a></p>

<p><a href="http://weblogs.mozillazine.org/hyatt/acid11.txt">Disable antialiasing for the drawing of polygons.</a></p>

<p>Victory!<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-27T22:25:24-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008011">
<title>Acid2: Version 1.1 Posted</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008011</link>
<description><![CDATA[<p>The Acid2 test has been updated to version 1.1 in order to fix the bug I outlined in my previous blog entry.  Here is how the Safari build with all of my fixes renders version 1.1.   As you can see now we're just down to better object element handling.</p>

<p><img alt="acid2-6.png" src="http://weblogs.mozillazine.org/hyatt/images/acid2-6.png" width="339" height="244" /><br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-23T02:47:07-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007977">
<title>Acid2: Lopping Off the Sideburns</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007977</link>
<description><![CDATA[<p>Astute viewers pointed out that there was still a rendering glitch in row ten.  It turns out this was actually a problem with rows six to nine.  The block above ended up being too tall because min-height specified using a percentage was resolving to auto instead of to 0 when the containing block had no specified height.  I fixed this problem, but check out the rendering now.</p>

<p><img alt="acid2-5.png" src="http://weblogs.mozillazine.org/hyatt/images/acid2-5.png/acid2-5.png" width="345" height="242" /></p>

<p>Observe how the smile is now positioned too high relative to the reference rendering.  I spent a very long time investigating this problem and determined that it is in fact a bug in the test.  At this point I am halting work on Acid2 until a revised test has been posted.<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-20T21:06:35-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007981">
<title>Regression Roundup</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007981</link>
<description><![CDATA[<p>The purpose of this blog entry is for you to track back to it with regressions you have discovered going from 1.2 to 1.3.  It would be especially helpful if you can test up front for whether this is a user agent bug (by spoofing as another browser), since changes in browser version numbers often cause regressions even when nothing is wrong with the browser itself.</p>

<p>The more clear and concise the reduction, the better the chances are that we can address the issue quickly (thus increasing the odds it can make it into a software update sooner rather than later).</p>

<p>Please include in these trackbacks only regressions from 1.2.  If you included something in the earlier blog entry's comments section, please post it again as a trackback.  Thanks!<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-18T23:19:25-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007980">
<title>Response to Some 1.3 Comments</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007980</link>
<description><![CDATA[<p>(1) The feed URL dialog that tells you 10.4 must be installed to view RSS feeds is simply a bug and not part of a master plan for global domination.<br />
(2) The View Source shortcut was changed to match Mail.app.<br />
(3) The default bookmarks reappearing after being removed won't happen going forward now that the way this is handled has been changed.  See (1) above re: global domination.<br />
(4) The selection extends to the edges of lines in the new Safari just as it does in other Mac apps like TextEdit.  This change had to be made so that editing selection would behave like NSTextView.  It was a challenge translating this to the Web space, but I will blog more about this in a future entry.<br />
(5) When saving links to the desktop from the context menu, you can hold down <i>Option</i> to change the menu item so that you can pick a location.</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-18T23:10:37-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007973">
<title>The Acid2 Test: The Smile and Row Fourteen</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007973</link>
<description><![CDATA[<p>Even though I consider row 14 to be ambiguous, I went ahead and modified the Safari code to yield the correct expected behavior.  It isn't so much that the test is wrong as that it is testing unspecified behavior.</p>

<p>I also noticed thanks to Ian Hickson that the smile was not in fact rendering correctly.  The reason is that Safari will expand floats to encompass overhanging child floats even when the outer float has specified a height explicitly in CSS.  I changed the code so that this is now only done when height is auto, and the smile now renders as it should.</p>

<p>Updated screenshot below.  All that I have left is fixing the <i>object</i> element's behavior in order to completely pass the test.</p>

<p><img alt="acid2-4.png" src="http://weblogs.mozillazine.org/hyatt/images/acid2-4.png/acid2-4.png" width="342" height="261" /><br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-18T04:08:13-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007962">
<title>Safari 1.3</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007962</link>
<description><![CDATA[<p>Those of you running Panther can now update to 10.3.9.  This update includes Safari 1.3 and new versions of WebKit, WebCore, and JavaScriptCore that contain thousands of improvements we've made to the engine since Safari 1.2.</p>

<p>What you are getting is all of the new standards support, new WebKit capabilites, site compatibility fixes and performance optimizations that are also present in Safari 2.0 for Tiger.  The layout engines for the two are virtually identical.</p>

<p>Here are some of the highlights:</p>

<p><b>Page Load Performance</b><br />
Safari 1.3 loads pages overall 35% faster than 1.2 as measured by IBench.  In addition to improving the overall page load, Safari 1.3 will display content sooner than 1.2 did, so that subresources don't hold up the initial display of the page.</p>

<p><b>JavaScript Performance</b><br />
We have substantially improved the performance of the JavaScript engine in Safari.  I encourage you to check out Safari 1.3 on <a href="http://www.24fun.com/downloadcenter/benchjs/benchjs.html">this benchmark</a> for example to see the improvement relative to 1.2.</p>

<p><b>HTML Editing</b><br />
Safari 1.3 supports HTML editing, both at the Objective-C WebKit API level and using <i>contenteditable</i> and <i>designMode</i> in a Web page.  The new Mail app in Tiger uses WebKit for message composition.  You can write apps that make use of WebKit's editing technology and deploy them on Panther and Tiger.</p>

<p><b>Compatibility and Security</b><br />
Compatibility and security are our number one priority in WebCore, and Safari 1.3 has many important compatibility fixes.  For example, percentage heights on blocks, tables and cells now work much better in Safari 1.3.  min/max-width/height support has been added.  More of the table-related CSS properties are now supported.  DOM methods like <i>getComputedStyle</i> are now supported.</p>

<p><b>The DOM Exposed</b><br />
The entire level 2 DOM has been exposed a public API in Objective-C.  This means various holes have been filled in Safari's DOM level 2 support.  In addition to exposing the DOM to Objective-C, the JS objects that wrap DOM objects can also be accessed from Objective-C, allowing you to examine and edit the JS objects themselves to inject properties onto them that can then be accessed from your Web page.</p>

<p><b>XSLT</b><br />
Safari 1.3 on Panther now supports XSLT.  10.3.9 includes libxslt, and Safari uses this excellent library to handle XSLT processing instructions it encounters in Web pages.</p>

<p><b>Plugin Extensions</b><br />
For those of you writing WebKit apps, a new Objective-C WebKit plugin API is supported that lets you put Cocoa widgetry into the Web page more easily.  In addition enhancements to the Netscape Plugin API (made in conjunction with Mozilla Foundation) have been implemented for plugins that require cross-browser compatibility.</p>

<p>Did I mention it's really really fast? :)</p>

<p>In case you're curious about differences between the Tiger and Panther versions of the engine, they mostly have to deal with frameworks that changed underneath WebKit. For example we have new faster image decoders on Tiger (that also handle PNGs correctly), so you'll find that Tiger fixes some of the PNG gamma issues that will still exist on Panther.  In addition the new decoders are incredibly fast and are now run on a separate thread on multi-processor machines on Tiger.</p>

<p>The network layer has also been improved on Tiger, so this may be another source of differences in behavior between the two operating systems.  Overall, however, it's likely that content and applications you develop with WebKit will behave identically on the two operating systems.</p>

<p>Let us know what you think.</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-15T22:35:36-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007958">
<title>Acid2: Row 14</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007958</link>
<description><![CDATA[<p>I believe row 14 is ambiguous and needs to be amended.  Safari makes this row too tall for the same reasons Firefox does.</p>

<p>See https://bugzilla.mozilla.org/show_bug.cgi?id=289480#c14 for more details.<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-15T14:16:09-08:00</dc:date>
</item>

<item rdf:about="http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007956">
<title>Acid2: Rows 6-9 Revisited</title>
<link>http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007956</link>
<description><![CDATA[<p>Earlier I asserted that Safari passed rows 6-9.  Now I'm not so sure.  As someone in the comments pointed out, Safari has a 1px golden ring around the black nose that is not there in the reference rendering.  I will have to figure out what causes this to see if it's a bug in Safari.<br />
</p>]]></description>
<dc:subject>Safari</dc:subject>
<dc:creator>hyatt</dc:creator>
<dc:date>2005-04-15T13:43:16-08:00</dc:date>
</item>


</rdf:RDF>