[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.
Re: [jQuery] Re: Superfish plugin: some limitations that could be addressed
showed you an example of a multi column div in a sub, had h tags, image, and assorted other markupdid you even look at it? Plugin code was untouched, any adjustemnts were done with css Florent V. wrote: 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
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
superfish shows and hides UL's and doesn't interact with their children like you are saying. The exact same markup in YUI example bellow works perfectly well...no hacks needed Florent V. wrote: 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-label"Submenu 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-label"Category 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-label"Category 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
When it comes to issues like you are presenting I defer to higher powers Example: YUI framework, even in latest 3.0 release. Menu is built with UL/LI with containing DIV structures: http://developer.yahoo.com/yui/3/examples/node-menunav/node-menunav-3_source.html here's a live example on Amazon S3 site: http://aws.amazon.com/s3/ 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 Florent V. wrote: 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 plugin: some limitations that could be addressed
not sure what you mean by "hack" or "abusing the ul/li elements" only interpretation can think of for "abusing" is invalidation, here's an example of large container div inside a sub in superfish. http://tinyurl.com/yzfwmvy here's the 100% validation thru w3c validator http://tinyurl.com/yh9b7qh Florent V. wrote: 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 plugin: some limitations that could be addressed
I don't know a lot about screen reader issues, however there is no
reason not to be able to build a mega menu inside UL/LI structure and
this has been done in superfish.
You can put divs inside an li, with columns , images, H tags, whatever
you want and is all valid. Do whatever css you want inside those
containers.
Florent V. wrote:
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
