Veröffentlicht am

HTML E-Mail Programme: Welchen Client benutzen die Anwender?

SitePoint hat im Blog einen leidlich interessanten Artikel zur Aufteilung der E-Mail-Programme auf Anwenderseite veröffentlicht.

»There are lots of reasons for hating HTML Email, but perhaps no#1 on most people’s hit list is having to produce HTML Email to deliver to potentially hundreds of different mail clients and configurations.

Now, clearly it’s completely impractical to test your work on hundreds of mail rigs, but the question is, where do you draw the line? Generic browser usage statistics are reasonably common, but mail clients stats?«

Zur Verwendung haben sie auch eine Tortengrafik eingebunden, allerdings irgendwie unvollständig bezeichnet.

In der Zusammenfassung allerdings schon interessant: Mit zwei Webmailern, nämlich Yahoo! und Hotmail, und dem Desktop-Client MS Outlook, verteilen sich auf nur drei E-Mail-Anwendungen mehr als 81% der Anwender. Andere (allen voran Apple Mail und Gmail mit je 4%) sind eher unter »ferner liefen« zu verbuchen.

(Via SitePoint Blogs.)

Veröffentlicht am

Web Inspector Redesign

Timothy Hatcher writes:

„Web Inspector Redesign: It has been nine months since our last Web Inspector update and we have a lot of cool things to talk about. If you diligently use the Web Inspector in nightly builds, you might have seen some of these improvements, while other subtle changes might have gone unnoticed.

Some of the Web Inspector improvements were contributed by members of the WebKit community. We really want to get the whole community involved with making this the best web development tool available. Remember, most of the Web Inspector is written in HTML, JavaScript, and CSS, so it’s easy to get started making changes and improvements.

Redesigned Interface

First and foremost, the Web Inspector is now sporting a new design that organizes information into task-oriented groups — represented by icons in the toolbar. The toolbar items (Elements, Resources, Scripts, Profiles and Databases) are named after the fundamental items you will work with inside the respective panels.

Console

The Console is now accessible from any panel. Unlike the other panels, the Console is not just used for one task — it might be used while inspecting the DOM, debugging JavaScript or analyzing HTML parse errors. The Console toggle button is found in the status bar, causing it to animate in and out from the bottom of the Web Inspector. The Console can also be toggled by the Escape key.

Error and warning counts are now shown in the bottom right corner of the status bar. Clicking on these will also open the Console.

In addition to the visual changes to the Console, we have also greatly improved usability by adding auto-completion and tab-completion. As you type expressions, property names will automatically be suggested. If there are multiple properties with the same prefix, pressing the Tab key will cycle through them. Pressing the Right arrow key will accept the current suggestion. The current suggestion will also be accepted when pressing the Tab key if there is only one matched property.

Our compatibility with Firebug’s command line and window.console APIs has also been greatly improved by Keishi Hattori (服部慶士), a student at The University of Tokyo (東京大学) who tackled this area as a summer project.

Elements Panel

The Elements panel is largely the same as the previous DOM view — at least visually. Under the hood we have made number of changes and unified everything into one DOM tree.

  • Descend into sub-documents — expanding a frame or object element will show you the DOM tree for the document inside that element.
  • Automatic updates — the DOM tree will update when nodes are added to or removed from the inspected page.
  • Inspect clicked elements — enabling the new inspect mode lets you hover around the page to find a node to inspect. Clicking on a node in the page will focus it in the Elements panel and turn off the inspect mode. This was contributed by Matt Lilek.
  • Temporarily disable style properties — hovering over an editable style rule will show checkboxes that let you disable individual properties.

  • Style property editing — double click to edit a style property. Deleting all the text will delete the property. Typing or pasting in multiple properties will add the new properties.
  • Stepping for numeric style values — while editing a style property value with a number, you can use the Up or Down keys to increment or decrement the number. Holding the Alt/Option key will step by 0.1, while holding the Shift key will step by 10.

  • DOM attribute editing — double click to edit a DOM element attribute. Typing or pasting in multiple attributes will add the new attributes. Deleting all the text will delete the attribute.
  • DOM property editing — double click to edit a DOM property in the Properties pane. Deleting all the text will delete the property, if allowed.
  • Metrics editing — double click to edit a any of the CSS box model metrics.
  • Position metrics — the Metrics pane now includes position info for absolute, relative and fixed positioned elements.

