Allow configuration options to be passed in attribute data

[jamietre]

Specification for describing options in 1.3

Allow passing any options as an attribute on the image:

data-mapster='{"json": data}'

Allow area-specific options on area tags using same convention
Options can be specificed either as JSON data, or using the attribute name

data-mapster='{"strokeWidth": 2}'
data-mapster-strokeWidth="2"

While not especially byte-efficient, should greatly simplify config, especially for users with limited javascript knowledge.

[NKarasek]

An advantage of stating area-specific attributes is, of course, customizing the rendering of specific areas. Interesting effects for circles, for example, can be developed using a combination of narrow dashed lines (global) and a wider-than-normal stroke (area-specific) - a pincushion effect - variable from area to area. See image below.

With just a few lines of added code to the jQuery.imageMapster.js file, area-specific attributes can be added overiding the global values set in the config options (strokeWidth, ...)

Contact me or comment in this forum if you would like more info.

[techfg]

Been thinking about this one....a brain dump for now:

1. Agreed that IM should provide a 'streamlined' option for configuration
2. Currently, IM doesn't explicitly define when attribute values from AREA element will be used (e.g. href/target) as a primary value falling back to AreaData as secondary and when AREA element will be ignored completely and only rely on AreaData (which is the 1st AREA element for a given primaryKey typically). Need to:

• Standardize behavior of use of AREA element and fallback to AreaData across all config properties, not just random ones
• Document behavior so its well understood

3. My initial thinking was to use the "json in data attribute" approach but the more I've thought through it, this becomes rather cumbersome and very error prone. JSON in a data attribute MUST adhere 100% to the expected format (e.g. keys double quoted, etc.) and for identifying things like functions, etc. it's even more cumbersome. Having separate data attribute instead of a single attribute with json embedded likely makes more sense and also will provide better clarity regarding which options can be specified on an AREA element directly and which can't.
4. If data attributes are leveraged, they should be namespaced (e.g. data-mapster-configoption) to minimize risk of collisions with other libraries
5. Possibly we don't even leverage data attributes and rely solely on options passed via JS - there's value and ease with data attributes but for anything non-scalar, it's error prone. Additionally, it has negative performance impact since there's another location to check for config option.

Again, just thinking out loud, feedback encouraged.