Blazor: Two way data binding workaround with date input

Blazor is an experimental framework that implements many essential elements of a C#/HTML/CSS framework. See for details.

Two way data binding is available for many elements but two notable missing elements are the input elements radio buttons and  dates as of Blazor 0.5.1. The radio button issue has a clean workaround by jsakamoto in This post offers a workaround for dates.

Start with a definition of the date field in your cshtml file like:

<input type="date" onchange="@SelectedDateChanged" id="scheduleDate"/>

In the code-behind file define SelectedDateChanged and OnAfterRenderAsync as

        protected DateTime pSelectedDate { get; set; }
        protected async void SelectedDateChanged()
            string selectedDateAsString = await JSRuntime.Current.InvokeAsync("customizationJsFunctions.getSelectedDate");
                pSelectedDate = Convert.ToDateTime(selectedDateAsString);
                pSelectedDate = DateTime.Now;

        protected override async Task OnAfterRenderAsync()
            if (pSelectedDate != DateTime.MinValue)
                string selectedDateAsString = pSelectedDate.ToString("yyyy-MM-dd");

                await JSRuntime.Current.InvokeAsync("customizationJsFunctions.setSelectedDate", selectedDateAsString);

As you can see there are two calls to JSInterop. Define the following script:

        window.customizationJsFunctions = {
            getSelectedDate: function () {
                return document.getElementById("scheduleDate").value;
            setSelectedDate: function (selectedDate) {
                document.getElementById("scheduleDate").value = selectedDate;
                return "OK";

And with this you have the equivalent functionality of data binding with the input date element.

Silverlight 5.0 and https Extended Validation

I’ve set up a web application for a client and ran into a problem with https Extended Validation. The site design called for use of extended validation in order to provide an extra layer of comfort for the end users. I spun up the site only to have the following displayed in Chrome and Firefox:



IE was OK:


Not a very successful display of the EV work. Chrome was actually quite helpful with an extended message about a file that was downloaded. So it took some work with the Chrome developer tools to discover that the root of the problem was an image that was being downloaded from Microsoft. If you look at the .aspx or .html page created to host a Silverlight app, the Silverlight plugin has an image that is displayed if Silverlight is not installed (<img src=”″ alt=”Get Microsoft Silverlight” style=”border-style:none”/>). This clearly breaks the EV check as information would come from a non-validated site. The solution is simple. Simply host the image on the web site with the desired EV, ala (<img src=”SLMedallion_ENU.png” alt=”Get Microsoft Silverlight” style=”border-style: none”/>)

Now the browsers show up like this:

So Chrome, Firefox, & IE do the right thing and have the EV shown as the company name in green (URL mostly redacted).

[EDIT 2015-10-02] When this post was written all three browsers showed an EV failure when an element in the HTML was from a non-EV site (April 2012). Retested on October 2015 with current browser versions and the behavior is now correct across all three browsers when EV succeeds. However, IE shows success when both Firefox & Chrome show extended validation issues in the original test. Given that the image is not actually rendered it isn’t really clear which behavior is correct. <ms>