Feature Request: "data-*" Attributes Instead of JavaScript

[luxlogica]

Web designers are very different to web developers: they use different tools, have different concerns, and specialise on different areas of knowledge. A good web designer will know (some) html and css, but will usually stay away from JavaScript (because "that's programming").

Semantic is specially attractive to designers, because of it easy and logical syntax, because many of its basic elements already follow many good design principles, and because it seems less opinionated and easier to customise than most other frameworks.

Unfortunately, there is some very neat functionality in Semantic, which requires the user to be familiar with JavaScript. Some of it may be simple - a matter of adding one or two lines in a 'script' element in our page - but others require lengthy incursions into the language (like Form Validation) which can be scary. Others - like Transitions - provide no explanation at all outside of the scope of JavaScript usage, and designers will be unlikely to make any use of it at all.

Other frameworks have managed to successfully abstract the JavaScript layer completely by using "data-*" attributes in the required elements. Any information that would normally be passed on to a JavaScript script, can be set in a 'data-' attribute to an arbitrary element. For instance, a "data-check-empty" attribute could be used to flag that a form-validation check is needed as to whether the element is empty or not, and a "data-check-empty-msg" could be used to set a custom message if the validation fails. Similarly, "data-check-min-length", "data-check-max-length", and even a "data-check-regex" could be used to set multiple checks in a single element.

The idea would be, therefore, that anywhere in the current framework where there is a requirement that the user should use JavaScript in order to turn on, configure or access certain features, those features would be available instead via "data-*" attributes.

This means that a designer could continue to deal only with the html elements that they are familiar with, while getting all the benefits of the JavaScript scripts in the background. This type of approach means that the framework would be attractive and accessible to a much wider range of users.

[jlukic]

Having behavior auto-attach without Javascript requires each component to query the DOM for elements that have the correct data attribute. This means each component in SUI would have a performance overhead just for being included in the page, and pages with no components would still have javascript firing from SUI.

I think behavioral code should be kept out of markup, I know a lot of other frameworks disagree with this point, but this is an ideological issue for my vision of SUI.

Behavior is inherently complex, much more complex than structure. SUI seeks to create guidelines for interfacing with behavioral definitions using english as a layer of abstraction, instead of including data bindings like other libraries.

[brigand]

I think a second build, or an extra file is the way to go with this.

It could be something simple, like this:

var modules = ["dropdown", "accordion"] // etc
modules.forEach(function(module){
var settings = $.fn[module].settings;
$('[data-' + module + ']').each(function(){
var $this = $(this);
var options = {};
Object.keys(settings).forEach(function(setting){
var value = $this.data(module + '-' + setting);
if (value !== undefined) {
try { options[setting] = JSON.parse(value) }
catch (e) { options[setting] = value }
}
});
$thismodule;
});
});

This allows you to do things like this:

...

On Tue, Jul 8, 2014 at 10:03 AM, QWp6t notifications@github.com wrote:

Bootstrap lets you turn off its data-api via $(document).off('.data-api'),
which I think is probably the best of both worlds. People who don't mind
the overhead can leave it on, and people who are more conscious of the
overhead can opt out.

—
Reply to this email directly or view it on GitHub
#931 (comment)
.

[ghost]

+1 for adding data attributes support.

[luxlogica]

@jlukic I agree with the principle of keeping Semantic simple and focused on having strict rules for maintaining an English-like and easy-to-use syntax. This is precisely what makes Semantic so compelling.

The distinction between 'behavioural code' and 'markup code' is not always so clear, however. If in order to have a certain element in my view display the way I want - such as a popup that displays html code, or a customised dropdown menu, or an offscreen sidebar - I must use javascript, then for the sake of simplicity and ease-of-use it may be better to build that functionality (=behaviour) into a format that is accessible for the designer (not just for the developer).

