Mavo should treat elements with `readonly` or `disabled` attributes as read-write

[LeaVerou]

Currently when using a form element with a readonly attribute (pen):

• Because it's a form element, it does not contribute to needsEdit, i.e. no editing UI shows up unless it's triggered by other properties
• Even on edit mode, the disabled or readonly attributes are not removed.

It may be a good idea to treat these as read-mode views, and remove the readonly/disabled attributes on edit mode. This would also offer an extension point for web components, which will be able to define read and write modes with no reference to Mavo, by simply supporting a readonly attribute.

One caveat is that often disabled is used conditionally, so we'd need to match on [disabled=""], not just [disabled]. Probably a good idea to do the same with readonly.

Thoughts, @karger @DmitrySharabin ?

[karger]

If the author has explicitly placed a readonly/disabled attribute, I would think it odd for mavo to override/remove it in edit mode. Because why would they have explicitly said readonly/disabled if they wanted it editable sometimes? They could have just said mv-mode="read".

I could argue for going the other way: if you have an element with mv-mode=read, then any form elements inside it should get the readonly attribute set on them to match the author's specification.

I also noticed this here:

The difference between disabled and readonly is that read-only controls can still function and are still focusable, whereas disabled controls can not receive focus and are not submitted with the form and generally do not function as controls until they are enabled.

Should that mean that if a property is disabled then it's value you should not be saved/modified even if changed? (This would not be the care for readonly, which explicitly allows for the case of scripts modifying the value).

Strangely, the same spec says

The attribute is not supported or relevant to select or input types that are already not mutable, such as checkbox and radio or cannot, by definition, start with a value, such as the file input type. range and color, as both have default values. It is also not supported on hidden as it can not be expected that a user to fill out a form that is hidden. Nor is it supported on any of the button types, including image.

which is strange to me because it seems perfectly reasonable to say I have this select/radio/checkbox showing a setting but I don't want to let the user change it.

[LeaVerou]

If the author has explicitly placed a readonly/disabled attribute, I would think it odd for mavo to override/remove it in edit mode.

Mavo does all sorts of things to try and generate an edit mode from what you give it, and that's what you find odd?

which is strange to me because it seems perfectly reasonable to say I have this select/radio/checkbox showing a setting but I don't want to let the user change it.

Yeah, I also thought that was weird

[karger]

Mavo does arbitrary things but I can't think of cases where it's does the exact opposite of what the author specified

[joyously]

Aren't there two states? One where the visitor is using the app, where the disabled or read-only content is informational, and one where the author is editing the app, where they want to change the content that is disabled or read-only.

Or perhaps you are talking about the ability for the logged in author to add or remove the disabled or read-only attributes? Does Mavo have to consider the state at load time as the confines of the app? The editing of the inception of the app happens somewhere else, that Mavo is unaware of.

[LeaVerou]

Aren't there two states? One where the visitor is using the app, where the disabled or read-only content is informational, and one where the author is editing the app, where they want to change the content that is disabled or read-only.

Exactly.

If Mavo can't remove the readonly attribute, it's unclear how to handle editing for e.g. <input property="foo" readonly>

[karger]

If there is a property that should sometimes be in read mode and sometimes in edit mode, then mavo should add the read-only attribute when it decides to enforce the read mode, and remove it when it wants edits.

[LeaVerou]

Agreed. But what if the attribute already exists in the template?

[karger]

if the author put it there then I think it should be authoritative? ie not overridden by edit mode....

[LeaVerou]

Then how do we generate an edit mode??

[karger]

Not sure i'm understanding the conversation. My point was that having readonly there, unqualified, should prevent generating an edit mode. If the author wants an edit mode they could leave off readonly. or make readonly=[mavo-expr]