Bi-color background

This example does not include IE 6/7 workarounds (check the source code of this demo page for IE fixes).

.parent {
  display:inline-block;
  text-align: center;
  border: 1px solid #cecece;
}
.child {
  display:inline-block;
  line-height: 0;
  height: 0;
  border-top: 1em solid #ffc;
  border-bottom: 1em solid #fdcf46;
  padding:0 .6em;
  vertical-align:bottom;
}

<ul id="menuBar-A">
<li><a href="#">About Us</a></li>
<li class="selected"><a href="#">Contact Us</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Products</a></li>
</ul>

Dots and pipes between list items

This example shows properly across browsers after some simple IE fixes.

ul.one,
ul.two {
    margin-left:0;
    display:inline-block;
    *display:inline;
    zoom:1;
    height:12px;
    line-height:12px;
    padding:0;
}

li {
    float:left;
    display:inline;
    height:2px;
    line-height:2px;
    position:relative;
    top:.3em;
}

ul.two {border-left:1px solid #333;}

ul.one li {border-left:2px solid #333;}

ul.two li {border-right:2px solid #333;}

ul.one li.first-child,
ul.two li.last-child {
    border:0;
}

a {
    color:#000;
    padding:.4em .9em;
    *position:relative;
}

<div id="menuBar-B">
<ul class="us">
<li><a href="#">About Us</a></li>
<li class="selected"><a href="#">Contact Us</a></li>
</ul>
<ul class="ourOffer">
<li class="services"><a href="#">Services</a></li>
<li><a href="#">Products</a></li>
</ul>
</div>

Left and right-pointing triangles

This example does not include IE 6/7 workarounds (check the source code of this demo page for IE fixes).

#box {
  line-height: 0;
  height: 0;
  border: .4em solid transparent;
  border-left-color: #333;
  border-right-color: #333;
  padding: 0 .3em;
  display: inline-block;
}

<ul id="menuBar-C">
<li><a href="#">About Us</a></li>
<li class="selected"><a href="#">Contact Us</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Products</a></li>
</ul>

IE 6 and border transparency

IE 6 does not support the keyword "transparent" for border color. When you use this value, IE 6 draws a black border.

The fix for this is to use the chroma filter which displays a specific color of the content of the object as transparent. For example, to create a right pointing arrow you could use this rule:

#Box {
  height: 0; 
  width: 0;
  border: 10px solid transparent;
  font-size: 0;
  _border-color: pink;
  _filter: chroma(color="pink"); 
  border-left-color: #333;
}

The font-size declaration is another workaround for IE 6. It is to make sure this browser does not increase the height of the box.

Stop the presses! I just learned a new trick (thank you Chungho Fang):

The magic [to create border transparency in IE] is to set ‘border-style’ to either dashed or dotted

That’s it! This is just one more way to use borders to achieve image-less design.

Further reading

• A Study of Regular Polygons
• slantastic
• Slants

About the author: Thierry Koblentz is a front-end engineer at Yahoo!

He owns
TJK Design,
ez-css.org and
css-101.org. You can follow Thierry on Twitter at
@thierrykoblentz
.

This property applies to all elements. It has five possible values:

• static
• relative
• absolute
• fixed
• inherit

position:static

From section 9 Visual formatting model:

The box is a normal box, laid out according to the normal flow. The
top,
right,
bottom,
and left
properties do not apply.

Things to notice in this demo

• The second box shows exactly where it would be without the position declaration.
• The value given to top does not apply because in a ‘static’ context, the computed value of box offsets is always auto.

Things to remember

• If the position property of an element has the value of static, that element is not said to be positioned.
• Because static is the initial value (the default value), there is no need to include such styling in a declaration block unless it is to overwrite a different value.

position:relative

From section 9 Visual formatting model:

The box’s position is calculated according to the normal flow (this is called the position in normal flow). Then the box is offset relative to its normal position. When a box B is relatively positioned, the position of the following box is calculated as though B were not offset.

Things to notice in this demo

• Box ‘two’ has moved down by 300 pixels, but box ‘three’ as well as the following paragraphs stayed in place. It appears like if the box was lifted from the page, leaving its footprint behind. This is because offsetting a relatively positioned box does not disturb the flow.
• The relatively positioned box overlaps the following elements. It shows in front of other boxes.

Things to remember

• Computed values are always left = -right and top = -bottom. If the direction of the containing block is ltr, the value of ‘left’ wins and ‘right’ becomes -’left’. If direction of the containing block is rtl, ‘right’ wins and ‘left’ is ignored. Authors could take advantage of how things work by setting equal value to opposite properties.
• Unlike with the ‘absolute’ model, top, right, bottom, and left properties cannot stretch nor shrink the box (they cannot change its size).

position:absolute

From section 9 Visual formatting model:

The box’s position (and possibly size) is specified with the top, right, bottom, and left properties. These properties specify offsets with respect to the box’s containing block. A absolutely positioned box is removed from the normal flow entirely (it has no impact on later siblings) and assigned a position with respect to a containing block. Also, though absolutely positioned boxes have margins, they do not collapse with any other margins.

Things to notice in this demo

• Because no box offset is specified, box ‘two’ did not move from its original position, but if we had used top:0;left:0; for example, that box would be at the top left corner of the viewport.
• Layout wise, it is like box ‘two’ had been styled with display:none. The box has been removed from the flow.
• With box ‘two’ out of the flow, box ‘three’ has moved up against box ‘one’ (the paragraphs have followed).
• Like all elements removed from the flow, box ‘two’ has horizontally shrink-wrapped.

Things to remember

• For any ‘absolute’ or ‘fixed’ positioned element the computed value for display is block.
• For any ‘absolute’ or ‘fixed’ positioned element the computed value for float is none.
• A ‘containing block’ is a box that establishes a positioning context. It is established by the nearest ancestor with a ‘position’ of ‘absolute’, ‘relative’ or ‘fixed’. This means the parent box may not be the containing block.
• The default position of a absolutely positioned box is not always the same as if it was styled with top:0;left:0; (in a LTR context). And this is for two reasons:
  1. The containing block for a positioned box is established by the nearest positioned ancestor; if there is none, the reference container is the root element. The containing block in which the root element lives is a rectangle called the initial containing block. For continuous media, it has the dimensions of the viewport (a window or other viewing area on the screen) and is anchored at the canvas origin. This example shows the box positioned in relation to the viewport (the default containing block).
  2. The element is positioned in reference to the padding box, not the content box nor the border box of the containing block. This new example demonstrates where box ‘two’ would be if the edges of the padding box did not touch the edges of the content box (the containing block being body).
• The size of the box may be the result of the top, right, bottom, and left property values. For examples, zeroing out all properties will make the box stretch to match the dimensions of the padding box of its containing block. See zeroing out all box offsets (note: ie6 does not stretch the box).
• To create a mask overlay that does not scroll with the document (as in the previous example), either use fixed instead of absolute or style body with position:relative as the initial positioning block is the viewport (styling html would not work in IE). As this overlay demo shows.
• position:absolute triggers haslayout.

Most important thing to remember

Because this positioning scheme removes boxes from the flow, it is considered bad pratice to use it for layout.

position:fixed

From section 9 Visual formatting model:

Fixed positioning is a subcategory of absolute positioning. The only difference is that for a fixed positioned box, the containing block is established by the viewport. For continuous media, fixed boxes do not move when the document is scrolled. In this respect, they are similar to fixed background images. For paged media (where the content of the document is split into one or more discrete pages), boxes with fixed positions are repeated on every page. This is useful for placing, for instance, a signature at the bottom of each page. Boxes with fixed position that are larger than the page area are clipped. Parts of the fixed position box that are not visible in the initial containing block will not print.

Things to notice in this demo:

• Since fixed positioning is a subcategory of absolute positioning, everything that was true for ‘absolute’ is also true for ‘fixed’ (the element shrink-wraps, it is removed from the flow, etc.).
• The box is positioned in relation to the viewport, it does not scroll with the page.
• In IE 6, the box appears as a static box, but there is a "funny" workaround for that.
• When printing the document, box ‘two’ appears on every single page.

Things to remember:

• The box’s position is calculated according to the ‘absolute’ model, but in addition, the box is fixed with respect to some reference. In the case of handheld, projection, screen, tty, and tv media types, the box is fixed with respect to the viewport and does not move when scrolled.
• Content may be inaccessile to sighted users if part of the box is outside of the viewport area.
• In the case of the print media type, authors may want to prevent an element from appearing on each printed page. Maybe using a @media rule, as in:

  @media print { 
    #logo {position: static;}
  }

• Like position:absolute, position:fixed will trigger haslayout in IE.

position:inherit

If position:inherit is specified for a given box, then it will take the same computed value as the property for the box’s parent.

Note that IE 6 and 7 do not support this keyword except when used with direction and visibility (see the CSS Property Value inherit).

Things to consider

Box offsets

Be aware that for absolutely and fixed positioned boxes, values set in percentage for top, right, bottom, and left are computed according to the dimensions of the containing block (which may not be the parent box).

‘position’ and ‘overflow’

A box styled with overflow:hidden will clip relatively positioned elements (nested boxes), but it will not always hide absolutely positioned ones. This is because the parent box is not always the containing block (the nearest ancestor with a ‘position’ of ‘absolute’, ‘relative’ or ‘fixed’).

In short, this means absolutely positioned elements will show outside of a box styled with overflow:hidden unless their containing block is the box itself or an element inside the said box. This demo page shows how things work.

Margins

Authors can use margins on elements regardless of their positioning scheme.

The case of IE

In IE, ‘positioning’ a box may be a blessing or a curse:

• In IE6, position:relative (with haslayout) can be used to prevent a box styled with negative margins from being clipped by a parent container (see how positioning the box fixes this issue).
• Positioning an element may "disturb" the way boxes stack in IE 6 and 7 as this may establish a new stacking context (see a test case).

Stacking order and stacking level

• According to the sequence in the source code, positioned boxes come in front of floats and boxes in the normal flow.
• Authors can specify stack levels via the ‘z-index’ property only on positioned boxes.
• In IE6 and 7, the simple fact of positioning a box can establish a stacking context (see above, "the case of IE").

Mobile devices

Read PPK’s article, the [sixth] position value, to find out why mobile browser vendors cannot really support position:fixed.

Further readings

• Visual formatting model
• Position (CSS property)
• The position declaration

A "ghost" analogy by
DrLangbhani:

An element with position relative is always offset relative to it’s normal position in the flow. In other words, it is shifted relative to where it would be under normal circumstances, and shifting it doesn’t affect the layout of elements around it. It’s like a ghost that has left its body behind. A body that has width and height and affects its surroundings but is invisible. The ghostly box is able to move but is still connected to the old body in that its position is still measured from it. Now an element with position absolute is even easier. It no longer affects its surroundings at all (it’s pulled out of the layout flow). It’s now a true ghost with no body left behind. As far as its sibling elements are concerned it’s as if it no longer exists. To get its position, look through each of its parent elements until you find one with either position: relative, [position: fixed,] or position: absolute. That element will serve as the reference point. Only if you don’t find a "positioned" element will it be offset from the document.

Unfortunately, Mobile Safari has no way to distinguish between normal click subscribers and delegated click subscribers, which is when the click event is attached to a container rather than to each child of that container. As a result, a delegated click will result in the entire container being highlighted rather than just the item that was tapped, and this can be both ugly and confusing for the user.

The good news is that Mobile Safari supports a CSS extension called -webkit-tap-highlight-color, which you can use to customize the color of the tap highlight or hide it completely.

The -webkit-tap-highlight-color property accepts any standard CSS color value, but you’ll probably want to provide an rgba value in order to control the alpha transparency. Disabling the tap highlight is as simple as setting the alpha value to 0, like so:

#container {
  -webkit-tap-highlight-color: rgba(0,0,0,0);
}

