One feature I used to use frequently in CorelDRAW! is conical gradients. The concept is simple: take a linear gradient and wrap it around a central point to create the appearance of a cone. When I switched to Adobe Illustrator (my primary motivation was that Corel’s exporting features weren’t very Web-friendly, but that’s a topic for another day), my main complaint was its lack of conical gradients. While some workarounds are available, none was frictionless, and my designs went without for some time.

A few weeks ago, I watched a video previewing the new “gradient on a stroke” feature of Illustrator CS6. While this feature sounds amazing for a number of reasons, my first thought was to try to use it to create conical gradients. The process is even simple enough to no longer make me long for Corel’s implementation. Here’s how to do it:

1. First, use the Ellipse Tool to draw a circle (hold down the [Shift] key while dragging to create a perfect circle). The circle’s width and height should be half that of the final size you’re looking for; for example, if you want a gradient 100px by 100px in size, create a circle that is 50px by 50px.

   

2. Create a stroke on the circle of the same size as the shape itself. In our example, that would be 50px. As you can see, I prefer to make my stroke and fill dramatically different colors so I can see ensure everything lines-up.

   

3. In the Gradient Panel, click the stroke symbol to select it, then, in the “Type” selection box, choose “Linear”.

   

4. Gradients-on-strokes have three possible display options: “within stroke”, which paints the gradient normally, just on a stroke; “along stroke”, which draws it perpendicular to the stroke’s line, and “across stroke”, which draws it parallel to the line. To create a conical gradient, select the “along stroke” option.

   

This basic process can be extended to create some pretty awesome gradients. Also, don’t forget about Illustrator’s clipping mask feature to add conical gradients to any shape of object:

Have a conical gradient you’re proud of? Share it in the comments!

Note: this post involves replacing default drivers with new, potentially-unsupported ones. Use caution and keep backups of your original drivers just in case.

I recently bought a RocketFish mini-DisplayPort-to-HDMI adapter to connect my work machine, a late-2011-model 15″ MacBook Pro, to my television (when I’m in my living room) and my Dell monitor (when I’m in my office). I chose the HDMI adapter over one for DVI because I can run the signal through my AVR for the TV and it’s considerably easier to plug in an HDMI cable than a DVI one.

My potential enjoyment turned to frustration, however, when I hooked up the Mac and saw this (the banding represents the screen area that is not used by the content being shown):

Apparently, AMD–the manufacturer of the video card my Mac contains–thinks everyone is using HDMI cables with CRT screens, and defaults to a generous amount of underscanning. Consequently, everything displayed on this monitor is “squished”, making crisp text look blurry. Googling for this problem turned up a sorta-but-not-quite-helpful blog post from Dell:

* Open the ATI Catalyst Control Center
* Under DTV (HDMI) 3 Scaling Options or at the bottom left hand corner there is a smaller monitor where you open the configure option
* Select 0% Overscan
* Click Apply

I now have some glimmer of hope that my problem can be solved (at least it’s acknowledged by somebody else), but my Mac is using the Boot Camp drivers for the AMD graphics card, so the “Catalyst Control Center” mentioned in the comment isn’t available. No problem: I’ll just go download it from AMD’s site.

Rats. Seems my video card (from all appearances, a standard Radeon 6750M) isn’t supported by AMD’s drivers. Having encountered this particular pain on nVidia-equipped laptops of yore, I hit some forums to look for alternatives. A succinct poster by the name of “superericla” provides some links to Catalyst drivers that aren’t preceeded by a “verification of proper hardware” step:

• AMD Catalyst drivers for Mobility Radeon (\*.exe, 86.8 MB)

Installing these drivers was a painless, but confusing, process. In short: be patient. Much time was devoted to staring at a blank screen after launching the installer hoping something would happen, then staring again after the installation completed waiting for the control panel to appear. After the application finally obliged me, the process for disabling the annoying default underscan was quite simple:

1. Choose the “Desktops and Displays” category.
2. Scroll to “My Digital Flat-Panels” and click “Scaling Options (Digital Flat-Panel)”.
3. Drag the slider to 0%. On my setup, the un-scaling happened in real-time.
4. Enjoy your new screen real-estate and non-blurred content!

Overall, I’m pleased how easy it was to overcome this particular problem. What experiences have you had? Found an alternate solution or better drivers? Decided to use a DVI adapter instead? Let me know in the comments!

HTML5′s “data” attributes are a great way to store metadata about a particular element in your markup without invalidating your HTML. They’re easy to use (just add “data-myvalue” as an attribute on your markup) and tools like jQuery can access the data stored therein easily. Take this example:

<input id='Email' name='Email' type='text' data-icon='envelope' />

We can get to this data with a simple jQuery call:

var icon = $('a#lnk-email').data('icon');

However, if you’re using ASP.NET MVC’s input helpers (as I am on my current project), you may run into an issue adding attributes to your input elements. As a reminder, the syntax for one overload of the TextBoxFor() method, for example, looks like this:

@Html.TextBoxFor(
    x => x.Email, // A lambda expression pointing to a property on the model
    new {  }) // An anonymous object representing any HTML attributes to apply

The anonymous object above is the source of our problem. Why? That’s an actual block of C# code, where hyphens aren’t allowed inside variable names. So dropping-in a “data” attribute, like this:

@Html.TextBoxFor(x => x.Email, new { data-icon = "envelope" })
//                                       ^ The problem.

…throws a syntax error. Fortunately, the MVC team has provided us with an easy workaround: replace the hyphen with an underscore, and you’re good to go!

@Html.TextBoxFor(x => x.Email, new { data_icon = "envelope" })
//                                       ^ The workaround.

This is both valid C# and renders out to our desired markup:

<input id='Email' name='Email' type='text' data-icon='envelope' />

HTML5′s “data” attributes are an excellent solution for embedding data in your markup, and, thanks to a convenient method overload, even ASP.NET MVC users aren’t left out due to variable naming rules.

For whatever reason, I get very little use out of the “track changes” feature in both Visual Studio and SQL Server Management Studio, which is designed to highlight lines that changed since the last save:

Visual Studio has an option to disable it entirely (Tools > Options > Text Editor > Track changes), but Management Studio lacks this feature. As a workaround, you can set the “Item background” color for these two items to “Automatic” (available via Tools > Options > Environment > Fonts and Colors):

• Track Changes after save
• Track Changes before save

Changing these settings results in a pleasant absence of the “track changes” bar:

It’s worth noting that Visual Studio’s behavior is slightly different. Setting the colors of these two options to “Automatic” maintains the original green and yellow colors instead of making them mimic the background color, as in Management Studio.

Although the design of the CTXNA Web site makes extensive use of images (for browser compatability), I became curious how difficult the style would be to reproduce in nothing but CSS and threw together a demo using JSFiddle:

The complete sample requires a browser that supports CSS gradients and the border-radius, box-shadow, and text-shadow properties; however, older browser users will still be able to recogize the button even if it’s not quite so pretty. :)

Switching your graphics from using images to CSS has some great advantages:

• More flexibility. Modern design techniques typically involve a number of iterations, each one of which can involve a major rework of graphical elements. If your images have already been sliced and placed into your HTML, it can be a chore to re-export them from your graphics tool of choice. Using CSS instead means you can make iterative changes without starting over.
• Fewer requests. Instead of loading a CSS file and several image files, browsers simply load a simple file, cutting down on slow loading times caused by network latency.
• Smaller file sizes. Though our example above is relatively complex, many images can be replaced with CSS with a significant reduction in file size (being text, CSS rules take up less space on disk than graphics). Given the average number of images on Web sites, this can lead to some serious page load time improvements!

Have you encountered sites with good use of CSS in lieu of images? Share in the comments!

NOTE: This post’s code was written for Windows Phone 7 and may or may not work with other versions of Silverlight or WPF.

One of the screens in the Windows Phone 7 app I’m currently working on (we’ll call it CombatForm) contains some combat tools for two separate players, implemented as a parent page with two child controls. These controls–each one an instance of the CombatActions control–need to change their state based on a property of the parent screen (which is in turn manipulated by user input elsewhere in the app). After mulling over several options (including using the application’s event bus and a more synchronous approach of manually modifying the controls’ properties), I decided to use Silverlight’s built-in data binding features to implement this, meaning I needed to create a DependencyProperty.

Creating the DependencyProperty on the CombatActions control was pretty straightforward. Essentially, we’re creating some metadata about the property on the UserControl we want, then using some of the Silverlight API’s calls to expose the property:

public partial class CombatActions : UserControl
{
    // ...

    public static readonly DependencyProperty CanCastSpellsProperty =
        DependencyProperty.Register("CanCastSpells", typeof(bool),
        typeof(CombatActions), null);

    public bool CanCastSpells
    {
        get { return (bool)GetValue(CanCastSpellsProperty); }
        set { SetValue(CanCastSpellsProperty, value); }
    }

    // ...
}

Ideally, I’d like to bind the parent property to the UserControl in XAML, which would have looked like this:

<c:CombatActions x:Name="Actions" CanCastSpells="{Binding CanCastSpells}" />

Unfortunately, I spent more time than I’d care to admit trying to figure out why that wasn’t working. Having given up any hope of a utopian XAML solution, I attempted the binding in the parent control’s code-behind:

public class CombatForm : PhoneApplicationPage
{
    public bool CanCastSpells { get; set; }

    public CombatForm()
    {
        // ...

        // In this example, we're binding the UserControl to a property on this
        // instance of CombatForm, so the DataContext is "this".
        DataContext = this;

        Actions.SetBinding(CombatActions.CanCastSpellsProperty, new Binding
            {
                Source = DataContext,
                Path = new PropertyPath("CanCastSpells"),
                Mode = BindingMode.TwoWay
            });

        // ...
    }
}

Success! The CanCastSpells property on the CombatActions controls can now be successfully bound to the CombatForm‘s property of the same name! The key was to create the binding programmatically (in the code-behind) rather than declaratively (in the XAML).

In the Windows Phone 7 app I’m working on, I’d like to provide some visual feedback for invalid input fields by outlining each one with the user’s selected accent color. Ideally, invalid input boxes would look something like this:

Unfortunately, WP7′s template-based styling model makes this difficult, and the workaround suggestions I’ve found result in significant amounts of markup noise (not to mention adding the necessary XAML for that approach just duplicates Silverlight’s internals).

One solution I’ve found to work well is to simply “stack” a pre-styled Border control on top of the TextBox you’d like to validate and control its visibility programmatically or with data binding (this example uses the former method). The markup is very straightforward…

<Grid>
    <TextBox x:Name="FavoriteFood" />
    <Border x:Name="FavoriteFood_Validation" />
</Grid>

…it’s easy to style to match the Metro UI…

<Style x:Name="ValidationHighlight" TargetType="Border">
    <Setter Property="BorderThickness" Value="3" />
    <Setter Property="Margin" Value="12" />

    <!-- Match the user's accent color. -->
    <Setter Property="BorderBrush" Value="{StaticResource PhoneAccentColor}" />

    <!-- Don't interfere with the TextBox's tappable area. -->
    <Setter Property="IsHitTestVisible" Value="False" />

    <!-- Remain invisible until the user tries to submit bad data. -->
    <Setter Property="Visibility" Value="Collapsed" />
</Style>

…and it’s trivial to show and hide to indicate validity.

private void Validate()
{
    // Perform some incredibly complex validation here, like so.
    bool favoriteFoodIsValid = FavoriteFood.Text.Length <= 32;

    FavoriteFood_Validation.Visibility = favoriteFoodIsValid ?
        Visibility.Collapsed : Visibility.Visible;
}

Note that we’re taking advantage of the built-in Windows Phone 7 style resources so the user gets a customized color for their invalid fields. The Border control’s IsHitTestVisible property is set to False so it doesn’t interfere with users trying to tap in the TextBox, and we’re keeping the Border invisible until the input field is validated.

The end result looks something like this:

Happy validating!

The markup portion of HTML 5 is an incredible leap forward in Web development, but is nonetheless not a brand-new language or technology. As such, bad habits that have crept up after years of working with browser inconsistencies, poor maintenance habits, and so forth continue to exist even in so-called “modern, HTML 5 sites”. In this post, I’ll share some of my own bad habits and how HTML 5 has allowed me to ditch them in favor of much cleaner pages that I don’t mind showing off to my friends.

The Problem.

First, let’s take a look at a typical HTML page I might have written several years ago:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
    <title>My Yucky Site</title>
    <link rel="stylesheet" href="style.css" type="text/css" />
    <script type="text/javascript">
        /* A smattering of JavaScript. */
    </script>
</head>
<body>
    <div id="header">
        <h1>My Yucky Site</h1>
    </div>
    <div id="navigation">
        <!-- Some navigation. -->
    </div>
    <div id="content">
        <h2>A Yucky Section</h2>
        <!-- Lots of content. -->
    </div>
    <div id="footer">
        <!-- A copyright notice. -->
    </div>
</body>
</html>

Obviously, I was in one of those “my HTML must be valid XML!” kicks back then: this hypothetical page needs lots of love and attention.

Let’s get started with something simple: the DOCTYPE declaration:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Fortunately, this one’s easy: this page won’t even be HTML 5 unless we get rid of that nonsense:

<!doctype html>

Much better! Now on to the good stuff.

The Head.

