This file is deprecated, like all browser-specific CSS files since the nifty "body id by browser" idea was implemented. Just remove webkit.css from the repo. You know you want to. :P
Oh and while you're at it :D this stuff can go from index.template.php:
// Quick and dirty testing of RTL horrors. Remove before production build.
//echo '
//<link rel="stylesheet" href="', $settings['theme_url'], '/css/rtl.css?alp21" />';
That was handy when the template had the extra stuff for rtl variant css files, but you've dropped that. Not a bad idea dropping it, since most themers don't even know what rtl.css is, let alone variants for it. Anyone who actually needs rtl variant files (like if using the variant system for layout variants) will know enough to write their own code to call them.
Oh and it might be advisable to do this a bit differently:
// This bit of template is used by default in the main menu to create the number next to the title of the menu to indicate for example the number of unread messages
$settings['menu_numeric_notice'] = ' [<strong>%1$s</strong>]';
Not sure it's worth hard coding the square brackets and strong tag in the template. Not a big deal if it stays, since it'll do the job for most mugs, but could also be handled just with a span and class, with all presentation handled in the css file. Random thoughts. :)
This is a tad peculiar too:
'current_page' => '<span class="pagelink current_pagelink"><span class="current_page"><strong>%1$s</strong></span></span>',
Why for it need span class="pagelink current_pagelink" AND span class="current_page" AND strong? Three containing elements? Ok, it'll never be able to break out and run away with all that around it, but span class="current_pagelink" should be just as effective.
Except that it's not actually a link for the current page, just a bit of text, so class="current_page" would make more sense.
ETA: Hmm. More funny critters lurking in the undergrowth.
'expand_pages' => '<span class="expand_pages" onclick="{onclick_handler}" onmouseover="this.style.cursor=\'pointer\';"><strong> ... </strong></span>',Can't see the need for strong tags there either, or for the mouseover for the cursor. Just having .expand_pages {cursor:pointer; font-weight: bold;} in the css should do it. Doesn't need js for the cursor.
<span class="pagelink current_pagelink">
yep, that's indeed enough for styling.. the others (inner span and strong) are leftovers from implementation..
Edit: will be fixed soon,
https://github.com/elkarte/Elkarte/pull/499
But it's not a link. The current page doesn't have any anchor attached to it. So, it doesn't make sense for the class names to include "link", and if you're having a current_page class to style it the pagelink class is just bloat. :)
yep, that name might be not perfect, should change it probably..
RE: the classes I left it there because of easier styling.. all elements in that section use
.pagelink, .expand_pages {
border-top: 1px solid #ccc;
border-right: 1px solid #ccc;
border-bottom: 1px solid #ccc;
padding: 1px 5px;
background: #efefef;
display: inline-block;
}
the current_pagelink class extends these borders &background images with another color and bold text style.
.current_pagelink {
color: #aaa;
font-weight: bold;
} We could remove that class from the HTML and move borders and background to the curren_pagelink class, but how would you add rounded borders to the first and last child if current_pagelink is the first or the last child?
.pagelinks .pagelink:first-child {
border-top-left-radius: 4px;
border-bottom-left-radius: 4px;
border-left: 1px solid #ccc;
}
.pagelinks .pagelink:last-child {
border-top-right-radius: 4px;
border-bottom-right-radius: 4px;
}It might be possible but I think all elements in a structure should use the same class, just for the sake of readability.
<ul class="mylist">
<li class="list_item">...
<li class="list_item active">...
<li class="list_item">...
</ul>
How about this?
.pagelink, .expand_pages, .current_page {
border: 1px solid #ccc;
border-left: none;
padding: 1px 5px;
background: #efefef;
display: inline-block;
}
.current_page {
color: #aaa;
font-weight: bold;
} Would have to try this live, but shouldn't this work just as well?
.pagelinks span:first-child {
border-radius: 4px 0 0 4px;
border-left: 1px solid #ccc;
}
.pagelinks span:last-child {
border-top-right-radius: 4px;
border-bottom-right-radius: 4px;
}
mhh, yes.. will try it ;)
Another option: maybe you could do the roundy border on the pagelinks div itself, and just set left borders on the spans, with no left border on the first child. That should, in theory, be faster to process. Last child is the slowest out of first, only and last.
ETA: Or.............................
why have a div and spans anyway? Why not just a ul, or one of the nifty new HTML5 tags?
Example:
<menu><a>Previous shiz</a><a>1</a><a>2</a><span>Ok so you have one of the buggers for the current page</span><a>4</a><a>Next shiz</a></menu>
/me hasn't dug too deeply into all the new HTML5 tags, so this is just an idea.
yep, using <nav> + childs seems to be the best option for semantic, anyway we'd need an <ul> and <li> inside.
The content is a list of elements, using <ul> and <li> seems just logical.
The nav tag is apparently for primary navigation stuff, like main menu and footer link directory. Wouldn't really suit for minor stuff like page links, AFAICT.
Also, I can't see the point of using a new html5 tag just as bloat to wrap an old block level element like ul. I'd either use just menu + anchors (html5 minimal markup) or just ul and li (old style but arguably just as good).
If you get into putting new html5 tags around existing elements that will do the job, it's really just divitis all over again IMO. Seems that way to me anyway. "Best practice" for this new stuff seems to be still evolving.
Ah. Looks like I might be wrong about menu. It's not currently supported by any browsers anyway. :D Looks like it'd have to be nav.
W3 says "The nav element represents a section of a document that links to other documents or to parts within the document itself; that is, a section of navigation links."
ETA: MDN says "The HTML Navigation Element (<nav>) represents a section of a page that links to other pages or to parts within the page: a section with navigation links."
So that would be cool for page links I suppose, if "the document" is taken as being the topic rather than the post. Who knows? :o
Menu will take li as child though, which would be very cool if someone supported it.
Would this work for you?
<menu class="pagination">
<li class="prev_page"><a href="prev">previous page</a></li>
<li><a href="page1"></a></li>
<li class="active">2</li>
<li><a href="page3">3</a></li>
<li class="expand_pages"><a href="expand">...</a></li>
<li><a href="page20">20</a></li>
<li><a href="page20">20</a></li>
<li class="next_page"><a href="next">next page</a></li>
</menu>
It'd work for me, but unfortunately it wont work for any browser that I know of. The menu tag apparently has zero browser support at the moment.
http://caniuse.com/#search=menu
that matrix seems outdated,
<!doctype html>
<html>
<head>
<style>
menu { clear: left;}
li {float: left; padding: 0 5px; margin: 0; list-style-type: none;}
menu li {border-top: 1px solid grey; border-bottom: 1px solid grey; border-right: 1px solid grey; background-color: #eee;}
menu li:first-child {border-left: 1px solid grey; border-radius: 4px 0 0 4px;}
menu li:last-child {border-radius: 0 4px 4px 0;}
</style>
</head>
<body>
<menu class="pagination">
<li class="prev_page"><a href="#">previous page</a></li>
<li><a href="#page1">1</a></li>
<li class="active">2</li>
<li><a href="#page3">3</a></li>
<li class="expand_pages"><a href="#">...</a></li>
<li><a href="#page20">20</a></li>
<li><a href="#page20">20</a></li>
<li class="next_page"><a href="#">next page</a></li>
</menu>
</body>
</html>
works fine for me in Chrome 27, IE10 and Opera 12.15 .. haven't tested Firefox.
Oh good. Well that's kinda handy then. MDN was still saying it wasn't supported too.
Anyway, what I was getting at before is that you should be able to set your border on the parent element ("pagination") and then you only have to do the left borders on the li bitz (except for first-child).
<style>
.pagination {border: 1px solid grey; border-radius: 4px; clear: left;}
.pagination li {float: left; padding: 0 5px; margin: 0; list-style-type: none; border-left: 1px solid grey; background-color: #eee;}
.pagination li:first-child {border-left: none;}
</style>
If the menu isn't floated, you'd need a clearfix of some sort to get the border to wrap the content. I think in practice it will be floated though. Or, you could just use inline-block instead of float on the li, which shouldn't need a clearfix.
Oh while we're on menus, might as well talk about hidden content. Superfish, and most of the other js, basically relies on display: none; to hide collapsed content. That's good for sighted users, but as you'd be aware it's bad for screen readers because the content will also be hidden from them. So, the risk is that it'll be so well hidden that blind peeps wont even know it's there.
Traditional a11y workaround was to try and avoid display: none; but there's a better way of handling it. http://www.w3.org/TR/wai-aria/states_and_properties
The main one of interest here is http://www.w3.org/TR/wai-aria/states_and_properties#aria-haspopup. If that's put in the markup for any parent that contains hidden content, straight away any screen reader will notify the user that there's a droppy menu or whatever waiting in the wings. This means display: none; now works as well for blind peeps as it does for sighted peeps, with no other workarounds required.
This WAI-ARIA stuff has very good browser support (IE8 is fine) and will validate with Elk's HTML5 doctype.
You can also use WAI-ARIA roles to give good a11y for lists. Taking the current main menu as an example, this is how it looks in the repo now:
function template_menu()
{
global $context, $settings, $txt;
echo '
<div id="main_menu">
<ul class="dropmenu topmenu" id="menu_nav">';
// Note: Menu markup has been cleaned up to remove unnecessary spans and classes.
foreach ($context['menu_buttons'] as $act => $button)
{
echo '
<li id="button_', $act, '" ', !empty($button['sub_buttons']) ? 'class="subsections"' : '', '>
<a class="', $button['sub_buttons'] ? 'submenu' : '', !empty($button['active_button']) ? ' active' : '', '" href="', $button['href'], '" ', isset($button['target']) ? 'target="' . $button['target'] . '"' : '', '>', $button['title'], '</a>';
// does it have child buttons? (2nd level menus)
if (!empty($button['sub_buttons']))
{
echo '
<ul>';
foreach ($button['sub_buttons'] as $childbutton)
{
echo '
<li ', !empty($childbutton['sub_buttons']) ? 'class="subsections"' : '', '>
<a href="', $childbutton['href'], '" ' , isset($childbutton['target']) ? 'target="' . $childbutton['target'] . '"' : '', '>
', $childbutton['title'], '</a>';
// 3rd level menus :)
if (!empty($childbutton['sub_buttons']))
{
echo '
<ul>';
foreach ($childbutton['sub_buttons'] as $grandchildbutton)
echo '
<li>
<a href="', $grandchildbutton['href'], '" ' , isset($grandchildbutton['target']) ? 'target="' . $grandchildbutton['target'] . '"' : '', '>
', $grandchildbutton['title'], '
</a>
</li>';
echo '
</ul>';
}
echo '
</li>';
}
echo '
</ul>';
}
echo '
</li>';
}
This is how it would look with the WAI-ARIA stuff for a11y:
function template_menu()
{
global $context, $settings, $txt;
echo '
<div id="main_menu">
<ul class="dropmenu topmenu" id="menu_nav" role="menubar">'; // Note role="menubar" added here.
// Note: All li's have role="menuitem" added. Also, li's which contain subsections have aria-haspopup="true". Nested ul's have role="menu".
foreach ($context['menu_buttons'] as $act => $button)
{
echo '
<li id="button_', $act, '" ', !empty($button['sub_buttons']) ? 'class="subsections" aria-haspopup="true"' : '', ' role="menuitem">
<a class="', $button['sub_buttons'] ? 'submenu' : '', !empty($button['active_button']) ? ' active' : '', '" href="', $button['href'], '" ', isset($button['target']) ? 'target="' . $button['target'] . '"' : '', '>', $button['title'], '</a>';
// does it have child buttons? (2nd level menus)
if (!empty($button['sub_buttons']))
{
echo '
<ul role="menu">';
foreach ($button['sub_buttons'] as $childbutton)
{
echo '
<li ', !empty($childbutton['sub_buttons']) ? 'class="subsections" aria-haspopup="true"' : '', ' role="menuitem">
<a href="', $childbutton['href'], '" ' , isset($childbutton['target']) ? 'target="' . $childbutton['target'] . '"' : '', '>
', $childbutton['title'], '</a>';
// 3rd level menus :)
if (!empty($childbutton['sub_buttons']))
{
echo '
<ul role="menu">';
foreach ($childbutton['sub_buttons'] as $grandchildbutton)
echo '
<li role="menuitem">
<a href="', $grandchildbutton['href'], '" ' , isset($grandchildbutton['target']) ? 'target="' . $grandchildbutton['target'] . '"' : '', '>
', $grandchildbutton['title'], '
</a>
</li>';
echo '
</ul>';
}
echo '
</li>';
}
echo '
</ul>';
}
echo '
</li>';
}
Pretty simple changes, but very effective for screen readers. Since the main purpose of using new HTML5 elements like nav and menu is for a11y (sighted users don't give a rat's how things are marked up) IMHO this is every bit as good as more trendy wrapping elements. :)
I'd suggest using this sort of thing for a11y wherever Elk has collapsible content that relies on display: none;
Note that standard tooltips (title attribute) are not considered to need any indication via aria stuffz, since screen readers already deal with titles with no probs.
So, as far as a11y goes you could equally well mark up your pagination like this:
<body>
<ul class="pagination" role="menubar">
<li class="prev_page" role="menuitem"><a href="#">previous page</a></li>
etc, etc....
That might not get HTML5 fanboyz as excited as using a menu or nav tag as a wrapper, but for all practical purposes it's every bit as effective, and it has browser support back to the stone age.