San Bei Ji » Web Development

Coloring the HR element line in CSS

Joe — Wed, 07 Dec 2011 00:37:31 +0000

I never, ever use this element, but HR has been bequeathed new life in HTML5 and I may start using it for providing more thematic break awesomeness to my already blindingly-awesome prose and poetry.

Anyway, someone asked me this question: Is color supported in all browsers by the HR element? To which I replied: “I have no clue. Let me investigate.”

Here’s an initial test:

HR colors I have known... blue:



    red:

    


    green:

Well hambone. Using the text rule for color on WebKit browsers yields no color change. Works fine in all cases in Firefox. IE gives no quarter to the border-color CSS property, but works fine with the text color value. Every browser supports HTML color attributes, but you know that using presentational markup is as wrong as Michelle Bachmann’s views on evolution and vaccination, so you just say no.

So what’s a poor web dev to do? Define a border width:

.red { border:none; border-bottom:thin solid red; }

Replacing the original border-color rule with the shorthand listed here, or just providing an explicit border-width property, will render a consistent 2 pixel line in all browsers. If we just wrote something like border:thin solid red; we’d get a 2-pixel border – see you’d think the HR element is just a line, but in fact the browsers all treat it like a box it seems. So we have to clear it out with border:none; and then add a border-bottom or border-top rule to set a 1 pixel line. If you want different widths, you have arguably more accurate control by only having to argue with one border instead of two.

What… you want to replace that HR with a background image? Good idea. Check out this post at Neatly Sliced for the answer, and gird your loins for the usual IE kludgeries.

A quick book review: Responsive Web Design

Joe — Mon, 14 Nov 2011 19:30:57 +0000

Just finished reading an excellent book: “Responsive Web Design” by Ethan Marcotte. If you build web pages, I want you to read this book. Here’s a few of my thoughts on what I just learned, and why you should read this one too.

The book begins with an overview of the evolution of page layout in web design, starting with it’s roots in printed page design and moving on to today’s reality that there is a multitude of screens and devices out there, with more on the way. We cannot predict what type of device our readers will show up with, and must adjust our belief system (if we have one) to accommodate the new realities that the various screen widths and mobile device sizes present us with.

The second chapter discusses the idea of designing within the constraints of a flexible typographic grid. Grid systems are somewhat of an artificial constraint that designers place on themselves to provide balance and symmetry to page layout, and on screen a new challenge is presented in that the page size is no longer fixed. The main takeaway here is to design content in flexible porportions to the variable screen widths that might be used to access your web pages. Mr. Marcotte puts forth some simple, accessible ideas for developers to leverage, making text more readable on unknown devices by putting forth a formula that I’ll repeat here mostly for the purposes of getting my own head wrapped around it:

target ÷ context = result

To decode Mr. Marcotte’s example, he begins with an assumption of a base font size of 16px. The headline in the comp is defined to be 24px. So to make it flexible, divide:

24 ÷ 16 = 1.5

And so the headline should be defined as 1.5em. Simple and elegant rule of thumb. Now we just need to remember to do it.

Chapter 3 applies this principle to flexible images, and expands upon it. There is the inevitable Questionable Functionality Challenge™ presented to us by Internet Explorer, which is quickly defused. That’s a lot of ink to dedicate to an obsolete web browser and the example demonstrates where the real problem lies by showing how awful text looks in resized images. But you aren’t locking up text in your images, right? I know, I know, it’s an academic example and clearly illustrates the failings of IE’s image resize capabilities. Let’s move on.

Chapter 4 introduces media queries. We’re finally at what I consider to be the coolest and most important part of the book – how to progressively enhance your web page layouts through the media query construct. Mr. Marcotte makes the argument in favor of using the min-width property instead of things like max-width (which tends to yield excessive code) and min-device-width (which only pertains to devices and doesn’t take into account variable web browser windows.) The max-width property is introduced for those that want to stop the insanity. (I do know people that expand their web browser to the full width of their 27″ high resolution monitors.)

Chapter 5 pulls it all together with strategies to integrate responsive design into your team’s workflow; how to make your design process itself a responsive one. He builds the case for Luke Wroblewski‘s “Mobile First” philosophy (a case that was already built up a bit in chapter 1) and finishes it all of with how to incorporate progressive enhancement using JavaScript to selectively pull in a slideshow component only when JavaScript is available and all the stars are in the proper alignment.

Overall, my belief has always been somewhat of the philosophy that there should be just “one web”; no “mobile web” or any other sort of alternate web reality that we should somehow slip into. Today’s mobile devices that are in fact being used to access the web are billed as fully capable web browsing devices, and indeed they are. Why deliver a shrunken-down version of your website just because they have a 3″ wide screen these days? It no longer makes sense in most cases; just reposition your content to accommodate their view. Every chapter includes simple, usable techniques that work, and I feel that these gems of advice should be a core part your future projects.

