An interview with Tom Beck, Chief Curator of the Albin O. Kuhn Library Gallery, aired on WYPR’s Maryland Morning this week, in which he discusses the works currently on display in the Library Gallery exhibition, N. Jay Jaffee Photographs from Public to Personal, 1947-1997. Beck talks about the artist’s personal life and work in relation to the photography of his peers, as well as the historical importance of Jaffee’s photographs.

Listen to the interview, “Photographer N. Jay Jaffee Captured the Spontaneous” at WYPR.org.

More information about the exhibition is available at our Arts and Culture Calendar. N. Jay Jaffee Photographs from Public to Personal is on display now through Sunday, March 23 in the AOK Library Gallery.

Voice of America’s International Women’s Day coverage highlights the efforts of leading women in science, technology, engineering and math (STEM) to encourage girls to pursue those fields.

In a video posted on the news site, Marie desJardins, professor of computer science and electrical engineering, says, “Make sure your kids are getting [exposure to STEM] from an early age so they think of themselves as creators of technology and new ideas, not just following the rules.”

See the video and article on Voice of America by clicking here.

A number of new interactive elements were introduced with HTML5 that provide native implementations of common UI widgets like dialogs and modals. Among these new additions are the <details> and <summary> elements. These elements allow developers to create collapsable UI widgets the user can click to show or hide content.

In this post, we’ll take a deep dive into the <details> and <summary> elements. You’re going to learn how to use these elements in your HTML markup, how to apply custom styling to them, and what browsers they work in.

Let’s get started.

Using the Details and Summary Elements

The <details> and <summary> elements are used in combination to create a UI widget that allows the user to find out more information about a topic by clicking on a summary.

A simple details and summary element example.

The <details> element is responsible for marking up all of the content relevant to the particular topic. The <summary> element is used to specify a short piece of text that describes the rest of the content in the <details> element.

<details>
        <summary>Summary text</summary>
        Content goes here...
    </details>

By default, the browser will only display the content within the <summary> element to the user. Once this summary is clicked, the remaining content will become visible.

The browser will use the text from the first <summary> element within the <details> element when constructing the widget. If no <summary> element is specified, the browser will simply display “Details.”

If you’d like the widget to be open when the page loads, you can specify the open attribute on your <details> element.

<details open>...</details>

The browser will toggle the open attribute for you as the user opens and closes the widget.

So what kind of content should you be using the <details> and <summary> elements for? Simply, any additional information you’d like to provide about a subject. For example, you could use these elements for marking up order data within an e-commerce app. In the following example, the user is presented with an order number that, when clicked, will reveal the full information about the order.

Using details and summary elements to mark up order data.

View The CodePen Demo

<details>
        <summary>Order #24892105</summary>
        <table>
            <tr>
                <th scope="row">Order Date</th>
                <td>30th May 2003</td>
            </tr>
            <tr>
                <th scope="row">Order Number</th>
                <td>#24892105</td>
            </tr>
            <tr>
                <th scope="row">Courier</th>
                <td>Buy N Large Postal</td>
            </tr>
            <tr>
                <th scope="row">Shipping Address</th>
                <td>
                    P. Sherman,<br>
                    42 Wallaby Way,<br>
                    Sydney,<br>
                    Australia
                </td>
            </tr>
            <tr>
                <th scope="row">Billing Address</th>
                <td>
                    P. Sherman,<br>
                    42 Wallaby Way,<br>
                    Sydney,<br>
                    Australia
                </td>
            </tr>
        </table>
    </details>

You could also create a UI widget that presents additional controls when a user clicks on a key object in your application.

Using details and summary elements to mark up additional controls.

View The CodePen Demo

<details>
        <summary>README.txt</summary>
        <ul>
            <li><a href="#">Open</a></li>
            <li><a href="#">Edit</a></li>
            <li><a href="#">Duplicate</a></li>
            <li><a href="#">Delete</a></li>
        </ul>
    </details>

Other applications could include things like questions and answers within FAQ pages, tables of contents, and collapsable fieldsets for multi-part forms.

Styling Details and Summary Elements with CSS

Now that you have an understanding of how to use the <details> and <summary> elements in your HTML, let’s take a look at how you can style these elements using CSS.

Targeting the details element in your CSS allows you to style all of the content within the element.

