Develop Reference

Selector for styling in jquery plugin to a void conflicts

I am new to jQuery. I recently develop a plugin bu using jQuery UI widget factory. It is working fine. I was using inline styling. But It will get complex for large files.
For the large project I have the option to use classes. But when if someone wants to use my plugin he'll simply copy the link and use it. But If he has same name of classes on his page then its page will be destroys because my of my styles. Can anyone please guide me how to avoid this.
I hope you get the point.
Thanks

Some things to consider:
If you make a selector that is too specific, like
$("ul > li > .foo ~ .bar");
it may break by any changes on the markup.
However, if you don't, it will break your user's style.
As commented, the easier way to fix this would be adding an prefix on the class, like
<div class="my-plugin-container">
<span class="my-plugin-span"> "Hello World" </span>
(OR) <button class="my-plugin button"> </button>
</div>
If you could post any code we could be able to help you further. I'll edit it according when you do.
Best of luck

Are dynamically generated aria-describedby values still accessible?

I'm running an automated accessibility test on my site and getting an error for a tooltip element which uses Zurb Foundation's tooltip (v6.2.3).
The issue is noted as "This element has an aria-describedby attribute value that includes one or more invalid ids." As far as I can tell, the div that it's described by does have a valid id, but since it's generated by JavaScript, perhaps that's causing the issue?
Here's what the code looks like in my editor:
<span data-tooltip aria-haspopup="true" class="has-tip" title="I'm on bottom and the default position.">"tip-bottom"</span><br>
And on render, Foundation's JavaScript changes it to:
<span data-tooltip="77rhf0-tooltip" aria-haspopup="true" class="has-tip" title="" aria-describedby="vd07t8-tooltip" data-yeti-box="vd07t8-tooltip" data-toggle="vd07t8-tooltip" data-resize="vd07t8-tooltip">"tip-bottom"</span>
Foundation's JavaScript also generates at the bottom of the document:
<div class="tooltip" role="tooltip" aria-hidden="true" data-is-active="false" data-is-focus="false" id="vd07t8-tooltip" style="display: none; top: 421.812px; left: 410.766px; opacity: 1;">I'm on bottom and the default position.</div>
Where the ID of the tooltip is randomly generated.
From zurb's JS Tooltip, where it's using a plugin to create the ID name:
var elemId = this.$element.attr('aria-describedby') || Foundation.GetYoDigits(6, 'tooltip');
As far as I can tell, it is a valid ID and should be working correctly. I assume if my testing tool has trouble picking up the ID, assistive technology would also run into an issue.
My question is: would this OK to leave as is, or is there genuinely an error here that would cause an issue with assistive technology?
I am fairly new to using ARIA attributes, so apologies if this question is confusing or poorly worded. Thank you!

My question is: would this OK to leave as is, or is there genuinely an error here that would cause an issue with assistive technology?
Your aria-describedby is added with javascript, and so is the div. Screenreaders read the generated DOM. So everything is ok.
It would have helped if you had indicated which tool you use because, the error might be that this tool is not capable to retrieve the div due to its hidden state, but this is not a problem from a screenreader point of view. Note that having aria-hidden=true does not make any difference.

Should a JQuery plugin be responsible for creating new HTML?

I am not quite sure what the best (or most common practice) is when needing HTML elements for your JQuery plugin to work. For example (although contrived), if you required a spinner (ticker) plugin where you would have text box containing a number and to the left of the box a up and down arrow. When the up arrow is clicked the value is incremented and the value is decremented when the down arrow is clicked.
I see some JQuery plugins, especially the JQuery UI widgets, that expect you to supply all the html and to give them special classes.
In the case of the spinner would you just expect the input tag and then in the JQuery plugin generate the HTML to render the up and down buttons?
Perhaps a better example is something like creating a paging data grid. Would the paging buttons (First, Last, Previous, Next, Page 1, Page 2...) be generated by the plugin or should the user of the plugin be expected to create HTML with special classes.

