Hello Dale,

You can Follow the implementation of this capability here: https://feedback.telerik.com/blazor/1483630-allow-selecting-and-copying-text-from-inputs-with-enabled-false. The page also contains a workaround you can try. I believe you have found it already as I see your Vote there, which raises its priority for us.

Regards,
Marin Bratanov
Progress Telerik

Hi Seth,

The ability to copy from disabled inputs will be implemented through this item: https://feedback.telerik.com/blazor/1483630-allow-selecting-and-copying-text-from-inputs-with-enabled-false. Whether it will be a new setting, whether it will not require any configuration at all and will just "work", or it will come, after all, through a ReadOnly parameter will be decided when the appropriate research has been implemented. I have also added your Vote to it on your behalf which raises its priority.

As for reasons why a readonly HTML attribute makes no sense for Blazor - you can see what it does here: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly. Here are the behaviors that make it unsuitable for Blazor:

• For one, it is not supported for checkboxes, radio buttons and select type elements which will create a disparity in a component suite (today's apps use at least 3 or 4 different type of selects so effectively half the editors won't have such a feature).
• Secondly, its default UX is sub-par - there is no difference between a readonly input and a writable input, which is a disservice to the end user and makes them feel like the app is broken.
• Thirdly, it is supposed to stop validation - this is not possible in Blazor because the framework validation works with the model field, not with the DOM element. You cannot have conditional rules there, unless you write complex custom validation attributes that take into account extra fields in the model that describe the readonly state. You can see how this can become a serious mess quickly.

Generally, a Blazor app would have its backend decoupled from the component, and if fields need to be shown to the user but not edited, there are two approaches (that can even be combined):

• render different UI for such fields - for example, render them as text instead of as inputs based on the same flag that you would otherwise use to set readonly. A plain if-block can let you render different UI in Blazor, which can be a single line of code.
  • Using disabled inputs is a valid way to let your users know they can't edit this input for some reason. A readonly field is confusing because it looks like it is ediable but it is not.
• avoid updating such fields in the backend - they would otherwise be part of a POST query anyway, and such queries can be forged, so a backend cannot trust user input anyway. Therefore, the backend must know about such fields and prevent them from being updated with its own safety logic.
  • a Blazor form does not submit on its own to an endpoint. It provides a pair of C# events that provide you with the model. Then, it is up to the application logic to use that data and perform the HTTP request. This means that the application can perform necessary checks, add metadata to the model or otherwise alter it before it makes a POST, based on the same flags that you would otherwise use for the UI. If you do want to make a POST, you have full control over what data you send (including metadata if you so wish), and you could have used any of the approaches above to show that to the user.

With all that said, there is one single benefit from having a readonly attribute - the ability to select and copy the contents. This can be achieved by rendering text instead of input with a simple if-block at the moment. The item linked at the top will allow it for Disabled inputs in the Telerik suite.

Regards,
Marin Bratanov
Progress Telerik

Hello Ian,

You can Follow the ability to copy from disabled inputs here: https://feedback.telerik.com/blazor/1483630-allow-selecting-and-copying-text-from-inputs-with-enabled-false. I've added your Vote to it to raise its priority.

Azure's settings are not a Blazor app, and a Blazor app does not rely on POST requests from a <form>. Thus, readonly for inputs there does not tie well with the framework concepts. If that turns out to be the way to allow copying, it might get added for that reason, but that will be subject to research on that particular feature. It is imperative for our components to follow the best practices for the framework and readonly is not part of that.

Regards,
Marin Bratanov
Progress Telerik

Hi Ian,

The HTML tag has the need for such an attribute, but a Blazor component does not. A Blazor form is not supposed to do a POST on its own in the first place, this should go through a service and the service should decide what to send, where to send it and how to send it.

Thus, the Enabled parameter of the Telerik Blazor Textbox serves the purpose of letting it show a value to the user, but not letting them edit it. It even showcases that the input is disabled, which is not something the readonly attribute does - and thus the Telerik component improves the UX immensely over the standard readonly attribute.

Thus, I cannot agree that a Readonly attribute is an enhancement - it has bad UX by default, and it is not used by Blazor. At the same time, we have an alternative that serves the Blazor purpose and provides a better UX - the Enabled parameter.

Regards,
Marin Bratanov
Progress Telerik

Hi Ian, Smiljan,

Setting the Enabled parameter of the Telerik textbox to true disables it so the user can't edit it. It also adds a grey-out effect, you can see this in its live demo.. If you want to make it stronger, you can add some CSS rules in your app to do so.

Here are a few examples of CSS rules to tackle the appearance:

<style>
    .k-textbox.k-state-disabled {
        background: lightgrey; /*make background darker gray to more clearly stand out as not editable*/
        opacity: 1;
    }

        .k-textbox.k-state-disabled.no-grey{
            background: white; /*or make background white like in the regular input so it is totally unclear it is not editable*/
        }
