Blancer.com Tutorials and projects

Today we’re concluding our three-part video introduction to the fundamentals of photography. This final instalment will be investigating white balance, ISO, and the relative benefits of RAW and JPEG.

---

Video Outline

In this final video, we’ll be looking at White Balance, ISO, and the benefits of shooting RAW over JPEG:

• White Balance: Investigating presets and how they work, along with when you should choose to use a particular setting over another. We’ll use one photo to see how each different White Balance setting affects the outcome.
• ISO: What is ISO, what’s a “stop”, and how can it help you shoot in low light conditions? We’ll also investigate the trade off with ISO – noise.
• Benefits of RAW: What are the different file formats available on your SLR, and why does RAW have an advantage over JPEG?

---

Watch the Video

---

How Has This Series Helped You?

I’d love to know how useful you’ve found this “Introduction to Digital Photography” series. Even if you’re not a “beginner”, let us know whether you’d have liked to have this guide available when you were first starting out. Your thoughts are really appreciated!

Much has been written on the big ticket changes in HTML5, like forms, semantics, and media, but information on the less splashy changes is sparse. While global attributes aren’t the most sexy change of HTML5, they are the change that you will be using over and over and over as you migrate to the new specification.

---

Introduction: What is a Global Attribute?

While the term attribute relating to HTML might be a bit fuzzy to you, you certainly use them with almost every element that you write. HTML attributes give elements meaning. They also give context. They are both the adjective and verb for an element, if you think of the element as the noun. For instance:

    <div></div>

Doesn’t really have much meaning. It’s a division of the page, and that’s it. When we add an attribute though, it does have meaning:

    <div id="foo" class="bar" style="color: red" title="FooBar To The Rescue"  dir="rtl" lang="en-US" tabindex="1" accesskey="F"></div>

We now have a division that is “Foo” with a class of “Bar”, which has a color of red, a title of “FooBar to the Rescue”, is displayed right to left, is to be read in US English, and when you press the tab button or “F”, it’s the first element to have focus. It’s basic, I know. The attributes are all those things that give elements meaning. The difference in HTML 5 from previous versions of the specification is there are attributes that can be used on any HTML element. These are now global attributes. Beyond the ones illustrated in the example above, there are some new ones that are global as well which will expand the possibilities beyond just boring peanut butter.

“HTML attributes give elements meaning. They also give context. They are both the adjective and verb for an element, if you think of the element as the noun.”

---

Common Attributes: Which Ones Are Now Global?

This is a relatively minor change in HTML 5. The attributes id, class, style, title, dir, lang, accesskey and tabindex are now valid attributes to have on any HTML element. You want to give a meta tag an id, that’s valid now. It’s even valid to give that same meta element a direction, language, class or any global attribute for that matter. While they might not have meaning at first blush, it’s perfectly valid to define them in any tag that you feel necessary.

    <meta name="description" content="FooBar, making me feel like it is actually FUBAR." id="foo" class="bar" style="color: red" title="FooBar To The Rescue"  dir="rtl" lang="en-US" tabindex="1" accesskey="F">

The above example is perfectly valid in HTML5. That said, where there is no reason to use an attribute, and it looks silly, perhaps the best course of action is to not use that global attribute. A tabindex on a head element might not be the best use of time and energy. The important part to understand is not the odd case of putting a global attribute in something that doesn’t quite make sense, but rather the fact that they are available in any element.

Each of these were common attributes in the past, and while their use were restricted somewhat in the past, you probably already thought of them as global. I actually had to look up id, because I couldn’t think of an element that you couldn’t use it (base, head, html, meta, script, style, title). The old common attributes are just half of the new global attributes though.

---

Edit Inline: The Contenteditable and Spellcheck Attributes.

The first of the new attributes to look at are contenteditable and spellcheck. They are not mutually exclusive and you can use one without the other, but for the purposes of illustration, it makes sense to look at them at the same time. Both of these attributes do what their names imply; they allow an element to be editable (contenteditable) or allows / disallows spellcheck on content. Let’s start with contenteditable:

Let’s look at number handling first:

    <article id="id">
        <p>You can not edit this paragraph.  I am happy, and and just sit here with no regrets.</p>
        <p contenteditable="true">This paragraph you can edit.</p>
    </article>

In this snippet, we have one paragraph which is not editable, and one that is. When you click on the non-editable paragraph, it works as you would expect by highlighting a word, etc:

However, when you click in the editable portion a whole new world opens:

The paragraph now becomes editable simply by adding the contenteditable attribute. It gets even cooler when we start using the contenteditable with multiple elements. Let’s look at a larger snippet and see what happens.

    <article id="edit_test"  contenteditable="true">
        <header>
            <hgroup>
                <h1>Let's See What Happens</h1>
                <h3>Does every element become editable?</h3>
            </hgroup>
        </header>
        <p>You can edit this paragraph now.</p>
        <p>You can edit this paragraph as well.</p>
    </article>

We start with something that looks like this:

When we focus the article element though, we have the entire span editable:

Furthermore, we can style the box (for lack of better term) using the CSS3 pseudo class of :focus

    #edit_test:focus { background: #eee; padding: 1%; }

and it will look something like this:

Final notes about contenteditable. There are three basic conditions that it takes: true, false, inherit. You can nest contenteditable conditions with nested tags. For instance, if we do something like:

    <article id="edit_test"  contenteditable="true">
        <header>
            <hgroup contenteditable="false">
                <h1>Let's See What Happens</h1>
                <h3>Does every element become editable?</h3>
            </hgroup>
        </header>
        <p>You can edit this paragraph now.</p>
        <p>You can edit this paragraph as well.</p>
    </article>

