This has recently become even harder to do with Microsoft’s attempt to force-feed browser updates – at least to those on Windows 7 & 8. And while I applaud this effort, it has also complicated matters even more. I recently fired up my copy of Parallels and loaded a Windows 7 image that I use to test IE9… only to find out that IE had updated itself to version 10! Thankfully, Microsoft has begun to provide “locked” VM’s for testing purposes. You can find them at: http://www.modern.ie/

Of course, IE has had a method of testing in its Developer Tools for several versions now which allows you to “fake” which version of IE you are running. The problem with the feature is that there are two different modes, and it’s hard to tell (at least for me) what the difference is between the two. So, in the hopes of saving some hair pulling, here’s an explanation and example.

I was recently assisting my wife, Stephanie, on a promo page for her company, Contatta. On the page, they wanted a streamlined (i.e. single page) process for signing up prospects, and we chose to build the experience like an image slider. In keeping with best practices – and the fact that they only wanted IE9+ support, we chose to use CSS3 transitions to generate the motion and state changes. For the four “states” of the page, we created a wrapper div that was set to a fixed width/height and set to overflow:hidden. All of the “elements” that will “slide” in were set to position:absolute and transform:translateX(125%). To create the illusion of movement, we’ve also created a class that specifies transition:transform .5s linear 0s. Note: I’ve removed the vendor-specific prefixes.

To slide the element into view, a class is applied (or removed) that changes the translateX() value between -125%, 0 and 125%.

As you can see it works great in IE 10 – and all kidding aside, Microsoft has done a great job adding HTML5 and CSS3 features to IE 10. But, as you might know, transitions (the “animation” of the form) were not supported in Internet Explorer 9. Since my version of IE9 had upgraded itself to IE10, we needed a way to see what the lack of transitions in IE9 would do to the experience. Enter the developer tools…

As you can see, when we changed the Browser Mode to IE 9, the browser still transitioned (animated) the form – but IE 9 doesn’t support transitions! It’s not until we changed the Document Mode to IE 9 that the transition no longer happened.

Browser Mode defines the User Agent – what IE tells the server it is. Document Mode on the other hand determines “what” or “how” IE  will render the page.

Using logic, we could just switch the Document Mode and think we’re “good to go”. But that’s not true either… as you can see below:

As it usually happens, after the page was built, “the powers that be” decided that they, in fact, did want IE 8 support. Which meant that not only did we have to come up with a solution, we needed to test it too.

There are a number of ways to serve alternate CSS to IE, but we chose to use an IECC (Internet Explorer Conditional Comment) – a stylesheet that is only shown to IE versions less than 9.  As you can see, when we switch the Document Mode to IE8, we get craziness because IE8 does not understand the transform property. As I mentioned earlier, we’ve used the translateX() value to move the form “off screen”. So, for these older versions of IE, instead of using tranform:translateX(125%), we need to set the left (or right) property of the element.

Simply switching the Document Mode, however, did not tell the browser to read the IECC. As far as IE was concerned, it was still IE 9 (or 10 if we had left it at its default). In order to truly emulate IE 8, loading the page and its resources properly, we have to set the Browser Mode as well as the Document Mode.

While I still try to test on an actual version of Internet Explorer, the fact that the Developer Tools allows me to quickly test functionality as well as look and feel, while remaining in IE 10 is a great time saver… once I figured out what the two modes meant!

When I updated this blog to “HTML5″, I took the leap and used CSS3 everywhere that I could. This post area was a prime candidate for border-image. For the uninitiated, border-image allows you to use a single image as both a border and fill for an element. All you need to do is specify how much of the top, left, bottom, right of the image will be the borders, and how those pieces should fill each area (stretching or repeating).

Diagram illustrating the cuts corresponding to the value ‘25% 30% 12% 20%’ from the W3C specification

If you’ve ever used Fireworks, Illustrator or Flash, they all have a feature known as 9-slice scaling. Border-image is basically the same thing, but done on the fly via CSS. The rule for all posts here looked like this:

.post {
margin: 0 0 40px 0;
-webkit-border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
-moz-border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
border-width: 29px 50px 55px 32px;
}

In keeping with best practices, you can see that I have listed the official property (without the vendor prefix) last, so that as browsers drop the need for the vendor prefix, they will simply read the last property – and the change will be seamless. Except in the case where all browser vendors are rendering a property different than the spec—thus lulling us into believing their rendering is correct when it is not.