Fire up your favorite iOS device and view this simple demo to see what a delegated click looks like both with and without a tap highlight. For more details on -webkit-tap-highlight-color and other useful Mobile Safari CSS extensions, see the Safari CSS Reference.

We decided to take the YUI 3 Slider widget skins up a visual notch for YUI 3.1.0. These were our goals:

1. Improve the overall visual tastiness and 3-D appearance
2. Offer a wider range of thumb and rail skins
3. Provide two sets skins to serve dark as well as light page backgrounds
4. Provide a complete set of thumbs and rails for vertical as well as horizontal use
5. Make it easier to mix and match thumbs with different rail styles
6. Provide Photoshop assets to aid developers in modifying slider images to match any background color

Compare the YUI 2 slider skins with the YUI 3 ones below. The new set has more variety and should serve a broad spectrum of pages and styles.

YUI 2 Slider Skins:

YUI 3 Slider Skins:

We didn’t restrict the thumbs to rectangles and 45 degree angles. This posed some challenges with anti-aliasing. The YUI 2 thumbs have shadows incorporated into the thumb image, so they are a solid color gray. We’ve improved this by making a shadow object that’s separate from the thumb image. The shadow has opacity: 0.15. This means it looks natural as the shadow falls on the rail and the tick marks.

We will be providing original photoshop files containing each of the rail and thumb images. This will provide developers the source from which to easily customize the images so that they look their best when placed on whatever color background your site has.

