[jQuery] Re: Superfish plugin: some limitations that could be addressed
We're going in circles here. showed you an example of a multi column div in a sub, had h tags, image, and assorted other markup did you even look at it? Plugin code was untouched, any adjustemnts were done with css Yes i did look at that example, and analyzed the HTML code for it. Yes it works. Yes it uses Superfish with no hacks to the plugin. BUT, this example is using a UL with a single LI element that's assuming the role of a semantically neutral container (for styling purposes). In HTML, the only block-level semantically neutral container is the DIV element. Period. This is what the HTML 4 and HTML5 specs say. Which is why i believe this solution that works visually is not good enough. The YUI example is a good example because they are using the right elements for the job: two nested DIVs. (They could use just one for that example, but i suppose they want to offer a simple template with more styling hooks for users.) You then wrote: “The exact same markup in YUI example bellow works perfectly well...no hacks needed”. This is wrong. Can you REALLY use the same HTML markup as the YUI, and make the full Superfish functionnality work? I can do that... by hacking the Superfish source. The problem i'm talking about is a problem of HTML semantics. I'm not asking if you can do a mega-dropdown with Superfish, because you can, as your first example shows, and as my own tests showed me even before that. I'm saying that you can't do it using the adequate HTML elements, which i think is a problem. Not a huge problem, but a problem nonetheless.
[jQuery] Re: Superfish plugin: some limitations that could be addressed
The exact same markup in YUI example bellow works perfectly well...no hacks needed In my experience, it doesn't work. As i wrote earlier, most Superfish functionality will work, but if you use something else than a UL as your submenu, even if it's just wrapping a UL in a DIV for styling purposes, then the animation effects won't work. Superfish won't find the element it's looking for when trying to apply an animation, and thus the animation will fail. But i may be mistaken. Are you able to make the animation effects work with the same code as the YUI example, without hacking the Superfish code? Say you want to animate the height and opacity of the submenu, and as per the YUI example your submenu is a DIV containing a DIV containing a UL. Does it work for you?
[jQuery] Re: Superfish plugin: some limitations that could be addressed
Thanks for this example. there's no doubt in my mind that YUI team hasn't processed all the issues you bring up when making their determinations on structure I don't know if they have. The YUI developers are very capable people, but this does not totally guarantee that YUI is accessible or that they don't get things wrong sometimes. But i can see that they're doing exactly what i'm saying that Superfish should allow. What YUI 3.0 Menu has: ... li a class=yui-menu-labelSubmenu title (e.g. category name)/a div class=yui-menu div class=yui-menu-content ul li class=yui-menuitem.../li li class=yui-menuitem.../li /ul /div /div /li ... This is perfectly fine. There are two containing DIVs, which has no semantic and accessibility impact (DIVs are neutral). Then the content of the submenu, which in this case is a UL list with one LI for each submenu item. Nothing wrong here. This is exactly the structure i had to code, and why i had to hack Superfish which doesn't allow it. ;) So what i had to code would fit perfectly with this YUI widget: ... li a class=yui-menu-labelCategory name/a div class=yui-menu div class=yui-menu-content pShort description of the category's content/p ul li class=yui-menuitem.../li li class=yui-menuitem.../li /ul /div /div /li ... Meanwhile, what you said was fine (and i believe is not, though it's not a BIG issue) is, using similar classes: ... li a class=menu-labelCategory name/a ul class=menu li class=menu-content pShort description of the category's content/p ul li class=menuitem.../li li class=menuitem.../li /ul /li /ul /li ... (Or maybe with a DIV between the container LI and the submenu's content, to avoid problems with current Superfish inner selectors.) Regarding higher powers, i should consult with accessibility experts i know about using a one-item unordered list as a container (just because Superfish requires it...). It's not elegant, and i suspect it might cause problems to some screen-reader users, but they may be able to confirm how significant those problems would be. Anyway, being forced to use subpar HTML code because a JS script requires some particular tags is never a good thing. In this case the consequences may be benign (or not...), in other cases they may be quite bad.
[jQuery] Re: Superfish plugin: some limitations that could be addressed
not sure what you mean by hack or abusing the ul/li elements HTML 4.01 defines a set of elements, each with its own semantics. Some are meant as generic wrappers or containers in order to support language or style information (that's the DIV and SPAN elements). Others have a more precise meaning and are meant for a rather specific kind of content (the HN elements, P, UL, EM, etc.). I'm saying using a UL with a unique LI (like in your example) when what you actually need (semantic-wise) is a neutral wrapper like a DIV is abusing HTML 4's semantics. It's not a big deal (the worse it could cause is a bit of confusion for users who rely on the semantic information in some way), but having to use a UL element even when it's not appropriate is not a good thing. only interpretation can think of for abusing is invalidation I was thinking of HTML semantics. You can write perfectly valid code that makes absolutely no semantic sense, and as such won't degrade gracefully when styles are not applied, will not be accessible with a screen reader, etc. For instance you could code a website's content with DIV elements only, content images as CSS backgrounds, everything absolutely positioned, etc. It would be valid, but it would be awful code nonetheless. Validity is a tool, not a token of quality.
[jQuery] Re: Superfish plugin: some limitations that could be addressed
there is no reason not to be able to build a mega menu inside UL/LI structure and this has been done in superfish Sorry, but i think this is a mistake. This is the kind of code that Superfish expects: ul id=menu li a href=#Category name/a ul class=submenu.../ul /li /ul You don't have to use a A element for the first-level name i think, but you do have to use a UL for the submenu (while the submenu class in this example is just for clarity, it's not required). You can't do this, as part of the features of Superfish will then fail: ul id=menu li a href=#Category name/a div class=submenu.../div /li /ul Sure, you can try to use a UL element for the submenu, put a unique LI inside, and then stuff whatever content you want in that LI (someone is giving that advice here, as the first name is the same it could be you ;) http://www.nabble.com/Superfish:-Mega-Menu-Ability-td23632675s27240.html). If you do that, it will work, but it'll be a hack (you're abusing the UL/LI elements). You may use a UL for the submenu, and use a set of LI elements for different contents, say a first LI for a top image, another LI for some inner title, a set of LI for links, another LI for a second inner title, another set of LI for links, and a final LI for a bottom image. That will work, but once again this is abusing the basic HTML semantics. Of course if you don't care about semantics and accessibility, that's not an issue. I happen to care. :) I see a few different “good” answers to that problem. One is to amend Superfish to make it more flexible (i.e. make this a configuration option, test, document). One is to declare that Superfish is not meant for mega-dropdowns or any rollover menu that needs anything else than an unordered list of links for a submenu, which would be a perfectly valid answer too. I vote for the first answer, though. And i may have missed a few other solutions. But abusing HTML semantics is not a solution in my book. I may resort to it if i really need to, but i think it should be avoided. Thanks for the input.
[jQuery] Re: superfish navbar - how do I center the whole bar?
Hello, This is a CSS issue, not really related to Superfish or jQuery. The solution depends on your code, and also on the browsers you want to support (IE 6 and 7 will limit what you can do). If your UL has a fixed width, you can center it horizontally in its container using automatic margins. Insert search engine name is your friend. If the container has a fixed width too, using some padding or a margin might do the trick too. If the width of your UL element can't be predicted, it gets harder. Using text-align:center won't work because your top-level LI are not text, they are blocks, most probably floated blocks (i don't know what your code looks like, but this is the most common solution). You can't center blocks using text-align:center. You CAN center inline-block elements, so it may be tempting to use display:inline-block on your top-level LI (and no float), but IE 6-7 won't support that. Likewise, using display:table-cell on your top-level LI elements is not an option if you want to support IE 6-7. So, if your series of top-level LI has an unknown, variable width, you're stuck with: 1. A JavaScript solution that requires getting the container's width, the UL's width, and add something like half the difference as a margin- left or padding-left to the UL; 2. A CSS solution that relies on a display:table element wrapping your UL (or display:table on the UL element itself). Elements that have a table-like display CAN be centered using automatic margins, even if they don't have an explicit width. And the one IE 6-7 compatible way to have a table-like display is to use a TABLE element. So you would need to wrap your UL in tabletrtd.../td/tr/table, then use automatic margins on that table element. Not nice, but it works.
[jQuery] Superfish plugin: some limitations that could be addressed
Hello, This is a message for Joel Birch, author of the Superfish plugin, to developers who may assist him (if any). It may be interesting to people working on similar plugins, dropdown navigation, etc. Superfish is a great plugin (thank you Joel for sharing it). It takes care of a lot of details, like some hard-to-squash IE7 bug, nice accessibility and usability enhancements, etc. While working on a project recently i encountered two issues with this plugin. Those issues are: 1. Superfish expects submenus to be UL elements and 2. the method of hiding submenus may not be accessible to some users (specifically users of text-to-speech technology). #1 SUPERFISH EXPECTS SUBMENUS TO BE UL ELEMENTS In the non-minified source of Superfish 1.4.8, this is on lines 104-105 and 112-113: var $ul = $(['li.',o.hoverClass].join(''),this).add(this).not (not).removeClass(o.hoverClass) .find('ul').hide().css('visibility','hidden'); $ul = this.addClass(o.hoverClass) .find('ul:hidden').css('visibility','visible'); I had trouble understanding all (if not most) of the Superfish code. But it looks like Superfish is looking of UL elements that are direct children of a given element [find('ul') and find('ul:hidden')]. If you happen to use a different element, say a DIV, the plugin works to some extent but the hiding/revealing of submenus is not managed by Superfish anymore, and the animation effects are not applied. Because Superfish won't find the UL it expects and thus won't be able to apply styles to it. I think it might be interesting, say in a future Superfish 1.5, to allow DIV elements as well, or maybe an arbitrary selector. The 'ul' selector could be a default parameter, and could be overridden with 'div', '.someclass', etc. I'm not sure if the requirement for the child selector is absolute, or is just a safety thing to avoid selecting nested elements in three+-level menus. Why would one want to use something other (whatever it is) than a UL? Well, it might be very useful to build mega-dropdowns (see http://www.useit.com/alertbox/mega-dropdown-menus.html), which is what i had to do (though my own mega dropdown was quite simple: a DIV with one paragraph and a short list of links). It might be useful too when you need an additional DIV around a UL because you need more markup to do some CSS embelishment (borders, shadows as images, decorated boxes, etc.). #2 HIDING SUBMENUS WITH DISPLAY AND VISIBILITY It's a well-known fact that a consequence of using display:none or (to some extent) visibility:hidden to hide an element is that this element won't be rendered by most screen readers (JAWS, Window-Eyes, etc.). Looking at the Superfish default CSS code, it looks like this was considered: .sf-menu ul { position: absolute; top: -999em; } .sf-menu li:hover ul, .sf-menu li.sfHover ul { left: 0; } (This is a simplified code extract.) The submenus are hidden by displaying them far on the left of the viewport (note that with most browsers, trying to do the same on the RIGHT of the viewport will create an horizontal scrollbar on the viewport, that enables the user to scroll all the way to where the submenus are positioned). Then when the parent LI is hovered, or gets the default sfHover class, this left offset is removed. This is a nice technique, but the JS code completely breaks it. Once the JS code is executed, the submenus will get this inline styles: element style=display:none; visibility:hidden; And when the parent LI is hovered or tabbed to, you get: element style=display:block; visibility:visible; I'm quite doubtful of the actual results of using a Superfish menu in a screen reader. Remember: screen readers act between the user and the application, meaning that a screen reader user is still using a normal web browser (mostly Internet Explorer, some use Firefox), and most screen reader users don't disable JavaScript (either because they don't know how, or because the websites they use require JavaScript in some ways). Now, please note that i don't know what the best option is. Reproducing the accessible CSS hiding trick in the JS would work. But: 1. The display:none might be necessary for some jQuery methods to work (i suspect animated fade-in effects to require an hidden element to work). Is this the case? Are there workarounds? 2. The current behavior MIGHT be ok in some or even most use cases. I suspect that linear navigation with a screen reader would work well, while other use cases (using the kind of page navigation shortcuts screen readers provide) might fail to reveal the relevant hidden submenus. I guess i should test this once i have some time to re-learn the basics of JAWS testing. (I'm not really fluent with assistive technology.) Finally, i would like to add that if the current JS behavior IS a problem for screen reader users, then the default