Don’t adjust your screen! This is what every post looked like!

There is actually an additional value in the spec called “fill”. The “fill” keyword instructs the browser to render the middle of the image as the background of the element. Without the keyword, the middle remains transparent (ie, the background-image or color is rendered instead). If there is no background-image or color defined for the element, it is simply transparent. Till now, all browsers have ignored the lack of the “fill” attribute and rendered the middle regardless. The code above worked perfectly—but it was based on improper rendering.

Chrome (actually, the change was made in Webkit) has recently changed their implementation of the border-image “fill” value as described in the spec. This is good, but it will ultimately break a lot of sites since many of us left the fill attribute off since vendors were ignoring it. Sloppy, sure. But it worked… until today.

So, dive back into your code and add the “fill” keyword if your site suddenly looks like swiss cheese. But you’ll want to (for now) only add the fill value to the non-prefixed version, as the addition of the value currently breaks Firefox if added to the -moz version of your rule (hat tip to @chriseppstein for that little nugget). My post class now looks like this:

border-image: url(images/article-background-stretch.png) 29 50 55 32 fill round round;

“fill” tells Chrome (and eventually other browsers) to render the center of your image as the background of the element. The two “round” values instruct the browser to tile the images on the x- and y-axis.

To illustrate the problem, have a look at this simplified example:

The two columns of text each have a transform: translateY(-100px); applied to them on :hover. Additionally, they are both set to transition the effect – thereby “scrolling” the text up by 100px. Simple enough. And if you are looking at this in anything other than Firefox, both columns behave the same. Of course, if you are looking in Internet Explorer, you won’t see anything because even with IE9, transforms are not supported. UPDATE: I’ve added the -ms- prefix for transforms/transitions, and in IE10 this works as it does in the other standards-compliant browsers.

Being that I like to write CSS shorthand when possible (but am moving back away from it for many CSS3 techniques, especially backgrounds), I wrote the transition line in shorthand. Simply transition: transition 2s linear 0; (with the browser specific code omitted for the moment). Testing in Webkit (which is what I use as my initial dev environment browser) showed everything was working properly. So, of course, I didn’t think more about it until the project was basically complete and I began the round of testing in Firefox, Opera and, yes, IE.

I knew that IE was not going to perform the “scroll”, but I was completely shocked to discover that FF was simply “jumping” (as you can see in the left column of the example) – exactly the same behavior as IE. I scratched my head in wonder as I ran over to CanIUse.com to make sure that my summer vacation in the Caribbean sun hadn’t confused my recollection about FF’s support of the transition property. I was completely baffled, and, in an effort to get to the bottom of the issue, I broke the shorthand out – going from -moz-transition: -moz-transform 2s linear 0; to
-moz-transition-property: -moz-transform;
-moz-transition-duration: 2s;
-moz-transition-timing-function: linear;
-moz-transition-delay: 0;

And suddenly things appeared to be working in FF. This is also what you see above. The left column uses shorthand, the right column uses the longhand notation.

Okay, the simple assumption was Firefox doesn’t support shorthand – but I knew for a fact that that couldn’t be. After looking at the code for the umpteenth time, I was as baffled as when I wrote it. But a shout-out on the Twitters revealed the answer… no “s”.

The “0″ at the end of the shorthand doesn’t have a unit. And with that, Firefox fails to execute the entire line. But wait, the longhand version doesn’t have a unit, so what gives?! Well, that line is actually being ignored as well. But because it’s longhand, the property, duration and timing-function are all being executed. To confirm, I changed the -delay property in the longhand version and, sure enough, no delay. Going back to the shorthand version, I added the “s” to the “0″, and, problem solved!

Of course, this begs the question “why”, which a number of us spent Sunday afternoon discussing on the Twitters. Tab Atkins confirmed that, in fact, the spec requires the unit on instances of time. So, actually, the problem isn’t a Firefox issue, but rather the fact that Chrome, Safari and Opera are “allowing” us to be slack in our code. Hmm. My position is, the default is “0s”, and in no other instance am I required to type the unit when specifying “0″, so why do I have to here? But who listens to me anyway?!

I happily added the stupid “s” and will definitely never make that mistake again… Oh, and I invoiced myself for several lost hours and frustration…! We’ll see if I pay the bill. ;-)

