Below are some useful links for doing web development for Safari.
Links for Limited Safari Technical Documentation
http://developer.apple.com/internet/safari/safari_css.html - This is a good quick reference. Do not assume this list is the complete listing, for it is not. It dates back to around 2004 and has not been updated. To get the full supported list try the following link.
http://developer.apple.com/documentation/AppleApplications/ Reference/SafariCSSRef/Articles/StandardCSSProperties.html# //apple_ref/doc/uid/TP30001266-SW1 - This is the full supported listing of all CSS properties. Not sure when this was published, but it is more recent than the above link. There is also the CSS Extensions that are included in Safari: see the next link.
http://developer.apple.com/documentation/AppleApplications/ Reference/SafariCSSRef/Articles/CSSExtensions.html# //apple_ref/doc/uid/TP30001265-SW1 - These are the CSS Extensions. All two of them! ;-) Try clicking on the link “show TOC” for more information from Apple.
Miscellaneous Links
http://builder.com.com/5100-6371-1050180.html#Listing%20F - An alternative solution to dealing with different media types. Using the @media in your style sheets.
http://developer.mozilla.org/en/docs/Images%2C_Tables%2C_and_Mysterious_Gaps - Gaps around images
Links from Apple
http://developer.apple.com/internet/safari/index.html - Apple’s Developer Domain’s Safari support page
http://developer.apple.com/internet/safari/safari_css.html - CCS reference for Safari. Out of date, but useful for those elements that are on the list.
http://developer.apple.com/internet/safari/uamatrix.html - Mac OS, Safari, and WebKit version matrix.
NOTE: WebKit is also the engine that drives not only Safari, but also the Mac’s Dashboard, Mail, and many other applications. This website may contain all of the updated documentation that I have been looking for. Actually not, it is mostly driven to developmental focus of the WebKit itself.
http://www.ecma-international.org/publications/standards/Ecma-262.htm - The JavaScript standard that Safari (WebKit) is based upon.
CSS Related Links
http://meyerweb.com/eric/css/edge/ - CSS Edge
http://www.quirksmode.org/viewport/compatibility.html - Screen dimensions
http://www.quirksmode.org/dom/innerhtml.html - Benchmark - w3c DOM vs. innerHTML
JavaScript Related Links
http://webkit.opendarwin.org/blog/ - Has some information on JavaScript.
http://www.alexking.org/blog/2004/03/01/mac-browser-javascript-performance/ - Has comments about browser performance. John Strung comments that turning off all languages other than English (or One) "can significantly speed up Safari". He is ASKING if anyone has tried this, so mark this down as RUMOR.
http://www.codehouse.com/javascript/tips/random_letter/ - Creating random characters
http://www.quirksmode.org/css/overflow.html
Quirksmode CCS - Contains some interesting aspects to CSS
Quirksmode CCS - Not For N4 CCS
Quirksmode CCS - Tables CCS
Quirksmode CCS - JavaScript
http://www.javascriptkit.com/jsref/regexp.shtml - JavaScript Reference
Table Related Links
http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#edef-TD - Information on how percents are only a hint
http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.5 - Table information
http://www.quirksmode.org/viewport/compatibility.html - Idea for adjusting width was found here.
http://www.workingwith.me.uk/articles/scripting/standardista_table_sorting - Table sorting
http://sourceforge.net/project/showfiles.php?group_id=162528 - Download for STS
HTML Links
http://www.w3.org/TR/1999/REC-html401-19991224/cover.html#minitoc - HTML v4.1 DOM specs
http://developer.apple.com/documentation/Cocoa/Conceptual/WebKit_DOM/index.html# //apple_ref/doc/uid/TP40001242 - DOM level 2 Specs
DOCTYPE Links
http://alistapart.com/stories/doctype/ - Good and informative, but note that it was written in 2002! Double check the current standards before using.
http://www.w3.org/QA/2002/04/valid-dtd-list.html - A detailed listing, but does not explain each usage.
http://www.w3.org/TR/html401/struct/global.html - Global Structure on an HTML document. Covers the DOCTYPE. Good information and a few more links.
http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/doctype.asp - MS’s perspective on DOCTYPE and IE v6.x.
http://msdn.microsoft.com/library/default.asp? url=/library/en-us/dnie60/html/cssenhancements.asp - CSS Enhancements for IE v6.x.
- This is also an excellent document that identifies what some (or all) of the differences are between compatibility mode and standard-compliant mode. It should be noted that standards-compliant mode is not measured against the current W3C standards, but the preliminary suggestions.
http://www.htmlhelp.com/reference/html40/html/doctype.html - Has a fairly good description as to the differences between Strict, Transitional, and Frameset. The comment about Quirk mode for IE v6.x is incorrect see the table above for the correct usages of the quirks mode with IE v6.x.
Thursday, October 05, 2006
Performance Related Issues with Safari 2.0.x
There are some obvious performance issues with Safari.
TEXTAREA used in TABLEs
This is very common problem within some corporate application when trying to deal with any aspect of a table that has many TEXTAREA tags. The symptoms are a page that is very slow to load, close, update, and refresh. Assuming there is one TEXTAREA tag per table cell. Depending upon the processor power of the Mac this may occur with as few as 35 columns with 10 rows to about 30 rows before the response time starts to become unacceptable.
These performance issues do not exist if the TEXTAREA is replaced by DIV elements and performance can be increased by a factor of about 1500% by using DIV elements instead!
My guess as to the cause of this that TEXTAREA elements are defined in terms of “rows” and “cols”. These values do NOT directly map back to the W3C standard units of measurements and I suspect that there is a problem in the translation of rows and cols.
It is an incorrect usage of the TEXTAREA element to used for formatting of a table cells or other parts of the HTML document. CSS should be used instead. I suspect it was just easier for some programmers to specify container size in terms of rows and columns.
Large Select Statements
Safari tends to have performance issues when a single select statement may have well over a few thousand entries. An example would be the pick lists for issues such as routing comments.
There is basically nothing that can be done for these situations except for perhaps reducing the number of entries in the list, which may not be appropriate. Businesses should be more aware of the nature of the user interface than to expect the user to literally scroll through thousands of entries in a list.
Some Links
http://www.w3.org/TR/html4/interact/forms.html#h-17.7 - TEXTAREA as defined by the HTML v4.1 standards
TEXTAREA used in TABLEs
This is very common problem within some corporate application when trying to deal with any aspect of a table that has many TEXTAREA tags. The symptoms are a page that is very slow to load, close, update, and refresh. Assuming there is one TEXTAREA tag per table cell. Depending upon the processor power of the Mac this may occur with as few as 35 columns with 10 rows to about 30 rows before the response time starts to become unacceptable.
These performance issues do not exist if the TEXTAREA is replaced by DIV elements and performance can be increased by a factor of about 1500% by using DIV elements instead!
My guess as to the cause of this that TEXTAREA elements are defined in terms of “rows” and “cols”. These values do NOT directly map back to the W3C standard units of measurements and I suspect that there is a problem in the translation of rows and cols.
It is an incorrect usage of the TEXTAREA element to used for formatting of a table cells or other parts of the HTML document. CSS should be used instead. I suspect it was just easier for some programmers to specify container size in terms of rows and columns.
Large Select Statements
Safari tends to have performance issues when a single select statement may have well over a few thousand entries. An example would be the pick lists for issues such as routing comments.
There is basically nothing that can be done for these situations except for perhaps reducing the number of entries in the list, which may not be appropriate. Businesses should be more aware of the nature of the user interface than to expect the user to literally scroll through thousands of entries in a list.
Some Links
http://www.w3.org/TR/html4/interact/forms.html#h-17.7 - TEXTAREA as defined by the HTML v4.1 standards
What Browser Platform Should be Used For Development?
The question as to what browser platform should be used for developing a web application is a good question to ask. In the past the answer has been: What is the most popular? What will support the features? What will be around in the next 3 years? What are our developers already familiar with?
In the past, if the development was to be kept simple only one browser would be chosen for the target audience. That has been IE in most circumstances.
With today’s emphasis on standards, the answer may not be a specific browser, but more so a given standard. With the current market shares being held by IE at 84.7%, Firefox at 10.05%, and Safari at 3.19% is a total of 97.94%. Assume that most IE users will upgrade to v7.x within the first year of release, and you have a profound percent of the population using a W3C standard compliant browser! So the answer is not what browser you should develop for, but instead what standard.
The second question is, to what browser’s implementation of the standard should you develop for? Why? Because not all browsers will be able to implement 100% of the standard at the same time. Once again, the answer should not be a specific browser as the target, but instead, what features of the standards are supported by the most browsers should be the question.
The goal is to make your application more compliant with what the masses are using. The best way to achieve that is though generalization of what browsers have currently implemented. I am sure that when IE v7.x starts to hit the market you will be able to find more resources comparing the low level components of the standards to all browsers. It should be easier to find out what has been well implemented and what may be best to avoid.
This philosophy may make the most sense with new development. It may be difficult to provide an incremental set of changes to an existing application to comply with the new standard, especially if the support of these new standards are being turned on through the DOCTYPE, which is an all or nothing situation in the use of the new standards.
In the past, if the development was to be kept simple only one browser would be chosen for the target audience. That has been IE in most circumstances.
With today’s emphasis on standards, the answer may not be a specific browser, but more so a given standard. With the current market shares being held by IE at 84.7%, Firefox at 10.05%, and Safari at 3.19% is a total of 97.94%. Assume that most IE users will upgrade to v7.x within the first year of release, and you have a profound percent of the population using a W3C standard compliant browser! So the answer is not what browser you should develop for, but instead what standard.
The second question is, to what browser’s implementation of the standard should you develop for? Why? Because not all browsers will be able to implement 100% of the standard at the same time. Once again, the answer should not be a specific browser as the target, but instead, what features of the standards are supported by the most browsers should be the question.
The goal is to make your application more compliant with what the masses are using. The best way to achieve that is though generalization of what browsers have currently implemented. I am sure that when IE v7.x starts to hit the market you will be able to find more resources comparing the low level components of the standards to all browsers. It should be easier to find out what has been well implemented and what may be best to avoid.
This philosophy may make the most sense with new development. It may be difficult to provide an incremental set of changes to an existing application to comply with the new standard, especially if the support of these new standards are being turned on through the DOCTYPE, which is an all or nothing situation in the use of the new standards.
Subscribe to:
Posts (Atom)
