Semantics, HTML5, and other gruesomeness. 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 authorsUm, 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. 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.
Re: Semantics, HTML5, and other gruesomeness. Reply #1 – June 24, 2013, 02:32:15 am Absolutely 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 strucure, though:<h3 class="content_header"> for cat_bar, catbg<h4 class="content_header"> for title_bar, titlebg<p class="post_content"> for windowbg<p class="post_content_alternate"> for windowbg2<p class="post_conent_unapproved"> ...Re HTML5: I've added some HTML5 additions in earlier PRs, mainly enhancements for the <input> boxes (placeholders, autofocus, email input and some <time> tags.. ) I was thinking about adding <input type="date"> for birthdays, calendar and other date related fields, but that's a bit more complex since some of the are splitted <inputs> and allow partial content (the birthday for example has inputs for year, month and day and you can fill only some of them)I'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>
Re: Semantics, HTML5, and other gruesomeness. Reply #2 – June 24, 2013, 04:11:13 am 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, titlebgEhhhhhhhhhhhh.........no. Not quite.First 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. Getting rid of the divs is easy, and wont mess up theming. On my local host they aren't being used for anything at all now. I could wipe the lot of them without any problem.Second thing is that I do not want the h3 and the h4 to have the same class name. I'm trying to avoid calling by tag name, as much as is humanly possible. It's the least efficient way to call things in terms of processing*. It's also more confusing. The class names should clearly distinguish between the two elements.Quote<p class="post_content"> for windowbg<p class="post_content_alternate"> for windowbg2<p class="post_content_unapproved"> ...Those look ok to me, in general, but I'm not sure on the names. They will contain the .poster areas and sigs, as well as actual post content. Something with "background" sort of seems more appropriate. I'm also not sure we should use p tags for them. My 2c is that li makes more sense.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>.Not sure. IMO, header seems more suitable for headers, like the current h3 stuffz. I'm not that thrilled about the section tag either. Div is supposed to have no semantic meaning, but it's just short for division. A div is a division of the page. In English, at least, section means much the same thing. I honestly cannot see how the latter is more meaningful than the former. They seem to me to mean the same thing. Hey ho.*Re selectors and processing stuffz: I would prefer to make as many selectors as possible as efficient as possible, for two reasons. First is that, as in the case of the drop menus, having clearer and more targeted classes and id's is usually less confusing when it comes to reading the code.Second is that regardless of how efficient our selectors are in theory, in practice about half of them will be about twice as slow as they are meant to be. Why? Because we're using variants. Using variants means that a lot of selectors will have to be processed twice: first in index.css and then in the _variant.css.This wont happen for every selector, but it will happen for a substantial number of them. It wont kill performance if it's done sensibly, but it's something to bear in mind. In view of that, we should avoid calling by HTML tag name as much as possible, and we should avoid calling by descendants as much as possible.CSS is the opposite to javascript in one odd way. In both CSS and js, calling by id is the most efficient. They differ when it comes to tag names and class names. CSS is faster calling by class name, and js is faster calling by tag name. Also, if you have to call a class in js it's best to tie it to its tag (like ul.quickbuttons) whereas if you need to call a class in CSS you should totally avoid tying it to its tag (just .quickbuttons is much better).
Re: Semantics, HTML5, and other gruesomeness. Reply #3 – June 24, 2013, 04:50:50 am 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.Yep, but that's what I suggested.. I think you misread (or I was unclear, dunno) . Instead of <div class="cat_bar"><h3 class="catbg"> ... use <h3 class="blablabla"> (without that outer div)
Re: Semantics, HTML5, and other gruesomeness. Reply #5 – June 24, 2013, 06:57:33 am They specifically state forum posts. I don't think it gets clearer than that. They didn't say blog posts which have a clear topic and comments. There are even examples of its usage as forum posts around. Every forum post stands alone with clear author, content, header (time at the very least but also the subject).I didn't want to post because I was just doing it on another thing I am doing and was on #elkarte anyway. It's not a what's new today thing, it is clear and simple and allows for better CSS targeting at least. Also, there are no downsides afaict.
Re: Semantics, HTML5, and other gruesomeness. Reply #6 – June 24, 2013, 09:26:29 am No, it doesn't allow for better CSS targeting, because we shouldn't be calling by tag name anyway. We particularly shouldn't be calling by tag name in combination with class name. The tag names shouldn't appear in the CSS at all, except in very rare instances where they can't be avoided. So, whatever tag we choose is effectively neutral for CSS targeting.The problem with the W3C spec is that it's contradictory (which wouldn't be the first time). Take the post you just made. It doesn't stand alone, because it's a direct reply to one of my posts. If taken out of that context, your posts doesn't make sense. This is common with forum posts.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...Also:Quote from: HTML5 DoctorThe tricky part is, what exactly is an independent item of content?The smell test for going independentAn 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.This is the problem, IMO. Forum posts often do not make sense when the surrounding content is stripped away. I'm sure you can think of plenty of examples of that. So, if that's one of the main criteria for the use of an article tag, then it woud seem as if an article tag is not appropriate.Bear in mind that the current W3C spec is a nightly draft, not a final standard.
Re: Semantics, HTML5, and other gruesomeness. Reply #7 – June 24, 2013, 10:47:59 am I think that for the most part, the original post in a topic definitely fits that description. It's always the topic that starts the discussion. Much like it is on news sites and even blogs. Article fits nicely IMO.
Re: Semantics, HTML5, and other gruesomeness. Reply #8 – June 24, 2013, 10:50:47 am 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.And some don't even make sense with the context surrounding them (like my posts ).
Re: Semantics, HTML5, and other gruesomeness. Reply #9 – June 24, 2013, 12:08:57 pm I noticed that the validator complains about the use of both "article" and "menu" when using HTML5 doctype..so I am not using those now. But it does makes some sense to use article for forum posts..though I am more inclined to use article on the whole subtemplate, that is: everything between header/footer templates and not just single posts. "section" is also nice to use - or just plain ol' div. EDIT: on Brad's comment that the original post might be best as "article" - that fits nicely with my work, since I use original post in several of the boardtypes, even lon in the topic since other posts are considered "comments" . Hm, must investigate further.
Re: Semantics, HTML5, and other gruesomeness. Reply #10 – June 24, 2013, 06:07:53 pm I still reckon it's a list of posts. Agree article might fit for the OP of most threads, but when you get a string of posts that just contain a few smileys or a ROFL or two, calling them "articles" stretches the definition of the word to ridiculous extremes. In other words, it's bad semantics.Anyway, like I said, it's only code junkies who are going to care. I doubt any of this is going to help a11y users at all. For instance, I know people on screen readers tend to navigate by h tags, so we should make sure there are enough of those, in the right places, and with a hierarchy that makes sense. That was an SMF fail, because SMF went straight from h1 to h3. There was never any h2.Taking the board index as an example, h1 is up in the header. The next headings as such are the category header bars, so really they should be h2. The board name should be h3, with possibly an h4 on the last post link. Some way of grabbing the last post link quickly when you can't see it would be good.
Re: Semantics, HTML5, and other gruesomeness. Reply #11 – June 28, 2013, 10:08:32 am Quote from: Antechinus – June 23, 2013, 06:17:25 pmQuote 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 authorsUm, 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. 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.Interesting thoughts here. I would like to share my own...Article tag should definitely be used. The W3C Spec 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.I agree that "catbg" and "titlebg" should not even be used anymore. It would be more appropriate to use the body class in conjunction with the header element. Example:.action_messageindex h2, .action_home h2, .action_search h2 { background: green;}Table classes should definitely be addressed. They are still the only thing within the stylesheet file that I find confusing at times.As 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. I personally hate using numbers in classes unless it's semantically necessary such as a board number or topic number. Note, that you could also use "content_stn", "content_alt", and "post_stn" "post_alt" for more added flexibility(stn = standard).
Re: Semantics, HTML5, and other gruesomeness. Reply #12 – 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.
Re: Semantics, HTML5, and other gruesomeness. Reply #13 – June 28, 2013, 10:24:18 am To add to some of the comments here. Article tags, Section tags, H1 tags, and others can all be used several times within a web page and it's still semantic. As far as the first post, that's what microdata(schema.org) is for: itemscope="" itemtype="http://schema.org/Article" should be used on the first post, while comments to that first post should have "http://schema.org/UserComments"See, a bot recognizes good semantics for SEO, however it has no idea what the first post is. So it doesn't help anymore to use only the article tag for only the first post. If the bot was any smarter, it would be wondering why it wasn't used for the rest of the posts, because all of it's content is unique. It should be used for all posts, just as the spec says. If you want an indexing bot to understand the difference between a actual article and it's comments, you use the microdata.
Re: Semantics, HTML5, and other gruesomeness. Reply #14 – June 28, 2013, 10:26:25 am Quote from: TestMonkey – June 28, 2013, 10:14:24 amQuote 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.Ant's suggestion was to use "postbg" and "postbg2", that's why I said that. As I said before, I agree they should be changed, but I also believe number's should not be used. That's why I suggested "content_stn" and "content_alt"...
Modern, Free, Powerful