Resources Panel

The Resources panel is a supercharged version of the previous Network panel. It has a similar looking timeline waterfall, but a lot has been done to make it even more useful.

  • Graph by size — click Size in the sidebar to quickly see the largest resources downloaded.
  • Multiple sorting options — there are many sorting methods available for the Time graph, including latency and duration.
  • Latency bars — the Time graph now shows latency in the bar with a lighter shade. This is the time between making the request and the server’s first response.
  • Unified resource views — clicking a resource in the sidebar will show you the data pulled from the network (not downloaded again), including the request and response headers.
  • View XHRs — the time and size graphs also show XMLHttpRequests. Selecting an XHR resource in the sidebar will show the XHR data and headers.

Scripts Panel

The previous standalone Drosera JavaScript debugger has been replaced with a new JavaScript debugger integrated into the Web Inspector. The new integrated JavaScript debugger is much faster than Drosera, and should be much more convenient.

From the Scripts panel you can see all the script resources that are part of the inspected page. Clicking in the line gutter of the script will set a breakpoint for that line of code. There are the standard controls to pause, resume and step through the code. While paused you will see the current call stack and in-scope variables in the right-hand sidebar.

The Web inspector has a unique feature regarding in-scope variables: it shows closures, ‘with’ statements, and event-related scope objects separately. This gives you a clearer picture of where your variables are coming from and why things might be breaking (or even working correctly by accident).

Profiles Panel

The brand new JavaScript Profiler in the Profiles panel helps you identify where execution time is spent in your page’s JavaScript functions. The sidebar on the left lists all the recorded profiles and a tree view on the right shows the information gathered for the selected profile. Profiles that have the same name are grouped as sequential runs under a collapsible item in the sidebar.

There are two ways to view a profile: bottom up (heavy) or top down (tree). Each view has its own advantages. The heavy view allows you to understand which functions have the most performance impact and the calling paths to those functions. The tree view gives you an overall picture of the script’s calling structure, starting at the top of the call-stack.

Below the profile are a couple of data mining controls to facilitate the dissection of profile information. The focus button (Eye symbol) will filter the profile to only show the selected function and its callers. The exclude button (X symbol) will remove the selected function from the entire profile and charge its callers with the excluded function’s total time. While any of these data mining features are active, a reload button is available that will restore the profile to its original state.

WebKit’s JavaScript profiler is fully compatible with Firebug’s console.profile() and console.profileEnd() APIs, but you can also specify a title in console.profileEnd() to stop a specific profile if multiple profiles are being recorded. You can also record a profile using the Start/Stop Profiling button in the Profiles panel.

Databases Panel

The Databases panel lets you interact with HTML 5 Database storage. You can examine the contents of all of the page’s open databases and execute SQL queries against them. Each database is shown in the sidebar. Expanding a database’s disclosure triangle will show the database’s tables. Selecting a database table will show you a data grid containing all the columns and rows for that table.

Selecting a database in the sidebar will show an interactive console for evaluating SQL queries. The input in this console has auto-completion and tab-completion for common SQL words and phrases along with table names for the database.

Search

Accompanying the task-oriented reorganization, the search field in the toolbar now searches the current panel with results being highlighted in the context of the panel. Targeting the search to the current panel allows each panel to support specialized queries that are suited for the type of information being shown. The panels that support specialized queries are Elements and Profiles.

The Elements panel supports XPath and CSS selectors as queries in addition to plain text. Any search you perform will be attempted as a plain text search, a XPath query using document.evaluate() and a CSS selector using document.querySelectorAll(). All the search results will be highlighted in the DOM tree, with the first match being revealed and selected.

