Habaritag:blog.mouvedia.com,2024-03-19:atom/c1dbc2d2e99c4b94088492b9c9e4f76614c2ebc4Marc’s Digital Life& web design considerations2012-07-26T21:04:50+02:00Graded browser support: the ultimate methodMarchttp://blog.mouvedia.comtag:blog.mouvedia.com,2012:graded-browser-support-my-method/13433255592012-07-26T21:04:50+02:002015-03-27T03:55:30+01:002012-07-26T21:04:50+02:00<p>Firstly you need to choose which browsers you will be supporting. As a general guideline, you should always support the big 3: Internet Explorer, Chrome and Firefox. If you are diligent and would like to do it thoroughly you will have to add the perpetual runner-ups—Opera and Safari—to the equation. That's the easy part.<br>Now you have to select which versions of these you should support. There are 3 grades:</p><ul>
<li><b>Base</b> is plain and simple what you should start with: if it doesn't work flawlessly or degrades poorly in these you are not on the right track.<br>
</li>
<li><b>Minimal</b> represents the versions which should ideally be supported too but most of the time are overlooked. For these you can provide a reduced experience without all the bells and whistles using graceful degradation and progressive enhancement but the essential functions like navigation and content access remain a must.<br>
</li>
<li><b>Extreme</b> should be be taken into account in the unlikely case that you are handling a very high traffic website: if it's not on this <a href="http://www.alexa.com/topsites">list</a> you can neglect that grade entirely.<br>
</li></ul><table summary="" style="empty-cells: hide;width:auto;text-align:center">
<tbody>
<tr>
</tr>
</tbody>
<thead>
<tr>
<th></th>
<th>Internet Explorer</th>
<th>Firefox</th>
<th>Chrome</th>
<th>Opera</th>
<th>Safari</th>
</tr>
</thead>
<thead>
<tr style="background-color: transparent;">
<th>Base</th>
<td>8</td>
<td>3.5</td>
<td>Stable</td>
<td>12</td>
<td>5.1.7</td>
</tr>
<tr>
<th>Minimal</th>
<td>6</td>
<td>2</td>
<td>Beta</td>
<td>10</td>
<td>4</td>
</tr>
<tr>
<th>Extreme</th>
<td>5.5</td>
<td>1</td>
<td>Canary</td>
<td>8.5</td>
<td>3.1</td>
</tr>
</thead>
</table>My First Webkit BugMarchttp://blog.mouvedia.comtag:blog.mouvedia.com,2011:my-first-webkit-bug/13076079862012-03-08T13:26:03+01:002012-03-08T13:40:46+01:002012-03-08T13:26:03+01:00<p>Sadly WebKit isn't exempt of redrawing bugs. I have discovered one while doing my website and never actually had the time—until now—to document it.<br>I am providing a <a href="/bug/webkit.html" title="click on the red buttons">test case</a> which demonstrates it. <br>Anyone knows if a bug had already been filled for it?</p>How to Properly Detect <details> SupportMarchttp://blog.mouvedia.comtag:blog.mouvedia.com,2011:how-to-properly-detect-details-support/13073590832011-06-06T13:18:08+02:002014-03-15T03:41:54+01:002011-06-06T13:18:03+02:00<p>Between version 10.0.603 and 12.0.701 Google Chrome had partial support for the <code><details></code> carelessly leaving its rendering <a href="https://bugs.webkit.org/show_bug.cgi?id=51071#c57">for later</a>.<br><a href="http://mathiasbynens.be/notes/html5-details-jquery#comment-35">Mathias Bynens</a> created a feature test which was too convoluted for my liking.<br>So I've made some research and found a shorter method which use what-I-am-calling correlated feature detection.</p><pre>if(!("open"in document.createElement("details"))||window.chrome&&window.google&&google.gears)
{fallback()}
</pre><p>In the very unlikely edge case that you have installed <a href="http://gears.google.com/" title="removed since version 12.0.702">Gears</a> on Chrome 12+ you would be served the javascript polyfill instead.<br>As a matter of fact Google plans to provide offline support to Gmail using HTML5 <a href="http://www.google.com/support/a/bin/answer.py?hl=en&answer=1308394">this summer</a> which will probably coincide with the first stable release to natively support the <code><details></code> element.</p>