Actually, one of the best features of Dreamweaver, Live View, can be used in a way that you might not have thought of. We know that Live View allows us to see the page, rendered by the embedded Webkit engine, exactly as it would appear in Webkit-based browsers. But there is also an interesting text field that becomes active in Live View at the top of the document window – an address field – just like in a browser!

And yes, you can type any URL into the field. Dreamweaver, just like the browser, will load the page in Live View. If you are in Split View mode, you might notice that the actual HTML from the page you are viewing is not there because Dreamweaver is still showing the code of your original page.

But click the Live Code button, and Dreamweaver will display the generated source of the page you are looking at — complete with all the corresponding CSS and Javascript files appearing in the related files bar. It’s a great way to learn from what others are doing.

To get the most out of this feature, I have simply created a “tools page” with links to all of my favorite online tools. In order to interact with your local tools page, you will need to choose “Follow Link” or, even better, “Follow Links Continuously” from the Live View Options menu.

So now, when I start Dreamweaver, I immediately open this page, turn on Live View, enable the Follow Links Continuously option and then go about working on my projects. Any time that I need a gradient, transition or anything more complex that I don’t want to “think about” how to create, I switch to my “tools page” tab where all my online friends are ready to help. I can then easily copy their code into the stylesheet that I am working on.

Let me know what you think about this – or if you have an even better “Best Tip Ever”!

HTML5 / CSS3

For those that missed it, shortly after the release of Dreamweaver CS5, the team released an update on Adobe Labs which provided initial code-hinting support for HTML5 and CSS3. This was later baked into an update to the core product. With Dreamweaver CS5.5, the team has updated the code-hinting database to reflect the current state of the HTML5 elements, as well as updating the WebKit browser engine embedded into Dreamweaver’s Live View. This means that things like native HTML5 video can be “seen”, but also interacted with while you are designing your page.

For the CSS3 aficionados, you might remember that the HTML5/CSS3 update last year added support for vendor-specific prefixes. This meant that you could type a dash, and Dreamweaver would codehint “-moz-”, “-o-” and “-webkit”-”. Choosing one of the vendor-specific prefixes would then in turn display a list the list of CSS properties that that specific prefix could be used with. Dreamweaver CS5.5 not only continues this functionality, a fourth vendor-specific prefix has been added, “-ms-”, because now Internet Explorer 9 has adopted its own prefix.

Additionally, the CSS Panel has been updated with a couple of very nice enhancements. First, the dropdown list now includes all of the new CSS3 properties and any vendor-specific properties that you may have added to your rule show up in the assigned properties list for easy editing. Second, new fly-out dialogs have been added to allow you to quickly specify values for box shadow, text shadow and border radius. Finally, the color picker has been updated to support the RGBa and HSLa color spaces — and even translate between hexadecimal values and these new color spaces.

The Multiscreen Preview which was added with the HTML5 update, has also been improved and now eases the process of creating media queries and their attached stylesheet files. But taking the idea one step further, the Window Size manager (a long forgotten Dreamweaver feature) now includes the ability to change the Design View and Live View to reflect only the desired stylesheet. Yes, this means that you can continue to work, modifying HTML, CSS and Javascript, while looking at the way the page will actually look under various scenarios! If you are serious about targeting multiple screen sizes/dimensions with CSS, this feature will have you cheering!

jQuery Mobile

And if you are into targeting mobile devices, the jQuery Mobile framework helps ease the process of creating mobile-optimized pages that actually “feel” like a native application. As a proud sponsor of the jQuery Mobile project, the Dreamweaver team has been actively contributing back to the framework. And Dreamweaver is all the better for it, as Dreamweaver CS5.5 adds a jQuery Mobile widget section to the Insert Panel, allowing you to easily add UI widgets from the framework to your page — and getting started is just as easy with the new jQuery Mobile starter layout. Use the Window Size manager to set your Design/Live View to the size of a mobile phone and it’s as if you are almost working on the phone itself.

And speaking of jQuery in general, Dreamweaver CS5.5 builds upon the enhanced Javascript code-hinting introduced in the previous version by providing intelligent code-hinting for the full jQuery framework.

Phonegap