Lastly, I am very thankful for the appearance of the A Book Apart series. Each one of these volumes is, I believe, how a tech book should be: concise, full of valuable, practical, actionable information. I have read several of these so far, and each one has been a hit. I look forward to more.

Annotate your Rails model

Joe — Fri, 11 Nov 2011 20:19:37 +0000

I just discovered this handy little gem called annotate. Run it and it’ll insert a comment in all of your model files at once, outlining the schema. This is incredibly convenient when working with your Rails models to be able to see the data and types right there in the top of the file.

Here’s what my Noober (/app/models/noober.rb) model looks like by default:

class Noober < ActiveRecord::Base
end

Spartan as always. Let's give ourselves something to look at with the annotate command. First, include annotate in your Rails 3 project in the Gemfile:

group :development do
  ...
  gem 'annotate'
end

Run the install command to update your gems:

$ bundle install

Run it from within your project directory:

$ bundle exec annotate --position before
Annotated (1): Noober

And the result should look something like this in your models:

# == Schema Information
#
# Table name: noobers
#
#  id         :integer         not null, primary key
#  firstname  :string(255)
#  lastname   :string(255)
#  email      :string(255)
#  nooblevel  :integer
#  created_at :datetime
#  updated_at :datetime
#

class Noober < ActiveRecord::Base
end

Awesome! Now I can see quickly which parts of the model I need to work with and add my code without having to peek at the database:

# == Schema Information
#
# Table name: noobers
#
#  id         :integer         not null, primary key
#  firstname  :string(255)
#  lastname   :string(255)
#  email      :string(255)
#  nooblevel  :integer
#  created_at :datetime
#  updated_at :datetime
#

class Noober < ActiveRecord::Base
    attr_accessible :firstname, :lastname, :email
    validates :firstname,  :presence => true
    validates :lastname, :presence => true
    validates :email, :presence => true
end

Works well for me!

When Can I Use posts a usage table

Joe — Mon, 19 Sep 2011 15:50:19 +0000

When Can I Use has posted a nice browser usage table, which includes mobile browsers and a breakdown by browser version. Compared with the browser market share analysis at Wikipedia, the numbers do line up quite well for the major categories, although there are some interesting discrepancies when you get down into the weeds.

I love looking at statistics and seeing what jumps out at you. What I see from these numbers today, here in September of 2011, is this:

IE is only 39% of browser market share now. Remember ten years ago? Yeah, times have changed.
Chrome is doing quite well. It’s going to overtake Firefox at this rate. 21% – that’s amazing.
Going by the When Can I Use analysis, if you combine Chrome, Safari, iOS, and Android, you have about 29% market share for WebKit browsers.
If these trends continue, and I see every indication that they will, Google Chrome will become the dominant browser platform sometime in the first half of 2012.

Fascinating. I’m going to need to make more popcorn.

Some Google+ thoughts

Joe — Wed, 27 Jul 2011 18:33:55 +0000

No question, Google+ is Google’s most successful foray into the whole social media arena. I am sure this one will succeed where other initiatives have failed. I’m glad to see it taking off. But a few things need to be worked out for it to achieve it’s full potential. Here’s my unsolicited feedback:

I think the first thing I’d like to see is for all my Buzz content to go directly into my stream. I don’t want two streams, nor do I want to go look at a separate place for all the people I follow on Buzz vs. Google+. It is an extra step that I don’t have time to take.

Another thing I’d like to see is that my activity stream selection should remain persistent. Currently the default stream is for everybody in my circles, but I would much rather have that be filtered to whatever circle I choose or was last viewing.

In fact, get rid of Buzz. And figure out how Google Reader and Google Bookmarks play in with this. Integrate them, or get rid of any overlap or confusion. Do it now before the problems become worse. Don’t wait.

I would really like a way to have my Twitter posts show up in my Google+ stream. This again is a time issue – I don’t want to spend a lot of time tending my content on both networks. It’s largely the same crowd for me anyway. If I have a choice between one or the other, I’m going to spend the time on Twitter because that’s where most of my contacts are. On the other hand if my content is posted in both places, then I can see if there are responses and alerts in the Google nav bar whenever I’m using Gmail or Calendar, which would be fine.

The toolbar changes lists links for Web, Images, Videos, Maps, and News if I’m looking at one of those properties, and Calendar, Documents, Photos, and Reader if I’m in one of those areas. Gmail and Web are listed in both, although the Gmail toolbar uses the docs/photos/reader listing (inexplicably in gray instead of black I might add) and Web lists the web/images/videos set. Sometimes links open in new windows. Sometimes they don’t. Who knows or cares what will happen next? I’m feeling lucky! Sigh.

The mobile version of the site doesn’t let me +1 comments. Overall I’d like to see more functionality built in to the mobile version of the site.

The mobile app on iOS seems like an early beta. I opted out of using geolocation when I first launched it and now there’s no way to get it back.

There it is – my loving feedback. Fix all that and I will be back. xoxox -J.

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.