San Bei Ji » webdev

SVG and MathML in HTML5

Joe — Wed, 08 Dec 2010 04:51:09 +0000

The next article in the Developing with HTML5 series.

Pick a flower on Earth and you move the farthest star.

—Paul Dirac

Scalable Vector Graphics (SVG) and MathML are XML applications that are widely used in scientific contexts. SVG is used to draw vector graphics, and is frequently found in visualization libraries such as ProtoVis. MathML is used to describe the presentation and meaning of mathematical formulæ. They are very easy to work with in a programmatic sense, because they are XML-based and therefore just text, and yet they are capable of rendering beautiful information in supporting web browsers.

Paul Dirac, who loved the maths.

The idea behind XHTML was to move the web toward extensibility (the X in XHTML), where a web browser markup language could be seeded with bits of other XML applications by declaring a namespace and letting things coexist. The problem with that plan was that XML parsers were required to be extremely fussy, to the point that if a problem was detected the browser should render an error message. Browsers don’t work that way. Instead, they forgive your human or computer errors and render the page as best as their little hearts can.

In the beginning of the process, HTML5 was not extensible, and to this day it remains opposed to the whole namespace idea. But SVG and MathML are highly popular and useful XML applications that deserve a place within the HTML5 spec. And so shall it be: and are the opening volleys in inserting SVG and MathML into your HTML5 document tree. Any elements that are children of the SVG and MathML specs are valid and functional child elements of the and elements respectively. No need to declare a namespace. You’re done. Thank you. Now this is not to say that the idea of inserting these XML applications within the HTML5 spec is not without some controversy. What about other XML applications and XHTML extensions such as RDFa, CML, and MML? CML (Chemical Markup Language) and MML (Music Markup Language) are indeed common, but within specific application contexts. They are not supported yet by any web browser (whereas MathML and SVG are well supported.) RDFa on the other hand is a more political issue: More on that whole mess in a later post… So in short, SVG and MathML are supported objects within HTML5 because they are widely deployed in existing web browsers, and they are very useful – particularly to those of us in the science industry charged with representing scientific information on the web. Let’s look at how to get started. First, an SVG example – simply start your SVG block using the element and drop your SVG markup within: The Sun in SVG

`The Sun in SVG`

Here’s a live example that will work in browsers that support SVG and MathML in HTML5. (Try it in the Firefox 4 beta.) Or if you aren’t one of those early-adopting browser users that are used to living dangerously, then please refer to the perfectly safe reference image below:

Reference rendering of the sun in SVG.

To learn more about SVG, check out the w3schools SVG tutorial for starters. While SVG is supported in basic forms in Chrome, Safari, and Firefox, only Firefox 4 (currently in beta) supports embedding SVG natively in HTML5. But Chrome will follow soon, followed by IE9, Safari, and eventually (hopefully) Opera. MathML is equally straightforward, using the element as the opener:




  
  The Dirac δ-function


  The Dirac δ-function
   $\int_{- \infty}^{\infty} f δ = f (0)$

Compare to the reference rendering below, or check out the live example.

The Dirac delta function rendered from MathML in Firefox 4 beta

Again, currently Firefox 4 beta is the only close-to-shipping browser that supports this. But it is expected to come to all major modern browsers in 2010/2011, including IE9, Safari, Opera, and Google Chrome. To learn more about how to construct MathML, check out Mathematica’s MathML tutorial.

In short, it’s an easy trip to embed SVG and MathML in HTML5. No namespaces are required. The trade-off is less extensibility, but if you need extensibility back there’s an XML flavor of HTML5, appropriately titled XHTML5. In the meantime, start looking for ways to leverage SVG and MathML in the coming months as capable browsers start coming online! While this is indeed a bit on the bleeding-edge side of things, web browsers are beginning to implement these features and I expect over the next year or two the practice of embedding SVG and MathML markup in HTML5 web pages will become entirely commonplace within the scientific community.

Exploring New HTML5 Elements

Joe — Fri, 03 Dec 2010 18:19:36 +0000

The next article in the Developing with HTML5 series.

Nothing endures but change.

—Heraclitus