Having spent the last six or so months attending conferences featuring talks about native application development with HTML/CSS/JS, I can personally attest to the popularity of the Phonegap framework. This simple, yet powerful, framework is there to solve one simple problem, the actual packaging of your HTML, CSS and Javascript into a native application for iOS and Android devices. And Dreamweaver CS5.5 includes built-in access to the framework — meaning, once you have your application looking and functioning like you want, a simple command in Dreamweaver can pass the entire “site” off to the Phonegap framework, packaging it up for deployment, or, if you’re in the middle of development, you can interact with your application using the iOS or Android simulators included in the respective platforms’ SDK.

Read more, see more

I have to admit that I’ve been looking forward to finally being able to show this wickedly evolved version of Dreamweaver off in public! And, that’s what I will be doing quite a lot over the coming months. Together with my good friends and colleagues, Terry White, Jason Levine and Paul Trani, I will be on tour around the world throughout the rest of April, May and June. You can see dates in the right hand column of this blog — or, read more about the tour and get registered on our Creative Suite Evolution Tour page. If you can’t make it to one of our tour stops, I’ve also recorded a series of videos showing off all the shiny new features.

Of course, this release is not just about Dreamweaver — there’s new stuff for Flash developers, video and audio professionals, as well as some wickedly cool developments in the InDesign world. So, be sure to check out Terry’s blog to get up to speed on publishing from InDesign to tablets. Jason will be spreading all of the new video and audio love (any Audition fans out there on the Mac platform?), and Paul will be sharing all the new developments around Flash and how this version is raising the bar on multi-screen development for applications and games.

As always, be sure to visit Dreamweaver’s home on Adobe.com for a complete list of features, as well as pricing and upgrade information.

There are several approaches to provide this fallback, but the “recommended” way to do this is as follows. We begin with the <video> element, and then a list of <source> elements providing the multiple encodings. Of course, you have to remember to list the MP4 file first, because iDevices are so damned arrogant that they won’t look further if they don’t see their desired format first. Not that Firefox is much better — if you don’t provide an ogg-encoded video, Firefox won’t fall back to the Flash video. Which, of course means you must encode your video in two formats (at least for now, as we wait to see the impact/support for WebM). Finally, you need the <object> element for Flash which loads and plays the H.264 video in a SWF wrapper.

<video  height="270" width="340" controls>
<source src="assets/video/odysseyAdv.mp4" type="video/mp4" />
<source src="assets/video/odysseyAdv.ogg" type="video/ogg"/>
<object id="FlashID2" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="340" height="270">
  <param name="movie" value="assets/video/videoPlayer.swf"> <!-- other parameters intentionally omitted -->
</object>
</video>

This got me to thinking… there’s got to be an easier way to deliver video to everyone – especially given that I don’t (currently) have any way to encode ogg or webm video from within Creative Suite 5. Since we are already encoding video into H.264 for consumption in Flash, couldn’t we just stop there? With the penetration of Flash at over 96% on desktop computers, Flash is the predominent video delivery vehicle on the desktop web. On mobile, Flash is already available both in the browser, as well as via AIR, on Android devices and will soon be available on other smartphone platforms like RIM, Palm, Nokia – so delivering via Flash is viable. So it’s only the iDevices that seem to be a problem – but the solution is so simple it’s almost laughable that we haven’t thought of it before.

For years we have “sniffed” for the presence of the proper Flash Player version on the desktop, and provided the opportunity to do an express install to update to the most current version. And for visitors without the Flash player, we’ve even provided alternate content such as the Flash Player badge and verbiage to suggest that the visitor install Flash. Hello, solution!

Instead of burying the Flash version of the video in the <video> element as a fallback for Internet Explorer 8 and below, we can provide Flash as the first option, and fall back to the native <video> element for iDevices.

<object id="FlashID2" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="340" height="270">
<param name="movie" value="assets/video/videoPlayer.swf"> <!-- other parameters intentionally omitted -->
<!-- The browser displays the following alternative content for users with Flash Player 6.0 and older. -->
<div>
<h4>You must be on an iDevice, because you are seeing native HTML5 video — everyone else sees the video in the Flash Player!</h4>
<video  height="270" width="340" controls>
<source src="assets/video/odysseyAdv.mp4" type="video/mp4" />
<source src="assets/video/odysseyAdv.ogg" type="video/ogg"/>
</video>
</div>
</object>