YUI 3′s widget foundation reached GA status last week with the release of YUI 3.1.0. We don’t yet have a full slate of native YUI 3 widgets, and we haven’t yet defined a set of global skins. However, the work we did on visual assets for the beta Slider Component should make it more useful in the short term, and we’ll carry all of these visual options on as alternative themes or examples once YUI 3′s baseline themes are in place.

Have a look at these working code examples of the new sliders. Checkout the behind the scenes detailed workings of the skin images and CSS.

We hope these new sliders will be a nice visual addition to your bag of tricks.

I completed the audit before the end of last year and expect to release new patterns in batches over the next few months. Some patterns will be mature and provide a solid foundation for site design. A few will be published as beta patterns which may undergo significant changes in subsequent updates based on feedback received. Regardless of their status, we hope you’ll get involved and review and provide feedback on the patterns provided.

The first batch of patterns to come out from the audit relates to navigation bars. There are three patterns so far in this grouping: Top Navigation, Left Navigation, and Progress Bar. One legitimate question is whether top and left nav bars are still the best or most current way to navigate a site and find content? We still find many examples of them across the web and in use at Yahoo! so for now I’ll say yes, but it’s worth thinking about.

Wherever possible I try to link patterns back to the YUI Library and, where appropriate, to other code and implementation solutions. YUI has great support for navbars and menu examples. Probably the best place to start is the menu widget.

