Behaviour of value attribute

[raxell]

The value attribute has an ad hoc expression since it is not recomended to set it with setAttribute.
But the behaviour of value is different from that of normal attributes, when passing a falsy expression the attribute is not removed. This can be a problem when using it on non-form elements (example).

Is this the expected behaviour?

There are conflicting informations about falsy values, here it is said that falsy values do not remove attributes, but the tests checks for the opposite:
https://github.com/riot/dom-bindings/blob/9697d1fb7429c3a0b494c0ee6b472b470a054434/test/expressions/attribute.spec.js#L33-L45

[GianlucaGuarini]

@raxell riot/riot#1453 is an issue referring to an old Riot.js version 2015. This repository is brand new created explicitly for Riot.js 4. Unit test behave consistently with the new documentation.

Regarding the value attributes on non form attribute we could probably handle them differently here but it would mean also adding more magic to the source code generating probably more problems than the ones we are supposed to solve

[raxell]

@raxell riot/riot#1453 is an issue referring to an old Riot.js version 2015. This repository is brand new created explicitly for Riot.js 4. Unit test behave consistently with the new documentation.

Oh you're right, I thought the latest comments of april was about v4.

So value is never added to dom for input elements, it is just setted with el.value = . But it is a valid attribute for other standard html elements, so I think is mandatory to handle it. If can be classified as bug I can create an issue in https://github.com/riot/riot
If it's ok for you I'll try to address it in the next days, I still have to see how the compiler work

[GianlucaGuarini]

I will migrate this issue to the compiler. We would need to patch the dom-nodes first to list all the input nodes.

[raxell]

More than the inputs elements the ones that must use the value expression binding are those that have defaultValue in their DOM interface. According to the spec those are input, textarea and output.
So any element other than those 3 can use normal attribute expression, do you agree with that?

[raxell]

The patch seems wrong to me, the problem with <progress> remains

[GianlucaGuarini]

could you please make a PR on the dom-nodes repo? I have now prepared the hooks in the compiler.

[GianlucaGuarini]

@raxell I have updated the list again. Could you please have a look at it?

[raxell]

The list can be found here, textarea and output does not have value.
But having the attr value does not mean that value expression should be used. I'll send a PR in a few mins so you can see what I mean

[GianlucaGuarini]

Droppint the support of the value directive on textarea tags is considered a breaking change. It ain't gonna happen

[GianlucaGuarini]

List of the additional elements having the value attribute by specs:

• textarea: https://www.w3.org/TR/2010/WD-html5-20101019/the-button-element.html#the-textarea-element
• select: https://www.w3.org/TR/2010/WD-html5-20101019/the-button-element.html#the-select-element

I honestly I don't get either what's the problem with the <progress> tag since it works out of the box.

I think I am going to list all of them and close this issue that for me is only related to html tags that don't allow the use of the value attribute

[raxell]

Just a sec, if you continue to make changes I'll never end to rebase ahahah
This issue is a matter of using node.value only for elements like input and textarea, for progress can be used node.setAttribute('value', 'x') since it does not have defaultValue

[GianlucaGuarini]

the point is: why should I handle differently DOM elements that allow the use of the value property?

[raxell]

Cause having the attribute and setting the value with .value are two different things. Why the value expression has been made? To handle setting the value property on inputs/textareas I suppose, since setAttribute overrides defaultValue. But for elements other than those two can be used setAttribute as with any other attribute (e.g classes)

[raxell]

The thing is

<progress max="10" value="{progressValue}"></progress>

Here if the value is binded using a value expression the removal of the attribute can only be made by manipulaiting the dom by hand. If it would be binded using a normal attribute expression passing a falsy value would remove the value attr making progress indeterminate (loading animation).

Example

[GianlucaGuarini]

thank you for your example. I still don't understand which kind of problem we are trying to solve.
A progress tag has always a value otherwise it does not make sense to use it and it can be removed with an if directive. There is no benefit of adding the value attribute to the DOM node.

[raxell]

A progress tag has always a value

No, "If there is no value attribute, the progress bar is indeterminate; this indicates that an activity is ongoing with no indication of how long it is expected to take". If you look at the example, the first progress bar starts with an indeterminate state (like "still don't know how much time it will take"), while the second is just initialized at 0%, those are two different things.

value attributes are just normal attributes that can be set using setAttribute as any other. The only two exceptions are input and textarea that need to use .value. NB: textarea does not have a value attribute, it has a value property, doing (just HTML):

<textarea value="example text"></textarea>

Doesn't make sense, will not set any text in the textarea.
Setting textarea.value from js will not set anything in the DOM (from the inspector console you will not see any value attribute added), same for input. Instead, setting progress.value from js will change the attribute in the DOM (from the inspector console you will see that value will be added/changed), so this is equivalent to using setAttribute.

To me the problem seems clear, I don't know if I'm wrong with something, is there anyone else that can review this and say if it make sense?
Anyway the final decision is up to you, all started from this stackoverflow question.

[raxell]

Sidenote: it's not necessary to remove value to have progress in an indeterminate state, having <progress value=""> is the same. But when using progress.value = '' the browser cast the empty string to 0 since it want a double