ElkArte Community

Quote from: TestMonkey – June 23, 2013, 01:59:12 pm
(07:41:42 PM) groundup: Instead of <div class="windowbg2"> for posts change that to article. Instead of <a id="msg123"> change that to <article id="123"> add a class="unread" for unread posts
(07:42:00 PM) groundup: Just thought of that because of Aaron's PR
(07:45:41 PM) groundup: Use rel="author" for article authors

Quote from: TE – June 24, 2013, 02:32:15 amAbsolutely agree on .cat_bar, .title_bar, catbg, titlebg and and others.. I've always hated these names, they never made any sense to me..
I'd use a flat and simple structure, though:

<h3 class="content_header"> for cat_bar, catbg
<h4 class="content_header"> for title_bar, titlebg

Quote<p class="post_content"> for windowbg
<p class="post_content_alternate"> for windowbg2
<p class="post_content_unapproved"> ...

QuoteI'd be carefullly with semantics addition. Some of them make sense, but it's important to use them in the right context. Not sure, but the initial post could be declared the topic's <header>, the replies would become a <section>.

QuoteFirst thing is that I want to get rid of the cat_bar and title_bar divs entirely, not rename them. They're just bloat now. We only need the h3 and h4 they contain.

Quote from: W3CThe article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable...

Quote from: HTML5 DoctorThe tricky part is, what exactly is an independent item of content?

The smell test for going independent
An independent piece of content, one suitable for putting in an <article> element, is content that makes sense on its own. This yardstick is up to your interpretation, but an easy smell test is would this make sense in an RSS feed? Of course weblog articles and static pages would make sense in a feed reader, and some sites have weblog comment feeds. On the other hand, a feed with each paragraph of this article as a separate post wouldn’t be very useful. The key point here is that the content has to make sense independent of its context, i.e. when all the surrounding content is stripped away.

Quote from: Antechinus – June 24, 2013, 09:26:29 amThis is the problem, IMO. Forum posts often do not make sense when the surrounding content is stripped away.

Quote from: Antechinus – June 23, 2013, 06:17:25 pm

Quote from: TestMonkey – June 23, 2013, 01:59:12 pm
(07:41:42 PM) groundup: Instead of <div class="windowbg2"> for posts change that to article. Instead of <a id="msg123"> change that to <article id="123"> add a class="unread" for unread posts
(07:42:00 PM) groundup: Just thought of that because of Aaron's PR
(07:45:41 PM) groundup: Use rel="author" for article authors

Um, hold the bus there. Before you get carried away with "It's a new HTML5 tag so I gotta use it", read the W3C definition of the article tag again.

Yes, they do suggest a forum post as one possible example, but the key point is that the article tag is intended to be used only for content which stands on its own, without being directly tied to other items.

This applies to forum posts sometimes, but it sure doesn't apply all the time. IOW, forum posts are not always (indeed, are frequently not) "articles" as defined by the HTML5 specs. Ergo, "article" is not the right way of marking them up, AFAICT.

I suggest that this be re-thought.

I agree that div is a useless tag in this context, so I had thought that (for the moment at least) it would make sense to go back to an idea that has been discussed before, namely marking up thread pages as an unordered list. After all, a thread page really is a list of posts, so that makes semantic sense to me.

---

ETA: I've been thinking about markup a lot lately. There are quite a few changes that I think would be beneficial, as well as being easy to implement. My intention is to start working on these too.