</style>

<TelerikTextBox Value="Enabled"></TelerikTextBox>
<br /><br />
<TelerikTextBox Enabled="false" Value="Disabled"></TelerikTextBox>
<br /><br />
<TelerikTextBox Enabled="false" Class="no-grey" Value="Disabled NoGrey"></TelerikTextBox>
<br /><br />
<input type="text" value="Readonly" readonly="readonly" />

And here is what that results in:

A "real" readonly HTML attribute does not make sense for Blazor because Blazor forms do not make a POST request by default. To send data to a service, you would handle the OnSubmit and/or OnValidSubmit event the form exposes, and send the model you get to your data service. For some cases, that service might serialize it and send it over the wire in and HTTP request (maybe to a REST api), but this is not something that is the duty of the form. Thus, the readonly attribute is not relevant to a Blazor component.

The Telerik suite of components comes with all necessary inputs, so there is no reason to mix in the standard inputs with the Telerik ones - you can use just the Telerik ones to create your forms. Our Form component can even automatically generate them for you.

Regards,
Marin Bratanov
Progress Telerik

Hello Patrick,

You can choose which event to bind to. With the standard HTML elements, that's the onchange event, whlie we use oninput, so you can do the same to get events on every keystroke.

Here's a basic example:

<input type="search" value="@theSearchText" @oninput="@InputHandler" />

@code{
    string theSearchText { get; set; }

    async Task InputHandler(ChangeEventArgs e)
    {
        theSearchText = e.Value.ToString();
        Console.WriteLine(theSearchText);
    }
}

Regards,
Marin Bratanov
Progress Telerik

Hi Patrick,

The <TelerikTextBox> component will use an <input type="text" />. You can alter things like its autocomplete and inputtype parameters that match to the corresponding HTML attributes: https://demos.telerik.com/blazor-ui/textbox/customization. An <input type="search"> does not offer extra functionality or attributes, yet if the type attribute is important to you, you can use your own HTML element and style it through our themes: https://docs.telerik.com/blazor-ui/themes/form-elements#inputs.

Regards,
Marin Bratanov
Progress Telerik

Hi Seth,

You can use the Enabled parameter to denote that a field cannot be edited to the user. Or, you can wrap it in an if-else block to show the values as text when they should not be editable, and only render a textbox when they should be.

If you are using a grid to insert/edit records, see here on changing the Editable parameter of a column based on a condition (such as edit or insert is being made).

Regards,
Marin Bratanov
Progress Telerik

Hi Seth,

Could you explain a Blazor scenario that requires ReadOnly and cannot be solved with Editable and/or an if-block around the textbox? We haven't been able to come up with a meaningful scenario for such a parameter and decided to leave it out to avoid clutter.

As for styling - I would recommend that you keep disabled inputs visually distinct from enabled inputs for your users so that they have a better experience.

Nevertheless, you could inspect the component and alter some CSS rules by following this blog post. Here's a sample I made for you that removes the two key settings that make up the disabled appearance.

<style>
    .k-textbox.k-state-disabled{
        filter: initial;
        opacity: 1;
    }
</style>

<TelerikTextBox @bind-Value="@EnabledTbValue" />
<br />
<br />
<TelerikTextBox @bind-Value="@DisabledTbValue" Enabled="false" />

@code{
    string EnabledTbValue { get; set; } = "first";
    string DisabledTbValue { get; set; } = "second";
}

Regards,
Marin Bratanov
Progress Telerik

An inputmode parameter would also be helpful. Just leaving this here for posterity in relation to this thread https://www.telerik.com/forums/support-for-inputmode-or-pattern

--Marin

Hi all,

As a first enhancement in this regard, our 2.8.0 release will provide Id parameters for all input type components (Textbox, NumericTexbox, DropDownList, and so on) so you can easily attach labels to them (<label for="theIdParamString">lorem ipsum</label>).

Regards,
Marin Bratanov
Progress Telerik

Hi Robert,

If you click the Follow button at the top of the page, you will get email notifications when there is an update on this task.

Regards,
Marin Bratanov
Progress Telerik

A quick update - you can try getting a Telerik-like appearance for standard textboxes by adding the k-textbox class to them, something like this:

            <TelerikTextBox Label="Username:" />
            <br />
            <br />
            <input type="password" placeholder="Password:" class="k-textbox" />

Regards,
Marin Bratanov
Progress Telerik

Depending on what the framework starts doing, we may no longer have to implement parameters for DOM attributes. We will see, and until then I can't say what will happen with the current ones you requested.

--Marin

For the time being you can use Enabled instead of ReadOnly. For the others - I agree they would certainly be nice features.