Type attribute is bindable in all supported browsers but IE8

[marclaval]

Following PR #45, consider this template:

# template inputSample(data)
    <div class="info2">All the following inputs are synchronized:</div>
    <div class="section">
        Comment #1: <input type="text" value="{data.comment}"/><br/>
        Comment #2: <input type="{data.comment}" value="{data.comment}"/><br/>
    </div>
# /template

var d={comment:"edit me!"}
inputSample(d).render("output");

The type="{data.comment}" part is not working only in IE8. As a consequence, the behavior of hashspace is inconsistent across the supported browsers.

Possible solutions: 1) Keep the limitation in IE8 only, and so the inconsistency. 2) Implement a complex workaround only for IE8. 3) Extend the limitation to all browsers, until IE8 is no longer supported.

[benouat]

Yesterday I would have vote :two: but after a good night of sleep I am now more in favor for :three:

On top of that, there is not a long list of use-cases for that.

[olaf-k]

I'd go for 1 + proper documentation without hesitation.

[divdavem]

I think it would not be fair to limit other browsers because Internet Explorer is limited. Implementing a complex workaround is not worth it for the rare use cases in which this can be used. So I also vote :one:.

[PK1A]

It would be (3) from me without hesitation, FWIW The main reasoning is that if I code my app in, say, Chrome, I would expect it to have the same functionality across browsers (please note that I'm not taking here about visual differences like animations, rounded corners etc.).

Imagine I'm in a dev team, code my app using the framework, it works it Chrome but the same code doesn't work in IE8. What is the response to be give to devs? I can think of only one: "re-code your functionality" and this would undermine my trust in the framework.

[olaf-k]

First off, browsers already do behave differently, that's actually why JS libraries and framework have been created, so developers are well aware of that. Why should we ignore "visual differences"? HTML5/CSS3 offer dynamic behaviors which are incredibly useful but largely ignored by IE8, does this undermine your trust in the W3C?

Secondly, as @benouat said, "there is not a long list of use-cases for that", which makes it easy to describe this kind of limitation in your documentation. This way, people who must deal with antiquities know they have to code in a slightly less obvious way, and happy devs who are not bound to this requirement can continue without restriction. The only case in which you have to re-code is if you don't RTFM.

Surprisingly though, my argument is --like you-- also about consistency. The difference is that I would rather have a consistent framework with limitations in IE8 behavior rather than consistent IE8 behavior with limitations in the framework. Dumbing down feels wrong.

[benouat]

Ok, nice argumentation ! :+1:

I change my vote for :one:

[piuccio]

This feels like the discussion on jQuery 1 vs 2. Drop IE8 support is always the best thing to do :smile:

[marclaval]

I vote :three: Such discrepancies between the supported browsers would be very frustrating for developers as they are developing with their favorite browser and are counting on the framework for the consistency.

[olaf-k]

The exact same argument for can be applied to developers frustrated to discover that bindings work everywhere but here "and are counting on the framework for the consistency." Please guys, let IE8 die in peace.

[benouat]

Where do we stand on that one ? I think it could be closed no ?

[marclaval]

Looks like there is a majority of :one: , which means no need to change the code. Unless new voters appear before the end of today!

[marclaval]

Option :one: won and this is the current implementation. So the issue can be closed.