One interesting nomenclature issue we studied was the distinction between a stepwise progress indicator (which is what the pattern is about) and a continuous progress bar (for which there’s a great YUI example). These two things are often referred to with similar names, but perform different functions. Suggestions for more appropriate terminology are welcome.

Please check out these new patterns and let us know what you think!

Can you describe the stencils you contributed, why you made them, and what you personally use them for?

I created a customizable, vector-based iPhone stencil library for InDesign. They came about as a result of several conversations that ultimately culminated with the creation of this stencil.

I co-lead the Vancouver chapter of the IxDA and one of the conversations that I’ve been interested in discussing with the group is “What is open source UX and is it possible?”. It’s a tricky topic to define, and the more I think about it, the more I am of the opinion that open sourcing tools is the first place to start, rather than focusing on definitions. I figure that the best thing you can do is to put tools in designers’ hands and let them create, so that’s exactly what I did.

Meanwhile, while pondering the Open Source UX question I was working on an iPhone app for a client and really wanted to use the newly discovered “interactivity” features buried in the depths of an InDesign workspace in hopes of a new path to generating rapid, clickable prototypes. So, I nabbed the PDF that you posted and started building out the InDesign snippets with customizable gradients rather than repeating, or stretched screen captures that I’ve seen used. I wanted to provide every Interaction Designer/UX Designer out there that uses InDesign with an option to use their preferred application for creating iPhone app layouts and designs if necessary.

You can find more details on this process in a blog post i have written called Lightweight Prototyping with InDesign.

Can you discuss how these differ from the Eightshapes adaptation of the Yahoo! stencil kit (since both are used in InDesign)?

Basically, I wanted to customize the PDF that you had already provided using the same level of fidelity as in the Illustrator version. I realized that it was a compilation of repeating images, rather than complete, editable vectors.

That said, I was making a move back to InDesign from OmniGraffle and saw it as an opportunity to create a higher-fidelity iPhone stencil for wireframing, prototyping, and quickly skinning an app to play with differences in look and feel, and to enable you to move that much further with InDesign.

The 8Shapes stencil doesn’t have the default gradients or some of the other interaction elements that I wanted to use in my wires (key/num pad, list select tumbler, etc.). That said, I didn’t create icons to the same extent that they did. I basically mimicked what was in the existing Yahoo! stencil.

I would love to add more to it eventually when I have time. I like having the option of removing the gradient if need be for basic wireframing yet have them readily available for quick mockups. I think they’re a good complement to each other depending on your use case.

What else would you see in the pattern library?

I’d love to see the Yahoo stencils in higher fidelity, much like the iPhone stencil, therefore on par with the OmniGraffle fidelity.

A general library on gesture based patterns would also be quite useful.