The HTML5 draft specification includes many new elements and attributes for enhanced structural and semantic clarity. Most of the old elements still exist too, and you can still use them if you like. But the new elements will serve to make your markup clearer, more compact, and more functional in modern web browsers. Let’s take a look at some of these elements and what they mean for web developers in scientific contexts. For starters, here’s a list of the new elements, along with links to the relevant points in the specification:

Heraclitus by cote on Flickr

A first glance at HTML5 structure

The first elements we should look at are the structural ones:

article, aside, figcaption, figure, footer, header, hgroup, nav, and section. Take a look at those names for a moment. Think how many times you’ve formed your markup in a fashion resembling something like the following code:

id="header">

`Tales of Woe`



  The neverending saga continues...


  id="nav">

    Navigation


    

      Page One


      Page Two


      Page the Third


    


  



class="article">

  The Stagnant Staircase


  It was a dark and stormy night. She didn't notice the vase by the banister as she walked past it, holding the wilted flowers in stale and murky water. The only thing she knew was that the nightmares had to end, and that they would end tonight...




id="footer">

  ©2010 In Your Nightmares Productions.

In particular, I’d like to direct your attention to the ID and class attributes for header, article, and footer. These are major structural components that are common in everyday markup. Use of these semantic structures is so common, that it made sense to construct elements around them. Here is the same code as the above, refactored in HTML5:



  Tales of Woe


  The neverending saga continues...


  

    Navigation


    

      Page One


      Page Two


      Page the Third





  The Stagnant Staircase


  It was a dark and stormy night. She didn't notice the vase by the banister as she walked past it, holding the wilted flowers in stale and murky water. The only thing she knew was that the nightmares had to end, and that they would end tonight...






  ©2010 In Your Nightmares Productions.

In the revised HTML5 version, things are much clearer to read. Your eye can readily follow where the beginning and end of the structural blocks are, because they have structural names such as article and footer instead of just generic div elements with nondescript element closings.

The specification defines header as “a group of introductory or navigational aids.” This could mean navigation, tag lines, section headings, logos, etc. In this example, we use this element to define the masthead of a page, but it could just as easily be a child of a navigation element or an article too – if that’s what the content semantically would require.

The article element represents a defined, distributable piece of content. This might be a press release, a journal article, a blog post, or even a status message such as we’d see on Twitter. We used it here to begin our piece of pulp fiction. (I’m sure there’s more to the story – perhaps at the next NaNoWriMo I’ll use that as a germ for an actual story…)

Heading groups

Oh, one more thing about this section that we should address, and here’s where things get interesting: the tagline. Right now we have a paragraph tag with a class of tagline. And if we’d like to keep that formatting in place, that’s fine. However there’s a new construct in HTML5 that we can leverage, so let’s take a look at the hgroup element:



  Tales of Woe


  The neverending saga continues...

Here what we’ve done is to change the tagline paragraph into an h2 element, and wrap the h1 and h2 elements inside of an hgroup. The hgroup element is a heading, and can only contain two or more of h1 through h6.

Sectioning off headings

Furthermore, you can use the section element to help structure your document. In a nutshell, consider that any heading within a section is one level lower than headings of the same face value outside of it. Consider the following markup:



  Homininae


  

    Gorillini


    

      Gorilla gorilla


      

        Gorilla gorilla gorilla


        Gorilla gorilla diehli


      


      Gorilla beringei


      

        Gorilla beringei beringei


        Gorilla beringei graueri


      


    


  


  

    Hominini


    

      Pan


      

        Pan traglodytes


        

          Pan troglodytes troglodytes


          Pan troglodytes verus


          Pan troglodytes vellerosus


          Pan troglodytes schweinfurthii


        


        Pan paniscus


      


    


  


  

    Homo


    

      Homo sapiens


      

        Homo sapiens sapiens

These are all h1 elements, but structurally the hierarchy is represented as so, due to the nestings of the section elements:

Homininae
- Gorillini
  - Gorilla gorilla
    - Gorilla gorilla gorilla
    - Gorilla gorilla diehli
  - Gorilla beringei
    - Gorilla beringei beringei
    - Gorilla beringei graueri