The Profiles panel supports plain text searches of the function names and resource URLs. Numeric searches are also supported that match rows in the profile’s Self, Total and Calls columns. To facilitate powerful numeric searching, there are a few operators and units that work to extend or limit your results. For example you can search for ‘> 2.5ms’ to find all the functions that took longer than 2.5 milliseconds to execute. In addition to ‘ms’, the other supported units are: ‘s’ for time in seconds and ‘%’ for percentage of time. The other supported operators are ‘< ’, ‘<=’, ‘>=’ and ‘=’. When no units are specified the Calls column is searched.

In all the panels pressing Enter in the search field or ⌘G (Ctrl+G on Windows and Linux) will reveal the next result. Pressing ⇧⌘G (Ctrl+Shift+G on Windows and Linux) will reveal the previous result. In the Resources, Scripts and Profiles panels the search will be performed on the visible view first and will automatically jump to the first result only if the visible view has a match.

Available Now and Contributing

All of these things are available now in the Mac and Windows nightly builds. Give them a try today, and let us know what you like (or don’t like).

If you would like to contribute, there are some really interesting tasks in the list of Web Inspector bugs and enhancements, and other contributors in the #webkit chat room are pretty much always available to provide help and advice.“

(Via Surfin‘ Safari.)

Veröffentlicht am

Internet Explorer 8: Wieder konkurrenzfähig

Die Konkurrenten Firefox, Safari und Opera knapsen dem Platzhirschen unter den Windows-Browsern, dem Internet Explorer, kontinuierlich Marktanteile ab – wohl auch, weil sie wesentlich konsequenter weiterentwickelt werden. Mit Release 8 des Internet Explorers findet Microsoft aber wieder Anschluss an die erste Browser-Liga, wie die Feature-vollständige Beta 2 zeigt. Sie steht auf den Microsoft-Servern für Vista, XP und Windows Server 2003 zum Herunterladen bereit.

Vollständiger Artikel bei heise.de

Veröffentlicht am

Is It Time to Ditch IE6?

Is It Time to Ditch IE6?: „On August 27, 2001, almost exactly 7 years ago, Microsoft unleashed Internet Explore 6 upon the world. Despite version 7 having been out now for almost two years, and version 8 already in public beta, usage of the 2001 release remains strong. W3Counter reports that it is still the most popular browser in the world at 34.6% of all visits, while TheCounter.com has it second to IE7, but only barely and still commanding a whopping 36% market share.

Because so many people still use the older version of Internet Explorer, many web sites have made the choice to continue supporting it (including SitePoint — where about 12% of our visitors still come to us using IE6). But is it perhaps time to ditch IE6 support and start forcing people to upgrade?

Web application developer 37signals made the decision to drop IE6 support in July (actual support for Microsoft’s last generation browser ceased on August 15). ‘IE 6 can’t provide the same web experience that modern browsers can,’ wrote 37signals of the decision. ‘Continued support of IE 6 means that we can’t optimize our interfaces or provide an enhanced customer experience in our apps. Supporting IE 6 means slower progress, less progress, and, in some places, no progress.’

According to 37signals, supporting IE6 was holding them back. And 37signals isn’t alone in their dislike of IE6. In 2006, a few months before Microsoft released their last major browser, PC World magazine ranked Internet Explorer 6 as the 8th worst tech product of all time, citing its terrible track record when it comes to security.

Security is such a big issue for IE6, that one blogger recently reported that 95% of all bots accessing his site use Internet Explorer 6 as their user-agent. ‘Most blog spam comes from bots that either fake or, as a trojan, use Internet Explorer 6 of infected systems,’ he wrote, ultimately deciding to block IE6 completely to alleviate the blog spam problem.

Of course, security isn’t the only reason web developers are sour on IE6. Internet Explorer 6 is also dismal when it comes to standards compliance. So why do people continue to use it? As Nick La wrote a year ago, the reason people still use IE6 is that developers go out of their way to make web sites work in it. So most people don’t realize that IE6 isn’t a good browser.

‘We all know that IE6 is outdated and has horrible CSS rendering engine. However, most average Internet users haven’t realized that yet. Why? Because we put our hard work on it and patch the bugs by various IE hacks,’ La wrote, urging people to drop support for IE6.

A third of the Internet is a lot of people to just leave behind, though. So support for IE6 continues at most web sites, especially large ones. What we need to move us forward, however, is a bold move, not too much unlike the one Apple made in 2001 when it decided to forgo backwards compatibility when it released OS X. In order to save the Internet from IE6, perhaps we need to stop supporting it.