I’ve had some time now to review and study the results and I wanted to share them with the community as we write up a “beta” version of the pattern and get ready to share it, so without further adieu, here are the results (note that this survey should not be considered strictly scientific).

Who Responded

Respondents identified themselves the following ways:

• Designer 21.4%
• Developer 32.1%
• Hybrid (Both designer and developer) 42.3%
• None of the Above 4.2%

Terminology Distinctions

Overwhelming majorities across all respondents agreed that

• Accordion and Accordion Menu mean the same thing (73%)
• Accordions and Tree Controls are two different things (89%)

Many commenters described the difference between accordions and trees along these lines: “Tree Control generally implies a depth of hierarchy that is not generally present with an accordion.”

A smaller majority said that Accordion and Collapsible Panels refer to the same thing (60%).

These majorities were consistent across roles.

Presentation of Accordions

A solid majority (68%), said that accordions can be laid out horizontally as well as vertically (and in fact the pattern is well attested on the web). People suggested that the labels on a horizontal accordion should be written vertically and/or rotated.

An even larger majority (72%) said that accordions can have only two levels (this aligns with the distinction between accordions and trees):

A slight majority (53%) said that accordions may be nested within other accordions. The written comments suggested that the wording of the question led some to answer that it’s certainly possible but not necessarily desirable, making suggestions such as, “If you adequately gutter them, this would be possible, but generally a terrible idea – kind of like using too many tabs and having them wrap into multiple rows.”

This was one of the questions where self-described designers and developers took opposing sides. 57% of Developers and Hybrids agreed that accordions may be nested, whereas 64% of Designers said they may not be. (None of the Aboves split 50/50!)

If I had to guess, I’d say that developers (and hybrids), more intimately connected with the how than the why may have been expressing more of a “you could do it…” perspective, whereas designers may have been expressing more of a “…but you shouldn’t” point of view.

How Accordions Should Behave

A small majority (54%) believes that accordions should allow for more than one panel to be open at a time. Both behaviors can be found online, so our impression is that this behavior may depend more on the constraints of the design space and the purpose of the accordion than on a blanket rule one way or the other.

This question also split along identity lines, but in an ambiguous way. Hybrids preferred the one panel-at-a-time rule by a tiny majority, while Designers and Developers and None of the Aboves agreed that multiple panels are okay by slightly larger majorities.

A much larger majority (73%) believes that an accordion can have a completely closed state (that is, that it’s not necessary that there always be one panel open). The only outlier is that the None of the Aboves broke 60% for the position that there must always be one panel open.

Several commenters suggested that it is a good practice to have one panel open by default, and for that panel to be either the first one, the one most recently used.

Another large majority (76%) believes an accordion’s overall size can change as needed, rather than being constrained to a consistent size. (Of course, there are contexts, such as the screen of a mobile device, in which it may be a valid choice or even a design constraint that an accordion maintain a consistent size.)

A very slight majority (51%) suggested that accordions should open on click (as opposed to on hover) and a nearly as large minority (45%) said that it depends. Interestingly, fewer than 4% were willing to state the accordions should open on hover as a rule.

Written comments on this question offered plenty of good food for thought, such as:

Opening a panel should require explicit action. If an accordion has multiple panels, opening on hover could be a jarring experience. Rather, use a tooltip to convey summary details of what is in the panel, and have the user explicitly “click” to open that panel.

Depends on the configuration of each accordion.

I put these examples together [multiple, rollover], so the developer can actually use the “best fit” for each use case.

Also, there should be the option to use rollover with different rules: (one most be open) or (elements should be opened on mouseover only).

For advanced usages, an accordion should open on hover during drag and drop operations. In any other circumstance, you can’t trust that the hover is intentional.

Accessibility

Finally, we asked an open-ended question fishing for any known accessibility issues with accordions and got a lot of great answers. (For our example issue, most people agreed that making the entire label clickable and not just a small icon is important.)

Here is a sampling of other insight about accessibility with accordions:

I think it’s safe to assume that an Accordion interaction is an advanced interaction. Lots of accessibility problems can arise.

1. Content is hidden behind panels so people may not find it.
2. Depending on the size of the clickable area or the trigger to open/close the panels there could be issues with the manual dexterity needed.

Accordions should open all panels if javascript is unavailable (though that may produce a “flicker” for those with javascript).

It depends on whether content in the hidden panels is present in the DOM or is retrieved upon opening the panel. If it is being retrieved, focus needs to be placed on the newly opened panel.

