Entity/Header/Masthead Markup Prototype

[ebollens]

Please define the header bar markup template:

• Create a directory template/entity/nav/SOMETHING
• Provide an HTML template in this directory with "ideal" markup for this using HTML 5 semantics
• Provide a user interface/experience design for this element at different responsive sizes
• Provide a description with motivation, challenges, etc. on a subpage linked to from the list on [[Components]]

[alicetseng]

After doing some research I'm going to propose this: template/entity/header/mastheadHNav. Masthead is another name for the primary website header and the html5 header entity allows its use to encapsulate the main page header with search,nav,logo. Thus this would he a type of header that features the masthead and includes a horizontal nav.

[ebollens]

This makes sense to actually make it a header at the top level, as some might not actually include a nav.

However, in that case, why not just template/entity/header/masthead? What's up with the "HNav" part?

[alicetseng]

ah - some mastheads don't always include a horizontal nav. thoughts?

[ebollens]

Exactly - and ours shouldn't require it either, although it clearly needs to support it.

Ideally we should seek to come up with one definition that can support the nav or a lack thereof. If not, then we could split this as you suggest.

Let's start with the HTML prototype and design for both, and see if we can't come up with a way to make it work with or without a nav.

[alicetseng]

sure - feel free to change the file as you see fit.

[ebollens]

@atsengucla when you have comments, can you put them on a subpage for this component rather than within the HTML markup template. The reason is that we don't want to build discussion into a template that is later going to wind up as a demo - whereas we can keep a full track record of discussion in a subpage on the wiki.

I've branch off a subpage here: https://github.com/ucla/WebBlocks/wiki/Entity-Header-Masthead

You can find this listed in the Components section of the wiki too: https://github.com/ucla/WebBlocks/wiki/Components

[ebollens]

I'm going to take a pass at simplifying it.

[ebollens]

@atsengucla please refer to the template/entity/header/masthead directory and let me know what you think of the prototype and the example of this in use.

While I understand the desire to keep markup near what it initially was, we have the freedom to actually get elegant with our markup, especially since the question now isn't even about the complexities of implementation but rather what makes sense semantically. Some of the places where I disagreed with the original description in template/entity/header/mastheadHNav.html:

• The use of div > nav when we can just use nav for the topbar (this is really about a separate entity admittedly though: the entity/nav/topbar which I've created #9)
• The existence of div.headerwrap does not seem to improve anything - also, the user of div[role="banner"] seems flawed since this div contains more than just the banner but also the entire primary navigational structure.
• The structure ul > li > a + ul > li > ul > li to accomplish a two-tier menu when it should be enough to use ul > li > a + ul > li to do this. Further, within this structure, there is an a.close. Responsive design should choose how this is handled and it should not have to be explicitly defined in the markup - although if we see reason, maybe we allow a user to define it if they want optionally (say to control the text).
• Existence of div.submenuSpacer - any time you have an empty element to handle spacing, something is wrong.

As I was going through your version, however, I realized I haven't covered the case of a department name explicitly - but that's something that fits within the h1 that's used as a header. Something we can think about that's a bit cursory to the actual prototype.

Also, you'll note some syntax in the comments for prototype.html, namely an integer value (or a pair with two periods in the middle) above an entity. That's a definition of how many of this element can exist in order.

• <!-- 0..1 --> Zero or one copy of the element
• <!-- 0..* --> Zero or more copies of the element
• <!-- 1 --> One copy required, not more or less, of the element
• ` One copy required, more optionally, of the element

In all cases, this notation pertains to the directly following element (and of course it's children apply when the element is used for that instance of the element).

[ebollens]

@modernrockstar do you see any problems with the markup template on the whole based on what you guys did for the Gateway itself? I believe its possible to implement everything on your masthead using the markup in prototype.html, but I may have overlooked something.

[alicetseng]

Hi Eric, a few clarifications: I believe that some of those wrapper divs might be necessary given the design techniques they are trying to execute? A wrapper div is still a common technique that is used due to the need to employ certain stylistic treatments on a layer separate to the actual content piece.

Are we saying we'll never include wrapper divs? Or are you simply saying that it wasn't needed in this instance?

I did look at html5 discussion sites and there's nothing wrong with using a wrapper div if there is a real need -- in fact the div is the correct/recommended element to use when a container object (w/o semantic meaning) is needed. I left their wrapper divs in because I recognize this is a real pattern that designers have/will continue to use. The OOCSS folks also employ this -- they just made sure to standardize the structure so it's modular and repeatable. The use a block, inner block, children content {header/body/footer} pattern to standardize the structure that wrapped elements take.

I understand the desire to be elegant, but my hope is that we are building for actual use cases. If we discover an actual pattern from the content -- shouldn't we recognize and standardize for it even if it isn't "ideal" ?

Regarding the menu-- I believe the close is for the explicit close button for their click drop-down menu and has nothing to do with the responsive design. This is something that the user needs to explicitly control in their click menu to close the menu.

Finally, I caution using "topbar" as a name for the sake of robustness. Yes, it happens to be the topbar in this design and many designs at the moment (for the current fashion) but who's to say that a utility bar will always remain the topbar? The "helper navigation" that includes auxillery links is commonly called a utilitybar.

[alicetseng]

The search is considered a nav element, not an aside. It is considered a major navigation element for a webpage. See nav section in this article: http://html5doctor.com/avoiding-common-html5-mistakes/

[ebollens]

@atsengucla, thanks for the comments! My follow up thoughts:

1. I completely agree that that wrappers may have some use, but what is the purpose in this case? If I look at #header[role="banner"] (I think your analogue is .headerwrap[role="banner"], the only properties defined on it according to the inspector are: background, border-bottom, min-height and padding. As such, I think this simply adds markup complexity without any real gain.
2. If we have to provide a wrapper, then we have to provide a wrapper. However, if we can avoid it, then we keep our markup more simple, so I think this is the sort of thing we add to the prototype as we implement - if we find it's not possible to develop the entity without it. That's why they're common in OOCSS and elsewhere, because CSS does have limitations without adding wrappers - when of course we hit those limitations.
3. I would also point out that HTML 5 will lead us to use new elements wrapping subtrees (like header). In many of these cases, I suspect that we can use these as wrappers/containers rather than define a wrapper div and then also an HTML 5 semantic element. This is definitely the case in your mastheadHNav.html example - hence why in prototype.html I did away with the wrappers.
4. The "Close" button is a design decision we may want to debate further. We have two options: (1) explicitly define a close button or (2) allow the framework to decide how to display a close button via the use of a closeable class on the nav. I'm inclined to prefer the second - although we could allow you to NOT define closeable and instead explicitly define the close element as you're suggesting. The benefit is that you're leaving control over presentation to the framework - unless of course you want to do the explicit definition, in which case you can simply do so as long as you use the right element. Does that sound like a reasonable compromise?
5. I was envisioning this as an analog to the Twitter Bootstrap class .navbar.navbar-fixed-top. Maybe it makes sense to break it apart into two units, nav.bar and nav.bar.top. Let's break this discussion off into issue #9.
6. Great catch. I'll amend the prototype.

[ebollens]

Updated to change the issue with aside to nav:not(.main). This also parallels a discussion on nav.main that Joseph and I were having where it should be its own distinct entity (see #12).

[ebollens]

Looks like this task is pretty much closed out. Thanks for the hard work on it! I've created a development task in #32.

[alicetseng]

Assigning masthead prototype to me, following agreement to re-scope masthead. Refs Ticket #32.

[alicetseng]

@ebollens @loganfranken this prototype and README has been updated; please vet and I'll close it and move on to finish the implementation.

[loganfranken]

Hey @atsengucla, this looks good to go although there are just a couple minor formatting errors with the README.md

[ebollens]

This issue should be closed as we're in implementation.