What do you think? Should web developers stop supporting Internet Explorer 6? Vote in our poll and then leave your thoughts in the comments below.

Note: There is a poll embedded within this post, please visit the site to participate in this post’s poll.

(Via SitePoint Blogs.)

Veröffentlicht am

Screenshots mit diversen Browsern erstellen

Besonders für professionelle Web-Entwickler ist browsershots.org gedacht. Der Dienst macht auf Wunsch Screenshots einer Website mit einer Vielzahl unterschiedlicher Browser auf verschiedenen Systemen – und das zudem kostenlos.

Über 60 Browser stehen bei browsershots.org für den Test zur Auswahl. Optional kann man weitere Eckdaten bestimmen: die Bildschirmgröße, die Farbtiefe, ob JavaScript aktiviert ist und in welcher Version es vorliegt, ebenso ob Java und Flash vorhanden sind oder nicht. Standardmäßig sind die jeweils wichtigsten Browser der Plattformen markiert. Wer will kann per Klick alle Kandidaten von Linux, Windows oder Mac OS anwählen oder aber sich nach Rendering-Engine entscheiden und alle mit Gecko oder alle KHTML/WebKit-Browser nutzen.

Der Dienst ist kostenlos. Dafür hat man allerdings keinen Einfluss darauf, wie schnell die Screenshots zur Verfügung stehen. Wer 10 Euro bezahlt, wird hingegen einen Monat lang bevorzugt behandelt.

(Via hoemmerich.com)

Veröffentlicht am

How To Run Firefox 2 and 3 Simultaneously

How To Run Firefox 2 and 3 Simultaneously: „

Firefox 3 was released just yesterday, bringing a wealth of new features to be excited about. From faster launch time and better memory management to interface polish and glitz, and over 8 million downloads already, Firefox 3.0 is truly a gem among modern web browsers.

For those that do web development, though, the 3.0 release means another round of website compatibility testing in both the earlier release and now the current one. For the most part, this isn’t a new challenge, but Firefox can be a bit peculiar: Upon launching Firefox, it checks to see if another instance is already running, and if found, brings up a new browser window of the currently running version. So, launching Firefox 2.0 while 3.0 is running results in two 2.0 windows, and vice versa for 3.0. This effectively stops the casual user from simultaneously running both Firefox 2.0 and 3.0 side by side. As an added side effect, when you completely shut down Firefox and launch a different major version, your profile information can get skewed, resulting in sometimes strange bookmark appearance and lots of checking for updates to installed add-ons. With a little tweaking, though, Firefox 2.0 and 3.0 can be convinced to run independently, each with their own bookmarks and add-ons.

Mac OS X Instructions
Running two versions of Firefox under Mac OS X couldn’t be simpler. The freeware application MultiFirefox takes all the guesswork out of the process by automatically detecting Firefox versions in your main Applications folder and presenting you with a list from which to choose the Firefox versions you’d like to launch. Complete with self-updating (thanks to the ubiquitous Sparkle framework), MultiFirefox is the easiest way to pull off this multi-browser stunt.

Windows Instructions
If you already have Firefox (2.0 or 3.0) installed, it’s important to back up your crucial information before getting started. Navigate to C:\Documents and Settings\YourName\Application Data\Mozilla\Firefox and copy your ‘Profiles’ folder somewhere safe.

Once backed up, download Firefox 2 and/or Firefox 3, depending on what you already have installed. Launch each installer and begin setting up Firefox, but make sure to choose Custom settings. When asked for a place to install Firefox, change the path(s) to C:\Program Files\Mozilla Firefox 3\ (or …\Mozilla Firefox 2), instead of just ‘Mozilla Firefox’. In doing so, you’ll place Firefox 2 at C:\Program Files\Mozilla Firefox 2\, and Firefox 3 at C:\Program Files\Mozilla Firefox 3\. Both versions of Firefox should now be in separate folders. (If you already have one version of Firefox installed at C:\Program Files\Mozilla Firefox\, you may choose to leave that where it is and just install the other version in a separate folder, however you’ll have to make a note of which is where, and modify the following instructions accordingly.)