- Hominini
  - Pan
    - Pan traglodytes
      - Pan troglodytes troglodytes
      - Pan troglodytes verus
      - Pan troglodytes vellerosus
      - Pan troglodytes schweinfurthii
    - Pan paniscus
- Homo
  - Homo sapiens
    - Homo sapiens sapiens

It’s turtle headings, all the way down

In the code, we had all h1s, but the spec requires that the hierarchy is interpreted as shown in this list, and we can clearly see that say homo sapiens sapiens is a subheading of homo sapiens, which is in turn a subheading of homo, then finally homininae. But why does this matter? Well, consider for a moment that the HTML5 specification only allows specific headings of h1 through h6. Then consider if we were to extend our taxonomic classification to encompass all mammals. We’d run out of headings before we got to homininae! In this manner, we can use the h1 element ad infinitum within it’s own section elements, and if we needed we can throw in a little h2 through h6 if needed. If we run out, just add more sections.

A small caveat, however: Having an endless stream of h1s means today’s screen readers used by disabled users might have trouble dealing with the hierarchical order of your content, and there is no functional CSS or other construct currently available to work around this problem. If you have accessibility issues to contend with, stick with the traditional usage of h1 through h6 for now, even if you use heading within.

Go figure

The figure and figcaption elements are for inserting and captioning figures in text documents. Before, we didn’t have an effective way to mark up figure images, and certainly had to come up with creative ways to mark up captions. These elements wrap this problem up nicely.



  

  This is a lovely Amati 1710 viola.

As a side note…

The only structural elements I haven’t mentioned yet is the aside element. The aside element indicates related information. It could be used for what we consider typical “sidebar” content in a web page layout, or it could be an aside in a story – such as a text box titled “learn more” in a feature news story or textbook-style article of content. This element may have it’s own headings, nav, content, and whatnot, and if it is found occurring within an article then it is considered related to that given article of content.

And that just about wraps up an introduction to HTML5 with a brief overview of the core structural and hierarchical elements. As we move forward with this series, we’ll take a look at the other new elements mentioned above, as well as look at some of the ways HTML5 has refactored existing markup to have new meaning.

First steps with HTML5

Joe — Mon, 08 Nov 2010 02:22:21 +0000

As I mentioned in my earlier post, HTML5 means quite a lot more than what we all understood markup to be in the HTML 4/XHTML days. At the core of the HTML5 specification however, markup is still the foundation. Let’s take a quick look at some of the differences between HTML5 and it’s predecessors. But before we get too into this HTML5 series, I should mention that the principal reason I’m posting my thoughts here on the subject is to learn for myself, and secondly to document a nugget of information or two that might be useful to you all out there. Excellent stuff has been written on this subject. Go read Bruce Lawson and Remy Sharp’s book Introducing HTML5, Mark Pilgrim’s HTML5 Up and Running, and Tantek Çelic’s HTML5 Now. Go read every one of these books cover to cover — I highly recommend them.

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

—Albert Einstein

Physicists with mad hair who most assuredly would have been totally down with HTML5.

I will now go through some of the reasoning akin to the way Pilgrim and Lawson follow in constructing the optimal basic HTML5 markup template, with my own commentary, flavor, and style thrown in just so I can acquire it in my head and hopefully help you all along with the reasoning:

The first line of code we see in HTML documents is the doctype. The reason why it is standard practice to use doctypes in markup, as all good web developers already know, is to trigger standards mode in web browsers. All major modern web browsers support this function, and it makes the role of a web developer much simpler to develop a consistent user experience across all platforms. If you’re familiar with the doctypes of HTML 4 and XHTML 1, you are familiar with how complex they appear.

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Not the type of thing one would readily commit to memory at first glance. The HTML5 doctype is significantly shorter:

There – fixed it.

With just a little experimentation, it was found that all browsers triggered standards mode with just the above minimal amount of code. So the HTML5 spec was written to codify what was already in existence, in the most compact and simplistic way that works. No long URL. No unmemorable string of voodoo or versioning cluster nonsense. Just the standards mode, please. That’s all we need – something simple and to the point.

The next thing you should know about is defining a character set for your document. This is a departure from the straightforwardness of our journey into HTML5 markup, but it is important for addressing a security concern where browsers attempt to guess character encodings that could conceal malicious scripts, so let’s get off on the right foot shall we? First, the old way:

Again, not the most memorable code. But then, that’s why I like HTML5: It fixes things. This is much better:

I should also point out something important here. In HTML5, you don’t need to place quotation marks around attribute values if there are no spaces. Spaces separate multiple values, and you need those quotes to herd them together and distinguish them from standalone attributes (which we’ll get into later). So, this would also be perfectly valid:

If you’re compressing a document for speedy delivery over slow networks, such as mobile contexts, then here’s a place to save a few bytes. But in general, it’s my personal preference to quote my attribute values for legibility’s sake.

Another thing you might notice is that this standalone element is not self-closing in the XML sense. You could write it that way, as in:

That’s with the trailing slash before the end closing angle bracket, in case you missed it. This would be the way it would be done were our document conforming to XHTML rules. XHTML5 is the XML-conformant variant of HTML5 and is developed as an option to the HTML5 specification. But it is not necessary, unless you really need XML parsing to be enabled. And the good news is, HTML5 allows for SVG and MathML embedding without having to switch to XHTML mode, so for most contexts even at the scientific level, we won’t need the X tacked on to the front of our HTML5. But please, don’t let that stop you from self-closing those tags. I myself only recently got out of the habit, after writing HTML5 for the past 10 months or so. It’s perfectly valid either way.

The rest of your basic HTML5 document at this point will look very familiar, with just a few things to point out. The most notable difference will be the opening HTML tag. Usually we’d just open up our markup tree with this:

However, if we were pulling out all the XML stops and such, we would be defining a namespace and a language, as so:

In HTML5, it is certainly not necessary to define a namespace (the xmlns part) because that much is assumed. That leaves us with the language declaration, in the form of the lang attribute. Lang attributes are specified according to IETF BCP47, and there’s a practical list of these codes that may be used on MSDN. A lang attribute is used by search engines to understand the content meaning better and categorize the results. It is used by speech synthesizers to produce the correct pronunciation of words with similar spellings across languages. It is used by browsers for producing the correct hyphenation, spelling correction, and so on, even across regional dialects. A lang attribute specifies the language of the contents of the given element, which means you may specify several languages on a given document.

Do use the lang attribute. Even better – use it regionally. I would specify lang=”en-us” (English – U.S.) for most of my web work, but on occasion I’ll dip into Traditional Chinese for my language studies, with specific vocabulary rules for Taiwan, in which case I’d use lang=”zh-tw” (Chinese, or “zhongwen” – Taiwan).

I’m fascinated by language processing and character sets in computing, so forgive my overly-thorough description of the situation back there. The point is, in HTML5, we can shorten this information on the opening HTML element to this by removing the namespace and the xml:lang attributes, and including the addition of my regional preference:

There, that’s a gooood HTML element. For other elements in your document, such as perhaps LI or P, you might specify additional languages as needed.

Bruce Lawson has a nice, clear writeup of what he considers to be the minimal HTML5 document framework. I agree with this markup template, with my own minor stylistic modifications presented below:

My Page Title

My awesome web page.

The rest is pretty straightforward, right? We have the overall wrapping HTML element, a HEAD, a BODY, our charset definition, our lang attribute set to Amurikun, well-formed tag organization, a title attribute, and some content. That’s it – not too different from our past experiences with HTML4 and XHTML, but arguably much simpler. You now can fill in the rest of your markup as needed as if it were HTML 4.01, and it’ll work in all modern browsers. That’s right, it’s OK to get started with this much right away. But if we stopped there, that would be missing the point of the new semantic conveniences of HTML5! So in the next post we will explore those constructs in a little more detail and talk about how these new constructs will save you time and make more sense for web development in the long run.

Cheatsheet from today’s Open Web Camp “Refactoring for Mobile” talk

Joe — Sun, 18 Jul 2010 05:56:09 +0000

For the Open Web Camp attendees, here’s my cheatsheet from the Refactoring for Mobile talk I gave today at Stanford:

Get it as a CSS file and view it in your favorite code editor:

walkthrough.css

Or preview here:

/* The first thing we need is a media query and to add to the head: */ @media only screen and (max-device-width:480px) { /* For starters, note the two divs #wrapper and #contents. Let's use those to create our structural layout and fold back in some of those design elements. */ #wrapper { background:url(img/back2.png) no-repeat center top; margin-top:-1em; } #contents { text-align:left; width:95%; margin:0 auto; } /* Now, let's style the main navigation buttons. First, we will use inline-block to give block-like behavior to the buttons but retain width based on the content. Then we set the color, font size, and floating, and add a bit of box shadow. */ .menu a { display:inline-block; background-color:#000; float:left; font-size:14px; padding:1em 0.95em; border-left:1px solid #888; -webkit-box-shadow:0px 1px 5px #222; } /* We can now use border-radius to style the left and right buttons instead of image files: */ .first_menu a { border-bottom-left-radius:6px; border-left:none; margin-left:2px; } .menu li:last-child a { border-bottom-right-radius:6px; } /* What if we flip to Landscape? There's a media query for that: */ @media screen and (orientation:landscape) { .first_menu a { margin-left:78px; } } /* Now we can style the body content. #middle-contents is the main containing block. We can use the background image from the main stylesheet, but alternately we can use rgba backgrounds to get finer control. Add border radius and box shadow for depth. */ #middle-contents { /* background:url(img/side.png) repeat-y;*/ background-color:rgba(0,0,0,0.3); padding:1em; border-radius:10px; -webkit-box-shadow:0px 1px 6px #000; box-shadow:0px 1px 6px #000; font-size:1.2em; margin-bottom:1em; } /* Let's style the banner text and have some fun with it using web fonts. Here's a font we'll pull in, using TTF and SVG formats. Sadly, the vendors have many opinions on the solution, but FontSquirrel can help sort it out. */ @font-face { font-family:'Lobster'; src: url('Lobster_1.3-webfont.ttf') format('truetype'), url('Lobster_1.3-webfont.svg#webfontcOtP3oQb') format('svg'); } #logo a { display:block; text-align:center; padding-top:12px; font-family:Lobster, sans-serif; font-size:2.7em; text-shadow:0px 2px 4px #000; } #logo h1 { font-family:Lobster, sans-serif; text-align:center; font-size:1.5em; } /* The float is creating a spacing issue. We can fix that with a clear: */ #header { clear:both; } /* We are getting close. Now on to the bottom of the page. The #comments section is too wide. We need to reset it: */ #comments { width:100%; } #comments textarea, #comments input { width:93%; margin-bottom:0.5em; padding:0.5em; font-size:1.2em; border:1px solid #000; border-radius:6px; } /* That input button could be nicer: */ #comments input.button { display:block; width:80%; margin:0 auto; height:2.5em; padding:0.5em; } /* Now we have something that looks like it was meant for a mobile device. Let's wrap this up by making the final links look like tap-friendly buttons: */ #right-col a { display:block; padding:0.5em; font-size:1.3em; font-weight:bold; text-align:center; background-image: -webkit-gradient(linear, left top, left bottom, from(#666666), to(#666666), color-stop(.5,#333)); border:1px solid #000; border-radius:20px; margin-bottom:0.4em; } /* Maybe those final link items were over the top. Let's restore them to inline links: */ #copyrights a { display:inline; margin:0; padding:0; font-size:small; border:none; background-image:none; } } /* Now add some HTML5: Add placeholder="I think..." to the textarea in comments.php, line 191. Add input types to email and url fields. Finish with atouch icon: (Note to attendees: I forgot to add the piano.png file to my project files. But this works otherwise!) */

Waxing Firefox, Waning IE

Joe — Sat, 03 Jan 2009 03:16:45 +0000

IE continues it’s downward spiral as the browser dips below 69% at the expense of Firefox and the WebKit-powered duo of Apple Safari and Google Chrome. The breakdown as paraphrased by TG Daily:

Net Applications released updated global browser market share numbers today, indicating that IE is losing users at an accelerated pace. The browser’s share dropped from 69.77% in November to 68.15% in December. Most rivals were able to pick up a portion of what IE surrendered. Firefox gained more than half a point and ended up at 21.34%, Safari approaches the next big hurdle with 7.93% and Chrome came in at 1.04%, the first time Google was able to cross the 1% mark. Opera remained stable 0.71%, but it is clear that the Norwegian browser cannot attract any users IE loses.

This is no surprise. Taking into account the seasonal fluctuation towards home users in December which point to higher “non-corporate” platforms and browsers, this is still a landmark statistic and shows that if the gradual decline continues, 60% and 50% are not that far off in the future. As the trend for Firefox and WebKit to rise at the expense of IE has been continuing for some time now. What surprises me are a couple of things though, specifically:

The rate at which IE is losing overall market share: While I predicted a decline in market share over the long term, I didn’t think I’d ever see it declining at the rate it is currently declining on a month to month average. It just seems steep to me.
Opera adoption: I thought that more people would pick up Opera – at least I thought they’d have 2 or 3 percent by now. They are by far the most deployed browser on the mobile web, but nobody knows it really because they could care less what browser is being activated from their baked-up phone UI, and it’s unlikely that they use it much (which is the fault of the phone vendors – Opera Mobile by itself is great.) I like Opera. It’s not my default browsaer, but I find myself using it from time to time for certain things. Certainly for print and presentations, and also it’s handy mobile web dev in Small Screen mode.

I wonder how much of those Safari numbers are being driven from iPhone and iPod Touch users? What is also interesting in these metrics is the inclusion of Google’s Chrome browser, which again is based on the WebKit core that Safari is founded upon. Chrome broke 1%, and at the same time they have begun recommending against IE and in favor of Firefox and Chrome for Google Gmail users. This is an interesting coup attempt to grab their Gmail base still floundering on IE6, and it is even more noteworthy that IE7 was not mentioned as an alternative. I am betting Chrome will be a major contender a year from now, and the overall WebKit market share might even approach Firefox’s levels. What is probably safe to predict is that IE will continue to lose out to Firefox and WebKit-based browsers and I would not be surprised at this point if the rate of increase in adoption of alternative browsers began to accelerate in 2009 towards these platforms.

It is nice to see strong lines of diversity returning to the browser market. The benefit will be for better browsers and stronger support overall for web standards.

The madness of screens vs. browsers on the mobile web

Joe — Mon, 29 Dec 2008 06:10:41 +0000

This evening as I was doing some research on mobile web development, I got myself on a tear about the wild differences we face as web developers regarding screen sizes and default browser installations, and came up with this:

Make	Model	Resolution	Default Browser Engine*
Amazon	Kindle	600 x 800	NetFront
Apple	iPhone	480 x 320	WebKit
Apple	iPod Touch	480 x 320	WebKit
BenQ	M315	128 x 128	Opera
HTC	G1	320 x 480	WebKit
Kyocera	Mako S4000	128 x 160	Openwave
Motorola	Hint QA30	320 x 240	Openwave
Motorola	Krave ZN4	240 x 400	Openwave
Motorola	KRZR K1	176 x 220	Opera
Motorola	RAZR V3	176 x 220	Opera
Motorola	ROKR E2	240 x 320	Opera
Motorola	SLVR L7	176 x 220	Opera
Motorola	V980	176 x 220	Opera
Motorola	VE240	128 x 128	Openwave
Motorola	ZINE ZN5	240 x 320	WebKit
Nokia	6300	240 x 320	Opera
Nokia	2605 Mirage	128 x 160	Openwave
Nokia	N81	240 x 320	WebKit
Nokia	N810	800 x 480	Gecko
Nokia	N82	240 x 320	WebKit
Nokia	N95	240 x 320	WebKit
Nokia	N96	240 x 320	WebKit
Palm	Centro	320 x 320	NetFront
Palm	Treo 680	320 x 320	NetFront
Palm	Treo 750	240 x 240	Internet Explorer
Palm	Treo 755p	320 x 320	NetFront
Palm	Treo 800w	320 x 320	Internet Explorer
Palm	Treo Pro	320 x 320	Internet Explorer
RIM	Blackberry Bold	480 x 360	Blackberry Browser
RIM	Blackberry Pearl	240 x 320	Blackberry Browser
RIM	Blackberry Storm	480 x 360	Blackberry Browser
Samsung	Behold T919	240 x 400	NetFront
Samsung	BlackJack SGH-i607	240 x 320	Internet Explorer
Samsung	Epix i907	320 x 320	Internet Explorer
Samsung	Eternity SGH-A867	240 x 400	Openwave
Samsung	Highnote M630	176 x 220	Polaris
Samsung	Omina i910	240 x 400	Internet Explorer & Opera
Samsung	Rant M540	176 x 220	Polaris
Samsung	Rugby A837	176 x 220	NetFront
Samsung	Saga i770	320 x 320	Internet Explorer & Opera
Samsung	SPH-Z400	176 x 220	Obigo
Siemens	SX66	240 x 320	Internet Explorer
Sonim	XP3	128 x 160	Opera
Sony Ericsson	C702a	240 x 320	NetFront
Sony Ericsson	C905a	240 x 320	NetFront
Sony Ericsson	TM506	240 x 320	NetFront
Sony Ericsson	W595a	240 x 320	NetFront
Sony Ericsson	W760	240 x 320	NetFront
Sony Ericsson	X1	800 X 480	Internet Explorer & Opera

*Some service providers will opt to use a different browser than the ones listed here.

It is interesting to note the diversity on these fronts. Screen sizes are all over the map, and the browsers here are not the usual suspects we see on the desktop. As for browsers, while it is certainly possible on many of these platforms to install a different browser (Opera being the usual choice), most users don’t bother. Regardless, Opera is the dominant player in this space, with significant marketshare owned by all the other actors on the mobile stage. As I research this topic, the WebKit engine proves to be the vast trendsetter and it is interesting to see how many platforms besides the iPhone are picking this one up. And trends show that this landscape is evolving rapidly as mobile capabilities increase and users begin surfing the web on their mobile devices with greater and greater frequency. ABI Research sees web browser installations on smartphones expanding from 130 million in 2008 to 530 million by 2013. The mobile web is a vastly unexplored frontier in web design and we should start seeing more and more attention getting paid to this aspect of the online world.

Update: Amazon Kindle’s Basic Web is based on NetFront – table updated to reflect this.

The woes of CSS color in print typography

Joe — Mon, 08 Dec 2008 04:57:21 +0000

As I was working through some documentation on styling CSS for print recently, I came across an oddity. Colors that I was specifying in my print styles were not getting represented properly at print time. Specify a nice shade of gray for some text? Maybe want to ghost print something very lightly on the printed page. No – not in Firefox. In fact, any shade of gray comes out as black in Gecko browsers. This behavior is only slightly more intelligent in Safari and IE7, but in all cases the user agent makes an assumption about what color of text constitutes being “too light” and then defaults to a darker shade of pale that is handled inconsistently across the various browsers. Printing font colors appears to be a messy situation.

Now the reason why the browser vendors have made this assumption is clear: Printing light text on what is almost always white paper is largely unreadable. Furthermore, printing in pure black, devoid of any complex color mixing, can make printing much faster, because the printer doesn’t have to mix in any red, green, or blue ink and can focus on getting the task done. But what is maddening to the designer trying to achieve accurate color representation in print from their web pages is that all of the major browsers assume that they are smarter than the designer, and recolor the text based on their own inconsistent algorithms. Actually, that may be assuming a bit much on the part of the browsers – sometimes the results defy logic.

To investigate further, I created a testing page. This page runs through some of the various color gamuts and creates a list entry for a number of color variations. The results are surprising… Here are some findings:

Safari 3: Between rgb(0,0,0) and rgb(107,107,107), things appear fine. But then there is a breakdown between rgb(108,108,108) and rgb(127,127,127) where the text will randomly jump to a light gray – equivalent of rgb(199,199,199). For lack of a better term, I call this area “The Dead Zone,” and we will see it again soon. At rgb(128,128,128), the text color then jumps to black and as you ascend the values towards an expected white color, Safari yields a progressive amount of additional lightness to the text until it finally winds up at around rgb(171,171,171) where it should be 255 for all values.

The Dead Zone also occurs in the red, green, and blue colorspaces. If you fix red at 127, about halfway between the minimum value of 0 and the maximum value of 255, we get a dead zone between rgb(127,100,100) and rgb(127,127,127). Same ratios happen starting at rgb(100,127,100), and at rgb(100,100,127).

Finally, Safari renders rgb(0,255,255), rgb(255,0,255), and rgb(255,255,0) inconsistently from their adjacent color values.
Gecko browsers such as Firefox, Camino, and Flock print the entire gray space in black. (Exception: Firefox 3 will actually print the color exactly right – see below.) You cannot specify a light gray such as rgb(127,127,127) or anything else. It will always default to pure black whether you like it or not. If you fix a color bucket at 0, you will get semi-accurate color for the rest of the gamut, but the other color combinations will trend towards black text the lighter it gets.
In Opera 9, gray shades render accurately up until rgb(185,185,185), and then higher values default to black. In the points tested, the same conversion to black happens after values higher than rgb(127,211,211), rgb(255,156,156), rgb(87,255,255), rgb(209,209,0), rgb(193,193,127), and rgb(177,177,255).
IE7 never gets any lighter than rgb(108,104,102) for grayscale, and the rest of the color spaces don’t seem to allow anything lighter than a midrange hue equivalent to around 110 for any given value.
One last thing about Gecko browsers: The marker (the little bullet to the left of each list item) will display the correct color value in print, even though the text itself won’t match! Underlines/Overlines/strikethrough will match whatever color the text is though. So at least here you can see what the color was supposed to be…
The exception as mentioned above is Firefox 3. Firefox 3 has been tested to print the colors exactly as you see them on screen, and is the only browser thus far that works this way in a predictable manner.

The conclusion I draw from all of this is that color in CSS print typography is woefully inconsistent, and I do recommend defaulting to black text in most cases simply because it is so problematic to predict what color you will actually wind up with in print. If you need color, go with a darker shade and test your print output in the four major modern browsers (IE, Safari, Firefox, Opera) to see what you can get away with.

Please feel free to try the test suite for yourself and let me know your findings in the comments or via a pingback.

The non-importance of !important

Joe — Tue, 05 Aug 2008 19:26:43 +0000

Molly Holzschlag raised a good issue via Twitter yesterday regarding the !important rules in CSS, reprinted here in more or less the order in which her tweets appeared thus far:

TwitterPoll: What does this mean to you? !=

TwitterPoll follow-up. What does this mean to you? !=good

TwitterPoll: Let’s remove the equal sign. What does this mean to you !good

yes, yes, I’m asking ultimately how the fuck !important means BANG IMPORTANT when realistically it should mean not important.

re: !important in CSS? Kill it. Specificity to the rescue.

Say it ten times fastL Specificity, specificity, specificity. Forget !important. Write specific selectors sez me. And night night!

I love Twitter. When it is up and running that is… Such a lively place for discussion.

Molly makes an excellent point here. My little position with the !important rule is that I always thought this to be somewhat of a funny-looking construct. It is just as Molly points out – the exclamation point preceding the word ‘important’ is odd, kind of stuck on there, and is especially confusing to those of us coming from that programming background where the ! means ‘not’ – as in != reading ‘not equal’ and that sort of thing.

The construct itself is generally frowned upon in production-level CSS code. The specificity of the !important rule overrides anything with normal inheritance values, and if your code is littered with it then you really need to go back and look at what your rules are doing with regards to the cascade. A good production stylesheet should be free of any !important rules.

I take from Molly’s tweets that she argues in favor of abolishing the !important construct and that people should use the cascade properly. While I understand this position and agree with it on a philosophical level, I think somehow this functionality should be retained. My proposal is as follows:

Change !important to just important, doing away with the confusing exclamation point and instantly making CSS more legible
Make some declaration that user agents should ignore the exclamation point and really just pay attention to the word “important,” for the sake of legacy support. Yeah more detail is needed here, but you get it.
Make validation issue an explicit warning stating that important should only be used for debugging purposes.

How this would look in the wild:

#hyrule { color:blue important; }

Not a big change really, but it gets rid of the somewhat confusing exclamation point, gets us more towards the ideal which is reduced abuse of the rule in question, and promotes better use of the cascade.

Yes that photo is completely random given the context of this discussion, but I thought it was pretty and it reminds me that I need to do a follow-up on my recent Taiwan vacation…