1/ .cat_bar, .title_bar - These suck. (http://www.councilofexmuslims.com/Smileys/custom/yes.gif)

The only reason .cat_bar and .title_bar went into 2.0.x markup was to enable supporting roundy bar ends in old versions of IE. Since we don't care about that any more, and since the divs have no semantic value, IMO those classes are superfluous.

They're not being used in the default styling at all now, and having thought about it I cannot see how removing them would restrict custom theming much, if at all. I could even easily do roundy bar ends in IE8 without those classes and without js patches.

2/ .catbg and .titlebg - These aren't much better.

First thing is that .catbg2 and .titlebg2 should defo be killed. They're very rarely used and getting rid of them is easy (have done on local).

As for the others (.catbg and .titlebg) the problem is they are too generic, which just ends up complicating the CSS. You often want different styling for table_grid headers and for other headers, so thumping them with the same classes makes no sense. It's just more stuff try and override.

Also, there's no semantic sense to these classes. At the moment .catbg can be either a category header, or a thread page header or a table column header, or several other things. Ditto for .titlebg. Then there's the whole "bg" thing, which would imply that .catbg provides backgrounds for entire categories, which it doesn't do at all.

I'm thinking these classes should be replaced with something like headerbar_h3, headerbar_h4, header_th, etc. This would make a lot more sense.

3/ Tables - Old classes not making much sense here either.

Leaving the headers aside for the moment, and just talking about the tbody stuff, with the new theme we're going for subtle zebra striping on rows. IMO, this is a well-proven way of making densely formatted tables more readable. For forum stuffz, I think it makes a lot more sense than colouring by column.

So that we have class names that do what they say on the tin, and so that we don't have to use efficiency abominations like tr.windowbg2, I think it would be best to use classes like .tablerow1 and .tablerow2. These should only be applied to the .table_grid class, not to any others. The board index and child boards already have their own styling for all cells, and nobody ever styles them by alternating rows.

4/ Which brings us to .windowbg and .windowbg2 - These are horrible too.

We all know what a window is. It's one of those things you open new stuff in, and can be resized and dragged and closed and whatever. That's what "window" means to most people online. Using .windowbg as a class name for something completely unrelated is semantic stupidity, IMO.

For the board index and child boards tables, there's no need for these classes. These tables already have CSS for every cell, and those cells already have their own individual classes. Imposing extra generic classes on top of those is just bonkers.

For the message index table, the same applies. Every cell already has its own class. The generic ones are just bloat, and just make markup and CSS more complex. They should be dropped.

These generic classes make no sense anywhere else either. For thread pages, if you want alternating classes it would make much more sense to use .postbg and .postbg2. I'm not even sure we need to provide for alternating classes in thread pages though, since frankly they seem to be out of fashion and IMHO are unlikely to return. Still, providing for them is fairly simple, but if we are going to do it it should be done by a sensible class.

---

Next bit: HTML5 stuffz.

Yes, it's all terribly exciting. However, there's still a lack of consensus in some areas as to how certain tags should be used in certain cases.

IMO, the first point to bear in mind is that, apart from code junkies, the only people who care about markup are blind people. Everyone else only cares about how it looks, not about how it runs. So, I'm mainly concerned about tag additions/changes that will enhance a11y for such people. If a change doesn't do that, I'm not that fussed about it.

My 2c is that we should use HTML5 tags where the use of a certain tag is unambiguous. For example, timestamps should use an HTML5 time tag. No worries.

Where the use of a tag is debatable, my 2c is that to save time and aggravation we should just do it old school (but still semantic). Once everything is more sorted, and once there's established consensus on tag usage, people can always look over the less-finished-than-it-is now product and suggest tag changes.

Quote from: Xarcell – June 28, 2013, 10:08:32 amAs far as the windowbg and windowbg2, I think they should be renamed to "content_bg" and "post_bg", not "postbg" and "postbg2", because not all areas which use the class is a post.

Quote from: TestMonkey – June 28, 2013, 10:14:24 am

Quote from: Xarcell – June 28, 2013, 10:08:32 amAs far as the windowbg and windowbg2, I think they should be renamed to "content_bg" and "post_bg", not "postbg" and "postbg2", because not all areas which use the class is a post.

Wouldn't that be, "content_bg" and "content_bg2"? Just wondering (I have no issue with any), because I'm not sure I see the (consistent) meaning otherwise.

Quote from: Xarcell – June 28, 2013, 10:08:32 amInteresting thoughts here. I would like to share my own...

Article tag should definitely be used. The W3C Spec (http://www.w3.org/TR/html5/sections.html#the-article-element) says this:

QuoteThe article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

"Syndication", "reuseable" and "form post" being the keys words here.

QuoteThe problem is, if you read the actual HTML5 specification, the elements in HTML5 are defined in a way that has little to do with how we have traditionally used them.

On the one hand, Hickson has introduced a whole new concept of structuring a web page in HTML5 with sectioning elements. On the other, Hickson is comparing his HTML5 sectioning elements to classes used in the wild with no understanding of what those classes were actually used for.

QuoteHTML5 wants to be backwards compatible, so the WHATWG decided not to introduce an h element (despite introducing a bunch of new sectioning elements), and instead wants to repurpose the h1 element to be the generic h element. Use h1 everywhere, and let the HTML5 outlining algorithm determine its true level… or so the theory goes.

This is a terrible idea for several reasons, the two main ones being accessibility and styling.

Accessibility

Using h1 everywhere is very bad for accessibility. Blind users rely heavily on the heading structure of a site. It’s important for all of us to be reminded of just how crucial heading structure is for accessibility purposes. For instance, a December 2008 survey of over 1000 screen reader users conducted by WebAIM found that 76% of blind and vision-impaired users ‘always or often’ navigated by headings when they were available. And a May 2012 survey found that 82.1% heading levels were ‘very useful’ or ‘somewhat useful’ when navigating a web page. (This is good, practical research, so take note.)

<snip>

Styling

But it gets worse. Lets say we want to run with a pure HTML5 outline, and we use h1s everywhere. Remember, in the HTML5 spec the h1 is just a generic h element; its real level is determined by how deeply its nested in sectioning elements.

So how do we style it? Well, we could add class names to all our h1 elements so we can pick them out, but that is contrary to the stated HTML5 goal of simplifying authoring; and we may as well stick to h1-h6 (all of which are treated as generic h elements in a HTML5 outline).

Here’s the generic style for an h3 element:

Code: [Select]

article aside nav h1, article aside section h1, 
 article nav aside h1, article nav section h1, 
 article section aside h1, article section nav h1, article section section h1, 
 aside article nav h1, aside article section h1, 
 aside nav article h1, aside nav section h1, 
 aside section article h1, aside section nav h1, aside section section h1, 
 nav article aside h1, nav article section h1, 
 nav aside article h1, nav aside section h1, 
 nav section article h1, nav section aside h1, nav section section h1, 
 section article aside h1, section article nav h1, section article section h1, 
 section aside article h1, section aside nav h1, section aside section h1, 
 section nav article h1, section nav aside h1, section nav section h1, 
 section section article h1, section section aside h1, section section nav h1, section section section h1 { 
    font-size: 1.00em; 
 }

Yet that’s what HTML’s structural elements give us. What a mess.

QuoteIt’s reasonable to suggest that perhaps user agents in the future, such as browsers and screen readers, will do more with HTML5′s structural elements, and that will make them more palatable to us as authors.

Opera’s Bruce Lawson suggested just that on the WHATWG mailing list in 2009:

    "After all, I know of no user agents that can use time, section, footer, datagrid etc but we mostly expect there to be soon.“

And here’s what Hickson, the HTML5 editor, said in reply:

   " I don’t. Most of the new elements are just meant to make styling easier, so that we don’t have to use classes.“

All that, and the editor doesn’t see user agents ever even using these elements. They are there, he says, to save us from using classes. Put another way, the creator of these elements seems unsure why they’re even in the spec, save ‘making styling easier’.

QuoteConclusions

Let’s wrap up with some conclusions.

    Headings matter: first, we should really care about the heading structure of our pages to help out blind and vision-impaired users trying to get around with screen readers. The venerable h1-h6 elements may be limited, but they’re relied on heavily by screen reader users.

    HTML5 structure is a mess: we should probably ignore HTML structural elements altogether. They’ve been a bit of a disaster — we have essentially forked the spec, created plenty of broken outlines, and wasted too much time already trying to get our heads around a fundamentally broken system. Long live divs.

    Consider ARIA landmarks: adding ARIA landmarks to your site is another simple, effective way of helping screen reader users.

    Consider schema.org and the future of semantics: schema.org has the backing of the major search engines, and while it’s certainly a mixed bag at the moment, it seems to be future for structured data on the web.

There are lots of good parts in the HTML5 specification, from new forms features to the History API and Canvas implementation. In fact, without the WHATWG, who have been the driving force behind HTML5, we’d still be stuck with HTML4/XHTML 1.0 while we waited for the W3C to get their act together. Nevertheless, just because HTML5 and all the related technology around it is new and exciting, it doesn’t mean we have to accept everything we’re given.

Sometimes it’s worth seeing how the HTML sausage is made, so we know what we’re eating. And in the case of HTML’s structural semantics, I’d rather pass.

QuoteLet me give you an example.

The spec says <header> and <footer> elements
define areas within a section, but do not define sections themselves, and so won’t
show up in a document outline.

This is something most people get wrong,
including those teaching HTML5 through books and blogs, whose examples
often show <header> being on par with <section>

 The spec also says
<header> and <footer> can be used multiple times per page (once per section,
for example), but you would never pick that up from most HTML5 resources out
there.

These may seem like pedantic, wonkish points. But they illustrate something
very serious—the community is trying to implement HTML5 markup in a way
that doesn’t have much relation to the actual HTML5 spec. It’s a weird inbetween
state of markup limbo that has inadvertently appeared because that’s
what everyone assumed these elements should be used for.

Quote from: emanuele – July 01, 2013, 01:18:10 pm/me is tempted to push the "like" button...

NO! Better write it. :+1: (/me thinks we need a :+1: smiley :P)