What is the impact of changing the default behavior of an HTML element?

Question

Recently there was a question here on Stack Overflow about changing the default behavior of checkbox to act on the page as a radio, that is, when selecting an item, the others should be unchecked, keeping the selection unique. The answers were given using Javascript basically changing the natural behavior of checkbox treating the events in this element. I always believed that doing so was not recommended and that the ideal would be to use the element itself radio for semantic reasons. I came to comment on the possible solution using the property appearance CSS, because it keeps the code semantics, changing only the appearance of the element, without requiring Javascript:

input[type=radio] {
  appearance: checkbox;
  -moz-appearance: checkbox;
  -webkit-appearance: checkbox;
}

<input name="foo" type="radio" value="1" checked> 1
<input name="foo" type="radio" value="2"> 2
<input name="foo" type="radio" value="3"> 3

However, searching, I saw that such a property was removed from CSS 3, so even though browsers still support such a property, I believe its use should be avoided and that the Javascript approach is commonly discussed in forums, but there are few places that discuss whether it is in fact appropriate to do so.

The conclusion I come to is that one should not change the behavior of one element while semantically it is appropriate to use another, but I cannot canonically state what is the impact of both performance, if any, as in the usability of the page.

So:

• It is allowed to use Javascript to change the natural behavior of an element to act as another?
• What is the impact of this approach? Is there a performance difference in page rendering? And how can this affect usability?
• If usability is directly affected, it is possible to correct using the attribute role="checkbox"?

Note: the example given between checkbox and radio was more for contextualization of the problem and the answers can preferably address other examples if necessary.

Answer 1

Let’s go in pieces:

It is allowed to use Javascript to change the natural behavior of an element to act as another?

Yes. Javascript was created to give intelligence to the components of the pages. In a way, the imagination (and browser security checks) is the limit of what you can do.

You can make a button behave like a text box, or a list li behave like a paragraph. Note that, as well as the things that people do in that TV show Jackass, just because you can not mean you should.

What is the impact of this approach? Is there a performance difference in page rendering? And how can this affect usability?

That is point X of your question. There is, yes, a difference. Let’s take the case of radio versus checkbox as an example. There is time for the browser to load these components. After this time, they will be loaded with their default behavior. In general this load time is very short, because browsers are implemented by the best multidisciplinary teams in the world and one of the things that these teams preach and apply is that everything should be as simple as possible.

When you add unnecessary complexity to a component, you add the running time of your Javascript to the loading time of the component. Soon, his checkbox Frankenstein never charge in time less or equal to the charging time of a checkbox healthy. You need time to castrate the checkbox, and after time to train him to behave like a radiobutton.

This makes the page slower, but whether this is noticeable to the user depends on the skill of who will do the hacking and the amount of elements that will be modified.

Note that it is not only performance that is impacted. You now have code to maintain, and code - especially HTML, Javascript and CSS - deteriorates over time. Somebody’s gonna have to keep it up some day, and even if it’s the original author, it’s normal for that kind of work to work like a snowball. Soon, code branches developed specifically for different versions of different browsers appear. Integration with new plugins becomes increasingly difficult too.

If usability is directly affected, it is possible to correct using the role="checkbox attribute"?

It’s not guaranteed. It’s kind of like pushing dirt under the rug. The best correction is to start from scratch and follow good development patterns. After all, they were created for a reason.

---

There is another factor that should be considered, besides the performance. You can spend development days to ensure that changing components does not slow down your page or increase your run time too much. But remember that today everyone navigates through dozens, and some users hundreds of sites that follow good design standards.

This means that users are trained to treat check box as check box and radio button as radio button. If in the end your page is very fast but users get confused, all your development effort was in vain.

Answer 2

1)It is allowed to use Javascript to change the natural behavior of an element to act as another?

Javascript is a language that makes the sites become interactive and according to the page Javascript observed the language rules anything is possible.

2)What is the impact of this approach? Is there a performance difference in page rendering? And how can this affect usability?

I)impact:

1. code level: Code generation to be maintained.
2. code comprehension: Low understanding required documentation auxiliary to code maintenance.
3. code maintenance: When working in a multi-distributed company you can not have guarantee who will maintain the software in 6 months or 1 year, knowing that your code possibly will not be cleaned because there is no clear order of why there was this decision, since it is a bad decision.

II) page rendering impact:

1. minimum due to bringing only additional javascript code and loading it, it almost always takes milliseconds.

III)And how this can affect usability?*

According to the Nielsen Group, this issue has already been addressed. checkboxes-vs-radio-Uttons by Nielsen Norman Group

On the site they even comment that they have different functions.
According to html readers for blind as the Dox Vox which interprets HTML entities for blind and visually impaired to a wrong choice causing the user to make the wrong decision as a checkbox should accept more than one option while the radio button accepts only one.

Making a site according to the standard UX and not the internal standards of an organization or team results in a better accepted site for a larger amount of users as the study: Interface Standards Stifle Design Creativity?

According to the Caelum and your UX analysis can be noted as Nielsen’s 10 heuristics as a basic guide to all UX that is to say if you run too far from reality your system is doomed to disaster.
Is it possible to prevent all interface errors by JS ? No! depends on the browser your user is using if it is an html interpreter like the one above,Dox Vox, your code will essentially break for these people so if you change the default behavior and this is the only possible solution that then found something wrong in the way you are following your logical reasoning.

Answer 3

It is allowed to use Javascript to change the natural behavior of an element to act as another?

Yes, from the moment we have to stop the spread and cancel a particular event (if it is cancellable, without stopping the spread of the same )

event.stopPropagation();

event.preventDefault();

We give the power to modify what that element will do, I can say that an input type text will behave like a button that when receiving a click event for example cancel your Focus event and trigger a click.

---

What is the impact of this approach? Is there a performance difference in page rendering? And how can this affect usability?

This can affect in many ways depending on your code, browser, internet connection...

You can avoid using external files. js otherwise you depend on your internet connection for your script to work and "modify the element"

The difference in performance will not be remarkable however it exists, if you do not prevent the flow of the element your browser will already know how to treat the same, the moment you start to prevent native functions, stop events, modify events, all this will have a cost for your application, stopping to analyze better think this way, you have a check that when you receive a click it will mark itself and uncheck another element soon you will make an extra change in your GIFT and this will yes take its cost.

Depending on your script it will disturb the loading of the page yes, so 'modify impacts the loading of the page.'

A basic example to demonstrate what might happen if your script is late and someone clicks your check. :

setTimeout(function(){
  jQuery('input').click(function(){
    return false;
  });
},3000)

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<input type="checkbox">

In the example above you can click the checkbox up to 3 seconds after the javascript code, after that I return false in the click event thus disabling your event mark or not checkbox, This is an example that can happen if your script takes too long to load and someone clicks on your checkbox that should work as a radio button.

---

If usability is directly affected, it is possible to correct using the role="checkbox attribute"?

This attribute serves to give more semantics to the elements of documents based on marking, I do not think it would be correct to use it in the case