details {
        /* Your styling rules. */    
    }

If you want to style just the area that opens and closes the widget, you should target the summary element.

summary {
        /* Your styling rules. */    
    }

Targeting these elements directly like this will add styling rules that apply in both the open and closed states of the widget. If you want to style the widget differently when it’s open or closed, you can use a CSS selector that only applies to <details> elements with the open attribute.

/* Open details element. */
    details[open] {
    
    }
    
    /* Summary within an open details element. */
    details[open] summary {
    
    }

By default, the browser will display a small marker triangle to the left of the summary text that indicates the current state of the <details> element. You can target this marker in CSS using the -webkit-details-marker pseudo-class.

/* Change the color and size of the marker. */
    summary::-webkit-details-marker {
        color: #69c773;
        font-size: 200%;
    }

You can even hide the marker completely by setting its display property to none.

/* Hide the marker completely. */
    summary::-webkit-details-marker {
        display: none;
    }

If you want to use your own marker icon, start by hiding the default marker (as shown above), and then use the :before pseudo-element to add your custom icon. This should be applied to the summary element.

Using custom marker icons.

View The CodePen Demo

Here’s the CSS code used to create the example above.

details {
        border-radius: 3px;
        background: #EEE;
    }
    
    details summary {
        font-size: 17px;
        vertical-align: top;
        background: #333;
        color: #FFF;
        border-radius: 3px;
        padding: 5px 10px;
        outline: none;
    }
    
    details[open] summary {
        background: #69c773;
        color: #333;
    }
    
    /* Hide the default marker. */    
    details summary::-webkit-details-marker {
        display: none;
    }
    
    /* Add the custom marker in the default state. */    
    details summary:before {
        display: inline-block;
        width: 18px;
        height: 18px;
        margin-right: 8px;
        content: "";
        background-image: url(https://s3-us-west-2.amazonaws.com/s.cdpn.io/4621/treehouse-icon-sprite.png);
        background-repeat: no-repeat;
        background-position: 0 0;
    }
    
    /* Move the sprite image when the details box is open. */
    details[open] summary:before {
        background-position: -18px 0;
    }

In this code, I’m using the :before pseudo-element to add the initial marker icon. I then create another rule that alters the positioning of the background image (so as to change the visible section of the sprite) when the details element has an open attribute.

Browser Support for the Details and Summary Elements

Browser support for the <details> and <summary> elements still isn’t great. Chrome, Safari, and Opera all support these elements, but Internet Explorer and Firefox do not.

Source: http://caniuse.com/#feat=details

There are a number of polyfills available that will add support for the <details> and <summary> elements to other browsers. Two of the best ones that I’ve found are:

• Element.details by Егор Халимоненко
• Details Polyfill by Manuel Bieh

Final Thoughts on Details and Summary Elements

In this blog post you’ve learned how to use the <details> and <summary> elements to create your own collapsable UI widgets. You’ve also learned how to style these elements with CSS, as well as how to replace the default marker icon with your own images.

It’s really encouraging to see browser vendors creating native implementations for some of the most commonly used UI widgets. What other UI components would you like to see added to browsers in the future?

Useful Links

• W3C HTML5 Specification: Interactive Elements
• WHATWG HTML Living Standard: Interactive Elements
• Modernizr HTML5 Cross-Browser Polyfills

The post How to Use the Details and Summary Elements in HTML5 appeared first on Treehouse Blog.

Even if you’ve been a front-end developer for years and have done a fair amount of JavaScript programming throughout your career, there may be a few things you’ve missed out on from those delivery pressures piled on you in your day-to-day development life.

Let’s take a step back, pause, take a breath and review some tricks and best practices you can learn from looking at the compiled JavaScript code resulting from CoffeeScript.

Example Code

Here’s an example of CoffeeScript code and its JavaScript output.

CoffeeScript:

myName = "Andrew"
    age = 30
    names = [myName, "Jim", "Michael", "Micah", "Yvette", "Shawna"]
    
    say = (name) ->
      if name is "Andrew"
        "Hi Chalkers!"
      else
        "Hi #{name}!"
    
    for name in names
      console.log say(name)
    

JavaScript:

(function() {
      var age, myName, name, names, say, _i, _len;
    
      myName = "Andrew";
    
      age = 30;
    
      names = [myName, "Jim", "Michael", "Micah", "Yvette", "Shawna"];
    
      say = function(name) {
        if (name === "Andrew") {
          return "Hi Chalkers!";
        } else {
          return "Hi " + name + "!";
        }
      };
    
      for (_i = 0, _len = names.length; _i < _len; _i++) {
        name = names[_i];
        console.log(say(name));
      }
    
    }).call(this);
    

Executing the above code will result in the following output in your console:

Hi Chalkers!
Hi Jim!
Hi Michael!
Hi Micah!
Hi Yvette!
Hi Shawna!

Let’s deconstruct some of the JavaScript output and ask questions about why things are the way they are and see what we can learn.

1. Don’t Pollute the Global Scope

Why wrap your code in something like this?

(function() {
    //Your code code here
    }).call(this);
    

First off, what is this code? It’s an anonymous function. The call method afterward means this is a self-executing anonymous function. In other projects or examples, you may see it written like this:

(function() {
    //Your code code here
    })(this);
    

Or:

(function() {
    //Your code code here
    })(window);
    

The this variable in the context of being ran in the browser is the window object. This protects the global scope from being polluted by your variables. When you normally define values outside of a function like:

var myName = "Andrew";
    

You can access them via the window object like this window.myName;.

The above variable will be the string of "Andrew." Now, you may think, “Great! Here’s another way I can access my variables.” But it’s not that simple. When working on large projects with multiple people or even including external dependancies and frameworks, you can’t guarantee the variables you’re declaring won’t clash with their variables if you’re polluting the global scope. You can’t guarantee that everyone is using this best practice either.

In order to protect your variables from clashing with other variables and prevent any unintended behavior, you’d need to wrap them up with any additional code you want to access those said variables inside a self-executing anonymous function.

So this code:

(function() {
      var myName = "Andrew";
      console.log(myName);
    }).call(this);
    

will output Andrew in to the JavaScript console.

But:

(function() {
      var myName = "Andrew";
      console.log(window.myName);
    }).call(this);
    

will output undefined because the myName variable is declared in the scope of the anonymous function and thus not binding it to the window object.

The next time you’re writing a less-than-trivial JavaScript application, try wrapping your code in an anonymous function.

2. Declare Your Variables Together

Declaring variables all together like this is a neat trick.

  var age, myName, name, names, say, _i, _len;  
    

Not only are you saving on space writing var only once but you can give others an idea about what your application is about with a quick glance. This may be a tad more digestible than scanning through all of the code to get an idea of what variables you can use.

However, in large complicated applications, you’d probably have several JavaScript files, all with their own self-executing anonymous functions that only deal with a specific set of code. This would avoid a long first line and confusing things for new developers to the project. Be modular! You can always combine these files for deployment later.

3. Operators Matter

Did you notice the line if name is "Andrew" gets compiled down to if (name === "Andrew")? Why did CoffeeScript use === rather than ==?

When you use the == operator, JavaScript tries to coerce each of the operands (the variables either side of the operator) to match one another. This can lead to some very unexpected outcomes. Here are some mind-melting examples:

0 == ''; //true
    1 == '1'; //true
    false == ''; //true
    false == []; //true
    false == 'false'; //false
    

However, when you use === it compares the types of the operands first and then the values. This can be quicker operation than its == counterpart because the JavaScript interpreter doesn’t have convert the types first before comparing the objects. If they aren’t of the same type, it will automatically return false, which is what you’d be expecting.

So if you’re confirming values, it’s best to use === to prevent any weird goings-on. If you want to look at some more examples, check out this Stack Overflow post.

If you’re ever doing any comparisons, it’s best to use === if you’re expecting the operands to be of the same type, which is the case in most instances.

Conclusion

Even if you don’t write much pure JavaScript anymore, it’s good to know these things as you never know when you’re going to need to get your hands dirty on an old code base or if the team you’re working on doesn’t use or want to use CoffeeScript.

I’ve always found that learning best practices in one language or framework helps introduce those in other situations.

Is there anything you’ve spotted in the JavaScript output by the CoffeeScript compiler that you’ve found interesting? Or have there been other things you’ve taken from learning one language and taken it into others?

The post 3 Lessons from the JavaScript Output of CoffeeScript appeared first on Treehouse Blog.