There really are two questions that you're asking (or at least can be interpreted):

1. Can the quoted value attribute of input[type=text] be injected if quotes are disallowed?




2. Can an arbitrary quoted attribute of an element be injected if quotes are disallowed.

The second is trivially demonstrated by the following:

<a href=javascript:alert(1234);>Foo</a>

Or

<div onmousemove=alert(123);>...

The first is a bit more complicated.

HTML5

According to the HTML5 spec:

Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand.

Which is further refined in quoted attributes to:

The attribute name, followed by zero or more space characters, followed by a single U+003D EQUALS SIGN character, followed by zero or more space characters, followed by a single (U+0022) character, followed by the attribute value, which, in addition to the requirements given above for attribute values, must not contain any literal U+0022 QUOTATION MARK characters (), and finally followed by a second single (U+0022) character.

So in short, any character except an ambiguous ampersand (&[a-zA-Z0-9]+; when the result is not a valid character reference) and a quote character is valid inside of an attribute.

HTML 4.01

HTML 4.01 is less descriptive than HTML5 about the syntax (one of the reasons HTML5 was created in the first place). However, it does say this:

When script or style data is the value of an attribute (either style or the intrinsic event attributes), authors should escape occurrences of the delimiting single or double quotation mark within the value according to the script or style language convention. Authors should also escape occurrences of & if the & is not meant to be the beginning of a character reference.

Note, this is saying what an author should do, not what a parser should do. So a parser could technically accept or reject invalid input (or mangle it to be valid).

XML 1.0

The XML 1.0 Spec defines an attribute as:

Attribute ::= Name Eq AttValue

where AttValue is defined as:

AttValue ::= '' ([^<&] | Reference)* '' | ' ([^<&'] | Reference)* '

The & is similar to the concept of an ambiguous ampersand from HTML5, however it's basically saying any unencoded ampersand.

Note though that it explicitly denies < from attribute values.

So while HTML5 allows it, XML1.0 explicitly denies it.

What Does It Mean

It means that for a compliant and bug free parser, HTML5 will ignore < characters in an attribute, and XML will error.

It also means that for a compliant and bug free parser, HTML 4.01 will behave in unspecified and potentially odd ways (since the specification doesn't detail the behavior).

And this gets down to the crux of the issue. In the past, HTML was such a loose spec, that every browser had slightly different rules for how it would deal with malformed html. Each would try to fix it, or interpret what you meant. So that means that while a HTML5 compliant browser wouldn't execute the JS in <input type=text value=<script>alert(0)</script>>, there's nothing to say that a HTML 4.01 compliant browser wouldn't. And there's nothing to say that a bug may not exist in the XML or HTML5 parser that causes it to be executed (though that would be a pretty significant problem).

THAT is why OWASP (and most security experts) recommend you encode either all non-alpha-numeric characters or &< inside of an attribute value. There's no cost in doing so, only the added security of knowing how the browser's parser will interpret the value.

Do you have to? no. But defense in depth suggests that, since there's no cost to doing so, the potential benefit is worth it.