Foundation 7: JavaScript plugin initialization

[abdullahsalem]

@zurb/yetinauts Could you please review this proposal.

[rafibomb]

I like the direction - the JS should be easy enough to mix with other JS plugins without conflict. Would a global option to prefix the data-attributes be the best option?

[Owlbertz]

I do think so, @rafibomb. While zfwould sure be future proof, as there is just a very little chance any other framework takes the same prefix, having it configurable would make totally sense. Of course having no prefix at all should be an option as well.

[andycochran]

Maybe the default is no prefix, and you can configure one in your app if you need to. Wouldn't that help with backwards compatibility?

[andycochran]

(Ack! Sorry. Butterfingers closed the issue.)

[abdullahsalem]

Thanks a lot for your participating guys.
I like your thoughts guys, yes I strongly agree that, it would be much better if they both are optional: the existing of the prefix, and its name. And the prefix name would be a good if it's zf by default.
However, I think that will lead us to another question: Where should that configurations be? So far, there is no any global Foundation JavaScript APIs; What do you think if we have something like Foundation.defaults in the global namespace?

Note: In this case, I think we should not wait for v7, because that will be compatible with the current major version, anyway!

[Owlbertz]

Having a configuration file for those that build their custom Foundation with Gulp, etc. would be a good approach imo. I guess these configs could also be used/set in the $(document).foundation(); call on the fly by passing something like

$(document).foundation({
  namespace: 'zf'
});

[abdullahsalem]

Note: In this case, I think we should not wait for v7, because that will be compatible with the current major version, anyway!

I only meant adding the prefix and its name, but the full solution that I mentioned in the proposal could be fully implemented in v7.

Here is the full solution:

• Adding a namespace to the data attribute of the plugin name and the plugin’s options, so the data attributes should look like: data-zf-plugin-name and data-zf-options.
• Removing the previous data individual options, and keep all the passed options in data-zf-options.

[ncoden]

Wether in Sass, JS, HTML (ect...), everywhere we work on the global namespace, we can't declare names without prefixs. The probability of naming collisions are too high, and they are often incorrigible for the user.

So YES, we should use a Foundation namespace, thank you !

About data- attributes :

JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used. Authors of libraries that are reused by many authors are encouraged to include their name in the attribute names, to reduce the risk of clashes. Where it makes sense, library authors are also encouraged to make the exact name used in the attribute names customizable, so that libraries whose authors unknowingly picked the same name can be used on the same page, and so that multiple versions of a particular library can be used on the same page even when those versions are not mutually compatible. -- W3C

However, I think zf is rare enough for we use it as prefix without risk of a naming collision.

[ncoden]

Would it makes difficult the change of an option through HTML ? If yes, we have to ensure that all options can be modified through Foundation. in Js.

[ncoden]

About the customizable namespace, I propose :

• Implement the namespace support for v6.*, with no namespace by default for backwards compatibility. I also propose we add it in a config file, with zf- prefix advised in commentary.
• Use the zf- prefix as default in v7