Now that we’re not making our site masquerade as XML (thanks to switching to the HTML 5 document type), we can clean up some other parts, too, like self-closing tags and that odd “xmlns” attribute:

<html>
<head>
    <meta http-equiv="content-type" content="text/html;charset=UTF-8">
    <title>My Yucky Site</title>
    <link rel="stylesheet" href="style.css" type="text/css">
    <script type="text/javascript">
        /* A smattering of JavaScript. */
    </script>
</head>
<!-- Our document's body -->
</html>

HTML 5 also allows us to use a much-improved shorthand for specifying the character set of a document…

<meta charset="utf-8">

…and also provides some default assumptions for file types, like “text/javascript” for script files and “text/css” for style sheets. Here’s what our cleaner <head> looks like now:

<html>
<head>
    <meta charset="utf-8">
    <title>My Slightly-Less-Yucky Site</title>
    <link rel="stylesheet" href="style.css">
    <script>
        /* A smattering of JavaScript. */
    </script>
</head>
<!-- Our document's body -->
</html>

The Body.

Unfortunately, our poor <body> tag is overrun with “div-itis”: we have <div> tags everywhere! Thankfully, HTML 5 provies us with a large number of new tags that express meaning about the content of our site. Here’s what our “old” HTML looks like again:

<body>
    <div id="header"></div>
    <div id="navigation"></div>
    <div id="content"></div>
    <div id="footer"></div>
</body>

Applying some of these new HTML tags, we can clean this up, too:

<body>
    <header></header>
    <nav></nav>
    <div id="content"></div>
    <footer></footer>
</body>

Now our header is represented by a tag actually designed to contain header information instead of a <div> pretending to be one, our navigation uses a tag designed to encapsulate site navigation, and so forth.

The Script.

So far, we’ve focused on cleaning up the structure of our Web page, but what about its behavior (in other words, “JavaScript”)? You’ll notice our “yucky” version’s scripts are inside the <head> tag, but that can cause some nasty side-effects, specifically that all of the scripts therein have to be loaded before the browser will show any content to the user.

A temptingly easy way to fix this (and one that works for most scripts) is to put all of our scripts after the rest of the HTML content. Browsers will load the HTML page and, at the very end, load all of the JavaScript-ey goodness:

<html>
<head><!-- Our document's head --></head>
<body>
    <!-- Our document's body -->
    <script>/* Our script! */</script>
</body>
</html>

However, scripts that need to modify your browser’s behavior or content can sometimes cause what Web developers call a “Flash of Unstyled Content”. Likely the most well-known scripts that are in this category are those that add support for HTML 5 elements in older browsers. What’s that? Don’t tell me I haven’t yet talked about–

Browser Compatibility.

While HTML 5′s markup is designed to (mostly) behave like previous versions, older browsers like Internet Explorer 7 don’t like seeing the new elements–such as <header> and <nav>–and will ignore putting styles on them. To get around this issue, we can use “HTML 5 shims” to trick these browsers into knowing about these elements. Two of the most well-known are Modernizr, which also helps you check for supported browser features like geolocation, and the HTML 5 Shim, which only adds support for the new elements. If you’re using either one of these scripts, it’s okay (and recommended!) to stick them inside your page’s <head> tag:

<html>
<head>
    <!-- Other heady stuff -->
    <script src="js/modernizr.js"></script>
</head>
<body>
    <!-- The rest of our page -->
    <!-- Other scripts -->
    <script></script>
</body>
</html>

Wrapping Up.

Now that we’ve cleaned-up our page quite a bit using many of the new ways we can write markup with HTML 5, let’s see just how much we’ve changed. Once again, here’s our crummy older version:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
    <title>My Yucky Site</title>
    <link rel="stylesheet" href="style.css" type="text/css" />
    <script type="text/javascript"></script>
</head>
<body>
    <div id="header">
        <h1>My Yucky Site</h1>
    </div>
    <div id="navigation"></div>
    <div id="content"></div>
    <div id="footer"></div>
</body>
</html>

…and now our much-improved modern HTML 5 version!

<!doctype html>

<html>
<head>
    <meta charset="utf-8">
    <title>My Awesome Site!</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <header>
        <h1>My Awesome Site!</h1>
    </header>
    <nav></nav>
    <div id="content"></div>
    <footer></footer>
    <script></script>
</body>
</html>

Not only have we removed a lot of noise (making the HTML much easier to read), but we’ve leveraged some new HTML 5 features to make our markup more meaningful, which has positive implications like improving search engines’ ability to crawl your site, helping visually impaired users view your site with screen readers, and making your friendly Web developer coworkers happy. :)