You can see that I’ve simply put the <video> element in the place provided for alternate content. And, if you want, you can still provide all three video formats (mp4, ogg, webm) in case someone on Firefox has a Flash blocker turned on, for example. But if you only want to encode once as H.264, this solution is so simple, you’re probably kicking yourself as hard as I was when I “discovered” it.

Don’t believe me? Here’s an example that shows the native video with Flash fallback and there’s also a link to the Flash with native video fallback. And if you have any problems with these examples, definitely let me know!

For all the excitement surrounding HTML5, it seems that the idea of “replacing Flash” for video delivery is the one that gets everyone going. But, as is pointed out in those two articles (and numerous others), it’s just not that simple – especially as long as there is a hefty majority of users on Internet Explorer 8 and below. If history is any indication, it will be many, many years before those browsers will disappear. I was recently speaking with some attendees at An Event Apart in Minneapolis who informed me that their IT department had just decided to move the entire organization (a large one, but one who I will not name for obvious reasons) to Internet Explorer… 7!!! Yes, S E V E N! I asked why on earth they weren’t moving to 8 and was told that they had begun testing internal apps on 7 “just before 8 was announced” – and they’d put too much work into it, and would have to start all over on 8. Sheez… but that is the reality in a large part of the corporate world.

Adding to that continued need for Flash are also concerns about DRM, multi-bandwidth delivery, as well as the simple fact that it is far easier for the average web designer/developer to customize a video experience in Flash. Oh, and if the client wants subtitles, cue points, video synchronized with our content it all becomes even more difficult. Not necessarily impossible, just difficult. And at the moment, there’s not even any tooling to help ease the pain. I’m sure it’ll come, and I’m also sure that every single point that I could ever dream up will be addressed – eventually.

For now, we live in a world that requires a multifaceted video approach, and thanks to the HTML5 Pack for Dreamweaver CS5, we can not only build pages using HTML5 elements and style them with CSS3, we also can add HTML5 video. But there are a few things that you need to be aware of in order to deliver a seamless video experience in HTML5, as well as provide a Flash alternative for IE. Let’s take a quick look…

Are you using HTML5 video today? Still using Flash? Join the conversation – I’d love to hear your thoughts…

In the following video, I show you how to use some of the really popular new properties – like using border-radius to add rounded corners, transform to rotate elements and transitions to create the illusion of an animated rollover.

There is a definite caveat that I want to make sure to mention – since CSS3 (and HTML5, of course) is still being developed, not all of the CSS3 properties are available in Dreamweaver CS5 (and in Live View some properties do not render). But even with that caveat, Dreamweaver CS5 now really rocks with CSS3. And again, if you’ve not looked at Dreamweaver lately, you can always download a 30-day trial.

During the keynote session at the Google I/O Conference in San Francisco, Adobe’s CTO, Kevin Lynch, demonstrated an extension to Dreamweaver CS5 which not only adds the new HTML5 semantic elements, but also properties for CSS3, to the authoring environment. With this addition, Dreamweaver CS5 users are provided with code hinting for HTML5 and CSS3 in Code View.

Of course, HTML5 and CSS3 are not “finished” yet, and as such, the team can’t “know” what’s going to be in the final specification. Therefore, the extension provides support for the elements and properties that are “the most complete” at this time. In other words, the elements and properties that, not only appear to be “mature” in the W3C specifications, but that are also gaining support among the browser makers. To this end, basic code hinting support is provided for these CSS3 properties specific to individual browsers (-moz, -webkit and -o).

As a page comes together from the code perspective, it’s also important that we see how that code is being rendered, and this is an area that Dreamweaver has truly shined over the last several releases with its Live View feature (an implementation of WebKit). And with the new extension, the underlying engine of Live View gets an overhaul to allow for the rendering of these new semantic elements, including the much hyped <video> and <audio> elements, along with rendering support for some of the most common CSS3 properties.

And for those looking for a little help in getting started, the extension adds a few new layouts to the CSS Starter Layouts (File>New) which have been marked up with the new HTML5 semantics.

Of course, there’s still work to be done – and rest assured, as Lea Hickman points out in an article in the New York Times, the Dreamweaver team is hard at work and laser-focused on creating the best environment for HTML5 and CSS3 development. Stay tuned for more news and updates as they become available. And if you haven’t already done so, download the Dreamweaver CS5 trial for yourself.