Create a new shortcut to Firefox 2.0 by right-mouse-button-dragging C:\Program Files\Mozilla Firefox 2\firefox.exe to your Desktop (for now), and choosing ‘Create Shortcuts Here’. Name the shortcut ‘Firefox 2″. Repeat for Firefox 3, changing ‘2″ to ‘3″ where appropriate.

You’re almost there, but now we have to tell Firefox to keep the two instances separate. Open the Properties window for the Firefox 3 shortcut, and add ‘ -ProfileManager’ (space key, minus sign, ProfileManager) to the end of the string of text in the Target field. Click OK, then run that same shortcut to bring up Firefox’s Profile Manager. Rename the existing ‘default’ profile to ‘firefox3″, and also create a new ‘firefox2″ profile:

Once profiles are set, exit Firefox completely. With two profiles in place, each version of Firefox can have its own bookmarks, extensions, and other settings, without interfering with each other. Open up the properties windows for both the Firefox 2 and Firefox 3 shortcuts you made. Remove the -ProfileManager addition from the Firefox 3 shortcut Target, replacing it with -no-remote -p firefox3 (space key, minus sign, no-remote, space key, minus sign, space key, firefox3). Add the same to the Firefox 2 shortcut, again changing the 3 to a 2. Both shortcuts should now have the -no-remote option set, as well as -p followed by the designated profile that matches that Firefox’s version. In short, Firefox 3 gets the firefox3 profile, and Firefox 2 gets the firefox2 profile, seen below:

Click OK on both shortcuts to confirm the changes, and finally double-click each to run Firefox 2 and 3 at the same time!

Also, don’t miss LifeHacker’s Power User’s Guide to Firefox 3 for some excellent 3.0 tips and tricks, as well as ArsTechnica’s briefing of what’s to come in Firefox 3.1.

“

(Via Command-Tab.)

Veröffentlicht am

Internet Explorer 8: Beta 1 in deutscher Sprache

Internet Explorer 8: Beta 1 in deutscher Sprache: „Microsoft bietet ab sofort die Beta 1 des Internet Explorer 8 auch in deutscher Sprache an. Anfang März 2008 erschien die erste Vorabversion des kommenden Microsoft-Browsers zunächst nur in englischer Sprache. Bis auf die Lokalisierung unterscheiden sich die beiden Beta-Fassungen nicht. Der Browser unterstützt unter anderem CSS 2.1 sowie erste Teile von HTML 5 und mit Hilfe von ‚Web Slices‘ lassen sich einzelne Teile einer Website gesondert über die Favoriten-Leiste abrufen. (MSIE, Microsoft)“

(Via Golem.de.)

Veröffentlicht am

Yahoo: Wie man Webseiten schneller macht

Yahoo: Wie man Webseiten schneller macht: „Yahoos Exceptional-Performance-Team beschäftigt sich mit der Frage, wie man Webseiten schneller macht, von Maßnahmen auf Serverseite über die Inhalte bis hin zu Cookies, JavaScript, CSS-Bildern und den speziellen Anforderungen mobiler Webseiten. Nach den ersten 14 Regeln für schnellere Webseiten hat Yahoo nun 20 weitere Tipps veröffentlicht. (AJAX, iPhone)“

(Via Golem.de.)

Veröffentlicht am

Optimizing Page Loading in the Web Browser

Interessanter Artikel, der unter anderem kurz auf die SCRIPT-Tag-Problematik eingeht.

Optimizing Page Loading in the Web Browser: It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.

[snip]

It turns out that figuring out ‘all the associated resources’ is the hard part of the problem. The browser does not know what resources it should load until it has completely parsed the document. When the browser first receives the HTML text of the document it feeds it to the parser. The parser builds a DOM tree out of the document. When the browser sees an element like <img src> that references an external resource it requests that resources from the network.

Problems start when a document contains references to external scripts, <script src>. Any script can call document.write(). Parsing can’t proceed further before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying effect of the latency.

The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.

[snip]

(Via Surfin‘ Safari.)