We would be able to edit the paragraphs in the article, but not the header group. Since this is a global attribute, you could theoretically add contenteditable to your body element, and then pick and chose the elements which are not editable in the document.

The spellcheck attribute goes along with the contenteditable, but it also can be used where your user might interact with your document, for instance forms. The spellcheck attribute is assumed on, unless you say otherwise:

    <article id="edit_test">
        <header>
            <hgroup>
                <h1>Let's See What Happens</h1>
                <h3>Does spellcheck work?</h3>
            </hgroup>
        </header>
        <p spellcheck="false" contenteditable="true">Spell check off.</p>
        <p spellcheck="true" contenteditable="true">Spell check is on.</p>
    </article>

As you can see, when we have the spellcheck set to false, we do not get an indication of a misspelled word, but with it set to true, we do. Very simple functionality. From my tests, browser implementation is a bit raw, but it does work now.

---

Adding Behavior: The Hidden Attribute.

Another new global attribute is hidden. It basically does the same job as “display: hidden” does with CSS but within an element. The advantage to this, it gives a semantical meaning to the element that it is not relevant at this moment in time. Therefore, screen readers, etc., would not mention the element in the hidden state when it would with a style of “display: hidden,” since that is dealing with its presentation. It is a boolean attribute, therefore, false is the assumed state and you only need to add the attribute name to the element that you wish to hide.

    <article id="hide_test">
        <header>
            <hgroup>
                <h1>Let's See What Happens</h1>
                <h3>Can we hide elements?</h3>
            </hgroup>
        </header>
        <p>We can see this paragraph</p>
        <p hidden>We can't see this paragraph</p>
    </article>

---

Dragging Elements: The Draggable Attribute.

HTML5 implements a new “Drag and Drop” API. While the specifics of the API are a bit out of the scope of this tutorial, the attribute to allow something to be dragged is not. Any element that has draggable set to true, can be dragged:

    <article id="drag_test">
        <header>
            <hgroup>
                <h1>Let's See What Happens</h1>
                <h3>Can we drag elements?</h3>
            </hgroup>
        </header>
        <p draggable="true">We can drag this paragraph.</p>
        <p draggable="false">We can't drag this paragraph</p>
    </article>

Without any javascript you can see the difference in browsers that support draggable. When set to false, if you mousedown over the element it will begin to highlight the text; however, when set to true it does not. In Chrome you get the drag icon, whereas in Firefox you just don’t get the highlight of the element. Either way, the browsers are trying to do something with these elements.

---

Saving Space With Menus: The contextmenu Attribute.

The contextmenu attribute allows you to give a menu without taking up valuable UI space for the menu. It is a menu which fires on events such as mouseup or keyup providing a bubble menu which provides options and actions based on those selections.

    <article id="contextmenu_test">
        <header>
            <hgroup>
                <h1>Let's See What Happens</h1>
                <h3>Can we give a context menu?</h3>
            </hgroup>
        </header>
        <p contextmenu="foo">This paragraph has a context menu called "foo" attached.</p>
    </article>
    <menu id="foo">
        <command label="Step 1: Write Tutorial" onclick="doSomething();">
        <command label="Step 2: Edit Tutorial" onclick="doSomethingElse();">
        <command label="Step 3: ..." onclick="youGetTheDrift();">
    </menu>

In this example, there are a few more things going on with contextmenu that are new. For instance, we have to have a menu defined so that contextmenu knows where to point. In the example above, we are saying when there is a mouse event (depending on browser implementation) go out and find the menu “foo” in the DOM, and display it’s commands. The syntax is relatively simple after that. We have a menu label which will display the attribute text, and we have an onclick event which will do whatever we have defined.

---

The Catch-All: The data-* Attribute.

I have saved the most controversial global attribute for last. I have mixed feelings with this new attribute. On one hand, I am looking forward to the ability to connect my logic layer with my behavior layer without going through too many hoops, or using attributes and elements outside of their design specs. On the other hand, I know that when you add ambiguity to a specification, it tends to be overused and misused when there are better options available.

What this attribute is, is a catch-all. Basically, the specification is saying we can not ever think of all of the use-cases for attributes, therefore we will leave you to your own to make them up. The logic in me feels a specification should give us a set of rules to play with, and leave it at that, but the innovator in me loves having the power to define new attributes. I just know from experience when there is a chance to do something not quite right, but easier, that path generally bites you in the behind. All that said, let’s keep it positive and look at a couple of possible cases.

I think this attribute will be a wonderful addition for microformats, and might be the thing that puts them in the forefront of development. I can also see some uses where on the backend I want to give some bread crumbs to my behaivor layer in javascript to close some gaps. Another idea where you might use this attribute is to provide a location for where you are when you posted an article. That might look something like this:

    <article id="data_test" data-latitude="38.254" data-longitude="85.72">
        <header>
            <hgroup>
                <h1>Post From Louisville, KY</h1>
                <h3>Waterfront Park Concert</h3>
            </hgroup>
        </header>
        <p>I've just attached a post from Waterfront Park in Louisville, KY.</p>
    </article>

I can now take those data-* attributes and do something via Javascript or another API, such as post a map, from attributes from my application layer. It ends up opening a ton of possibilities, but don’t forget the immortal words of Ben Parker, “With great power, comes great responsibility”.

---

Conclusion

Like most things in HTML5 at the moment, the browser support for these changes are spotty at best. Some new attributes are supported. Some are incorrectly implemented. Some have no support at all at the moment. That said, they all appear to degrade nicely without much hoopla involved, so there isn’t a compelling case outside of not working to not begin experimenting and implementing. The specification changes are slowing, so more than likely what you see is what you will get… At some point.