Markup for: theme_breadcrumb()

Typo

Why do we wanna add a class the ol & li ?

{% if breadcrumb %}
  <nav class="breadcrumb" role="navigation">
    <h2 class="element-invisible">{{ 'You are here'|t }}</h2>
    <ol>
    {% for item in breadcrumb %}
      <li>{{ item }}</li>
    {% endfor %}
    </ol>
  </nav>
{% endif %}

css to target:

.breadcrumb ol{ ... }
.breadcrumb ol li { ....}

less markup & classes to work around

With the dropping of IE8, there is little reason to continue to use classes for line elements. The use if nth child will suffice for any styling needs as well as any javascript/jquery access.
http://caniuse.com/#search=nth

@mortendk @webthingee Adding classes is often the best way to keep styles modular and abstracted from the underlying markup structure. For building sites, I try to use targeted classes for 80% of my CSS selectors, based around my design/style guide. In core *default* markup though, I know Morten would be the first to say ‘get rid of that crap!’ :)

It boils down to not stepping on the toes of front-end devs. The trouble is as you take classes out of the markup, you invariably make your CSS selectors more complex and higher in specificity, which makes them harder to override. I believe we best serve themers by balancing the two and limiting both the classes and the stylesheets in core to a sensible minimum. A class should not be there unless there is a style attached, and core CSS should be purely functional.

What about this:

<nav class="breadcrumbs" role="navigation">
  <h2 class="visually-hidden">{{ 'You are here'|t }}</h2>
  {% for crumb in breadcrumbs %}
    {% if loop.last %}
      <span class="breadcrumbs__item is-active">{{ crumb.label }}</span>
    {% else %}
      <a class="breadcrumbs__item" href="{{ crumb.href }}">{{ crumb.label }}</a>
    {% endif %}
  {% endfor %}
</nav>

Edit: removed stray </ol>

yes my initial respons is always "get rid of this crap" ;) and to be honest i dont belive in the idea to class up everything to make it more abstract (in this example the breadcrumb markup strukture will likely stay the same the next X years )

Fortunately the way were gonna build stark & bartik is one with all the classes n stuff in & one that is clean so we can make both worlds happy :)

so as long as we can seperate the two filosophys (clean vs. class based) im a happy little frontender

@mortendk #6 I’m with you. Our philosophies on CSS might differ, but we both agree on less stuff in core to get in our way. Come to think of it, that’s one reason to go the list-less route for horizontal navs, especially breadcrumbs. As long as it works out for a11y, we could take the classes off of the breadcrumb items in #5. Since everything would be naturally inline, we could conceivably require no breadcrumb CSS in core.

What do you think?

Screen readers use semantic markup to help logically parse a website. Removing the lists will be a step backward for assistive technology.

@ryan
well yeah maybe the filosophies differ - mine have changed alot over the last years (gasp im getting old) but my basic filosofy is that i dont wanna force anybody into a "this is what we think right now is best practice" cause noone knows whats gonna happen in 2 years :) - which i think we agree upon.

So what i think we should do is to do the clean as possible version in stark & push in all the classes into bartik - then we get the both of both worlds ?

@mgifford: so are you arguing that everytime we have 2 links next to eachother they need to be in a list ? - as i remember the talk i had with falcon03 in Portland, one of the issues was that it only mattered when you had a substantional amount of links & that the only gain there was the ability to jump over x amount of links ?
but screenreaders still could count etc if the links were gathered inside a <nav> elemet.

My point is that we wanna make a good solid solution for a11y - but we also need to look at how were doing stuff with fresh eyes - Drupal is as a platform lacking so hard in the frontend & its imho full with old assumptions that maybe isnt needed anynore - So lets make a solution that makes it good for all of us.

@mortendk *Exactly right*. Get all the extra markup and non-essential classes out of core markup. Anything class that is not needed to make Stark work needs to go away. Push them to Bartik (and Seven, they may have different needs for classes). Also exactly what you said about a11y :)

Definitely good to look at everything (especially accessibility) with fresh eyes. Thanks for taking on this huge task that is bound to ruffle a lot of feathers. Not easy to do.

It's such an interesting challenge with participating in Core development as it has to work with the technology & user behaviors that people have now, but it also should be anticipating where things are going in 2-4 years.

One of the leaders in the accessibility world is WebAim and they are still using HTML4 & have a breadcrumb structure that is super simple:
http://webaim.org/blog/lowvis_and_motor_surveys/

There are also places where there are frankly judgement calls and it really depends on the context. I assume that a menu with only 2 items in it would be slightly more awkward to navigate than what @ry5n was proposing as it would announce that there was a list of 2 items and so would take slightly longer.

Now, for most basic sites, this makes sense. However, if you've got site that's 3-4 levels deep, then having that order would provide some useful structure.

So what is the use case we should use to decide the default behavior? Will it be easily extended so that deeper sites can easily add a more structured menu?

You can also find a reference implementation of Breadcrumbs as part of the HTML 5.1 Nightly Editor's Draft - Common idioms without dedicated elements.

4.14 Common idioms without dedicated elements
4.14.2 Bread crumb navigation

code example:

<nav>
 <p>
  <a href="/">Main</a> &gt;
  <a href="/products/">Products</a> &gt;
  <a href="/products/dishwashers/">Dishwashers</a> &gt;
  <a>Second hand</a>
 </p>
 <p>
  <a href="/">Main</a> &gt;
  <a href="/second-hand/">Second hand</a> &gt;
  <a>Dishwashers</a>
 </p>
</nav>

This raises an interesting question about webAim - if they still insist on using html4 markup are we gonna follow their lead or keep on the path of html5 ?

You can also find a reference implementation of Breadcrumbs as part of the HTML 5.1 Nightly Editor's Draft - Common idioms without dedicated elements.

'editor's draft' being the operative word. there has been some recent dicussion on breadcrumb markup on the HTML list.

I am going to update the current advice in the section you cite, due to feedback from users, to something like this:

<nav role="navigation" aria-label="You are here">
<ul>
  <li><a href="/">Main</a></li>
  <li><a href="/products/">Products</a></li>
  <li><a href="/products/dishwashers/">Dishwashers</a></li>
  <li>Second hand</li>
</ul>
</nav>

This raises an interesting question about webAim - if they still insist on using html4 markup are we gonna follow their lead or keep on the path of html5 ?

They are actually using an XHTML doctype, this may be due to a number of reasons including the constraints of their CMS or they just haven't bothered to update the doctype, in reality it makes no difference. They are using ARIA attributes on their site, which are only 'conforming' in HTML5, but what this means is that when they run their code through a validator it will whine about their use, nothing more.

Closed #1854346: breadcrumb markup & twig file as a duplicate of this issue.

my comment wasnt about what they use on their site - but what they are expecting us to do with the reader ;)

"The trouble is as you take classes out of the markup, you invariably make your CSS selectors more complex and higher in specificity, which makes them harder to override."

True, but there is a way in-between. Following SMACS, it's fine to make selectors 2 levels deep. So .breadcrumb li is perfectly fine and doesn;t interphere with other list items.

My opinion would be to remove classes as much as possibles (same for ID's), and only add them on the element like .breadcrumb, .main-menu and .logo.

I agree with the proposed markup. The consensus seems to be that cutting away unnecessary classes is the way to go, especially with the dropping of IE8 support and the ability to use n-th child selectors, or selectors like .breadcrumb li, which are perfectly fine. The proposed markup already made it into core. Marking as fixed.

Remove class on ol and replace .element-invisible with .visually-hidden on h2. This reflects the version that already made it into core.