Re: 4.13.1 Bread crumb navigation - use of right angle brackets

I'd say the code should reflect what it "means". If you "mean" the
breadcrumbs show the path in the structural tree of a website, then yes,
use nested ol's. A breadcrumb per definition can't be like a recipe.
Although there's some similarity between the two, a recipe is a series of
steps in a process, a breadcrumb is a navigational path, always down one
branch (a recipe usually has multiple branches).

For some reason there seems to be a trend that we (authors) give in to what
is used the most "in the wild", instead of doing what is actually correct.
HTML is nothing more than structuring data. Some data can be structured
more than other data, I think we should strive to structure it as best as
we can.

This should be (in my opinion) the goal of, at least, the spec. If people
will actually follow it is a different discussion, but striving for the
best possible outcome should (again, in my opinion) always be more
important than what people are used to now.

It's exactly the same as using the <i> element for icons; it's lazy, sloppy
and incorrect, but it's used more often than not and promoted by frameworks
like Bootstrap. The spec should (and thankfully does in this case) promote
the use of <span>, when no semantics are or should be tied to the element.

Sorry for my rant, but it feels like 1994 all over again when the argument
is made that most people don't use it right now and therefore shouldn't be
in the spec. That's reversed thinking, let's go for the best possible
result ;-)

On 17 September 2013 09:35, Patrick H. Lauke <> wrote:

> On 17/09/2013 14:14, Reinier Kaper wrote:
>> Anyway, back on topic, the only really semantically sound way of writing
>> a breadcrumb is (unfortunately) nested lists:
> If you want to denote the hierarchy, yes. If, however, you see breadcrumbs
> more as an ordered list of steps (a recipe, if you will, that you need to
> follow, from the site's entry page to get to the current page), then an
> ordered list also makes sense.
> As with most discussions of "semantics" though, it's easy to fall down a
> rabbit hole of over-specifying and over-semanticising things (or, as
> Jukka's example clearly shows, using "reductio ad absurdum"). Really, in
> the end, the question should be: how detailed and semantic do you want to
> be, and who would benefit from it? Would the experience be vastly improved
> for, say, screenreader users if they encountered a deeply nested ordered
> list that simply tells them where they are within a site?
> P
> --
> Patrick H. Lauke
> ______________________________**______________________________**__
> re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
> |
> |**redux/<>
> ______________________________**______________________________**__
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> ______________________________**______________________________**__

Received on Tuesday, 17 September 2013 13:47:04 UTC