Also, the separation of 'behaviour' and 'display' inside the context of a web page may be obvious to us - ie., if I want a picture to 'shake' with a tada effect on mouseover, that can certainly be considered "behaviour". But we should remember, that our web page is being developed as part of a 'bigger context' where it is, itself, just part of a bigger system. In the bigger context, the whole of the web page is usually just really the "V" in an "MVC" system, and almost everything we are doing in it is just "display" (i.e., view) code... In this wider context, if my page is interacting with a backend database, and my form has to save data to it, then I may use a controller object - either programmed in javascript on the frontend, or in a server-side language on the server - and that is behaviour (ie., control code). If a field in my form has to turn red to warn the user of error in data entry, that is a "display" concern (i.e., view code, which has nothing to do with my controllers). From this perspective, if I want a graphic on the page to "shake" with a tada effect on mouseover, that is something that should be able to be specified entirely in the view itself, that is, in the image itself - and not have to rely on an outside controller code. In this scenario - which is common - being able to specify the shake effect with a simple data attribute on the image itself would not only help keep separation of concerns in my web app, it would actually simplify my view syntax and maintainability.

Indeed, if adherence to a strict, simplified syntax - and ease-of-use - is the main concern, by forcing a designer to write several lines of javascript, when perhaps a single data attribute would do, we may be actually forcing a much more difficult and complex usage.

Whether adding data attributes would impact on performance, I honestly do not know. Again, I believe that this will boil down to an issue of priority: is the aim of Semantic to be primarily a "fast" framework, or a simple one? Personally, having used a couple of the competing frameworks that do use the data-attribute approach, I can say that "performance" is not an issue, at all, as far as the end-user is concerned - even if the framework -is- slower for using data-attributes, it is certainly not perceptible.

Semantic is a wonderful framework, and this suggestion is made in the spirit of trying to enhance it even further. It is, however, merely this: a suggestion. Whatever the developers decide is, of course, the right choice for the framework. Projects like Semantic are extremely valuable and the developers that power it and keep it going must feel comfortable and happy with the code they are writing.

Once again, thank you for your consideration, and for all your hard work. It's truly appreciated.

[knudpotente]

+1 for data attributes - they're the reason we end up using Bootstrap. Please, don't decline.

[lrlopez]

I really like @brigand approach. Just include that snippet into a separate .js file and reference it if you need data-* attributes support. This way we address @jlukic's concerns, as no Javascript firing from SUI would take place by default. Everyone is happy! 👍

Frankie, could you prepare a PR if Jack agrees?

[jblac]

new comment on a super old thread, go me! It's a shame this was declined, as a rails developer, I define my fields like:

<%= f.input :password, required: true, input_html: { maxlength: 20 } %>

and of course, i can expand or simplify my requirements however i want there. This outputs the following HTML for the field:

<input maxlength="20" class="password required" required="required" aria-required="true" size="20" type="password" name="species[password]" id="species_password"">

Bootstrap reads the attributes out of the box, if i want to use semantic (which from a UI standpoint I like better) I have to re-define everything I've already defined and I have to do it for all 400 forms in my application? Seems like unnecessary cost to the semantic users to me. This is the only reason why I can't take semantic seriously atm.

[ElEmFurt]

I was able to achieve attribute based validation rather easily using a data attribute and a single function (incase anyone is still in need of this). My controls have a data-validate attribute with the id in it for the value, so that I can then find all controls with this data-validate attribute and then add them as rules. In my case I just needed an empty validation on it, if other validations are needed, they can also be added as data attributes and then used inside the function below for adding them dynamically.

The advantage of this is that I can call this function after I add dynamic controls as well, and it works just fine.

function SetValidations()
{
$('.ui.form').form({
inline: true,
on: 'submit',
transition: 'fade',
});
//Add validations dynamically
$("[data-validate]").each(function () {
var validateId = $(this).attr('data-validate');
$('.ui.form').form('add rule', validateId, ['empty']);
});
}

Also as mentioned above, a developer can create a system of attributes to be used, in a similar manner and the web designer can then easily refer the list of attributes to enable the features needed. I function as both for my applications, so it's rather easy for me to take a decision on what the HTML markup will contain vs. the javascript.

Hope this helps anyone looking for a similar fix.