Well, I really believe the title should be clickable, specially if the content of the element will be loaded using AJAX (just like a tabview approach), but the reality is that sometimes the developer (should have)/(want) the control to customize that behavior. Here is the list of examples that I created for an accordion widget implementation based on YUI 2.x, it’s probably one of the most used components from the bubbling YUI extension.

We’ve had a case where the ‘label’ of the accordion was a link to a full blog post, and so could not be accordion-clickable. In that case, we wrote an icon into the source with js to do the job. Provided the icon is sufficiently large and/or comes with an accesskey, I don’t see a major difficulty…

Accordion controls server the purpose of fitting lots of content into less space. Since this is a visual concern, it would be fine for a screen reader to simply read all of the content and ignore the fact that it is displayed as an accordion visually. It is sufficient for an icon to be clickable to expand a panel. There could be a configuration option to allow the entire label to expand a panel, or it can be left up to the implementing developer to attach a listener to the label that calls a public “open” or “expand” function to add that functionality.

Just think of an accordion as a tabbed view. The entire panel label area should be clickable, but if it contains other controls (e.g. a “dismiss” or “close” button) I suggest only the label (text) be clickable, or at least the clikable area only expand up to the interactive controls (i.e. for a caption containing a button, the area above, below and “after” the button should be clickable).

Releasing the Draft Pattern

One commenter questioned the artificial constraints of the survey (a fair cop, if you ask me):

I didn’t like this survey. The questions were not flexible enough. As a designer/developer, I believe all interface elements need to be tailored to particular site or web application. Asking black and white questions does not leave room for the obvious differences between projects. Some projects need a hard and fast rule, while the same rule might be totally inappropriate for another application. For the most part, I could of answered every question with a “it depends” result.

Rest assured that the pattern will only gently recommend and the YUI code will be flexible and powerful. The survey wasn’t designed to limit people’s choices but rather to gather opinions and preferences, so even feedback about not having hard-and-fast rules is useful.

We’ve published a beta version of the Accordion pattern in the Yahoo! Design Pattern Library. If you’d like to give further feedback on the pattern, in a free-form manner, please drop by or visit the related forum discussion.

YUI contributor (and author of the Interval Selection Calendar example) John Peloquin of W. Hardy Interactive has released another excellent option for Calendar implementers: a layered navigation path for selecting years and months. The layered approach provides an alternative to the built-in navigator interface that ships with Calendar.

John describes the inspiration and thought process behind this implementation on his blog, where you’ll also find API documentation and source code.

(I realize this is not a scientific survey. I’m just interested in engaging the wider community in a discussion instead of trying to impose my view or Yahoo!’s view on the community as authoritative.)

Everywhere I go lately, it seems that interaction designers and web developers are talking about accordion widgets and debating about what makes an accordion an accordion. Not everyone working in this field has heard the term (some may simply refer to “stacked panels” or “collapsible panels”) but most get the gist fairly easily. Ironically, none of the UI elements described as accordions share the actual behavior of a real-world accordion (the musical instrument): namely, that stretching an accordion opens all the folds evenly.

Accordions have been an on-and-off topic of discussion on the main IxDA mailing list; we discussed them in our Pattern Library workshop in Vancouver earlier this month, and there’s been an ongoing discussion about accordions on our internal designer mailing list here at Yahoo!.

So I sat down with some folks from the YUI team (and Marco, the maker of an experimental YUI accordion widget) a little while ago to sort through a draft of an accordion pattern that might help inform the development of an official YUI component.

Broadly speaking, most people agree on what we’re talking about when we talk about an accordion interface element. Everyone agrees that accordions are used to compress content into a limited space and that they consist of panels that can collapse or expand. Beyond this, there are a number of subtle nuances that not everyone agrees on.

One trend I’ve noticed is that front-end developers tend be agnostic about how the accordion should work, viewing it as really just a variant on a tree widget. Designers tend to be more prescriptive, saying that to be an accordion it must behave in thus and such a way (but not all designers agree on what these rules are).

In the end, the YUI folks will produce code that can be made to do just about anything. We aren’t going to try to impose our own taste or preferences in design through the functionality of the code itself. However, we will use the associated pattern to make suggestions and recommendations drawn from the experience of the entire design community, and we will probably lobby for default behaviors that match what most people expect.

So, if you’ve got a few minutes and an opinion, please visit the survey and let me know what you think!

I’ll close the survey on April 30.