You should look into jqGrid. It generates a lot of HTML, but it leaves the <table> and pager elements up to you. It then obviously appends to these elements. But it also creates siblings and containers for these elements as well.
For example,
<!-- index.html -->
<table id="mygrid"></table>
<div id="pager"></div>
// main.js
$('#mygrid').jqGrid({pager: '#pager', ...});
jqGrid not only appends to #mygrid and #pager, but also creates new siblings and containers.
<div id="gbox_mygrid">
<div class="ui-jqgrid-view">
<table id="mygrid"><!-- rows --></table>
</div>
<div id="#pager"><!-- stuff --> <?div>
</div>
So you see that jqGrid does what it has to do, to work well. I think it depends on the needs of the plugin.

Generally, I would expect the developer to supply only the container element along with any essential inner elements (think images in a slider). I would expect the plugin to generate any controls like buttons, pagination, etc.
Requiring the developer to supply a container element gives them complete control over how, when, and where your plugin appears on their page, as if it was just another div. Requiring them to also supply any necessary content isn't always necessary, as this could just as easily be a config item.
The main upside I see to having the user supply HTML comes when dealing with clients that don't support/allow JavaScript (think old browsers, spiders, etc). At least they'll see something related to what your plugin was meant to display, rather than just an ugly blank space. In the slider example, if done properly, the plugin can gracefully degrade to a static image in the case of lacking JavaScript support.
All intricacies such as controls and status displays should always be generated by the plugin. Why? User-friendliness is the first thing that comes to mind. People use jQuery plugins because they want a fast, relatively pain-free solution to a problem. Additionally, many users of jQuery plugins are not web developers, but instead are often just administrators of blogs and such.
By eliminating the need for the users of your plugin to have to create elements that they really have no control over, you also eliminate a lot of headaches caused by typos, misunderstandings, and lack of RTFMing.
Hopefully my opinions and insights have been helpful.

Why do I have to call $(":button").button(); to enable JQuery UI Theme?

I am still new to JQuery and JQuery UI Theme. I have managed to develop my own theme, and to apply it on a simple test page with buttons. I read the documentation, and I could not find where it says that I should explicitly call $(":button").button(); to apply it.
If I don't do this, the theme is not applied. So why do I have to do this explicitly? Or if this is expected from me, does anyone have a generic script to apply the theme automatically on all items? Thanks.
EDIT
Reading answers and comments, some people imply that application of UI Theme is automatic, but others say it should be applied manually. A test on the delivered test HTML page seem to indicate that theme must be applied manually.

If you look at the demos, the button styles can be applied to other elements as well, such as checkboxes, radio buttons and anchors. jQuery UI thinks it is better to let you specify which elements should have that particular style applied than to try to guess, especially since specifying the elements is typically a one-liner: $(foo).button();

The reason you have to call the button function, is so that jQuery UI can add all of its specialized classes and attributes to the button.
If you start off with a button like this:
<button type="button">A button element</button>
It will be replaced with this:
<button class="ui-button ui-widget ui-state-default ui-corner-all ui-button-text-only" role="button" aria-disabled="false"><span class="ui-button-text">A button element</span></button>

The reason you have to specify this explicitly is because not everyone using the library might want to style all their buttons as jQuery UI buttons. It's generally considered desirable to separate "mechanism" (which jQuery UI provides), from "policy" (which you get to decide); and jQuery is excellent at letting you define policy in a concise way anyway.

Unobtrusive Knockout Template Question

I've been experimenting with an unobtrusive Knockout data-binding jQuery plugin. Follow the link here.
I cannot seem to figure out how to keep the "data-bind" attribute out of a template, though. I can't decide whether or not it should even be done, either. I just have a hunch.
Example template:
<script id="storeTemplate" type="text/x-jquery-tmpl">
<li>
<div class="storeTitle" data-bind="click: select">${storeTitle}</div>
</li>
</script>
I'm thinking that it might be a good idea to pull data-bind="click: select" out of there. Does anyone have an idea as to how to do that? I've tried $(".storeTitle").dataBind( { click: "select" } ); A jQuery selector only selects objects that have already been created in the DOM, yet the elements we want to edit are not part of the DOM yet. Also, I would like to avoid applying bindings more than once.

It seems I just sort of answered my own question. Considering that the elements in the template are actually sitting in the DOM (just in string form) I could just modify the string and add the data-bind="click: select". Rather than doing string manipulation, a coworker suggested I just temporarily insert the template text as innerHTML to add it to the DOM, modify it using the plugin, insert the modified version back into the template as text and apply bindings.