That's a good corner-case.  While you have ie7 open, can you inspect the DOM 
given your input?  How many attributes does your 'a' element have?

First, sorry about the multiple submissions.. i got 500 errors, i assumed my 
submission wasn't processed. 

I only have ietester for simulating ie7, which does not provide the dom 
inspector. so i can't see how may attributes the a element has in ie7, sorry

Can you explain this a little more? This doesn't look like it could possibly be 
correct HTML syntax (with the extra "). Is this an IE hack? Typo? If it's a 
hack, what's the purpose, can you point to a reference.

Well, it sure isn't valid html (hence the bug report title :)).
As far as i know this isn't generally used as an ie rendering hack.

I have seen this happen often in the past years in 2 general cases:
- in this case, the html was directly entered by end users through a cms. it is 
a typo this time.
- other times i have seen this happen, is when a bad script is generating html. 
in that case, it's a buggy html generator



I don't know about any numbers about how often this occurs; however, there is a 
potentially big penalty when it occurs in these ways:
- the resulting rendering difference is hard to spot, causing people to spend 
lots of time finding out what is going on.
- the rendering difference will probably go unnoticed for some time (lots of 
people do not test with every browser), potentially crippling stuff (in this 
case, the form where it was encountered did not display it's link to the 
agreement pdf)
- the reason why that occurred is tough to explain to customers. every major 
browser handles the original (invalid) input html OK. At least ie7 seems to 
fail on the (invalid but slightly different) output html, maybe other older 
browsers fail too.
- this might be just an instance of a more general case, i have not thought 
about other invalid tag/value/browser combinations that get an extra space.

Ideally, i think the parser should this invalid html alone.

Regards, Otto van der Schaaf

I understand the problem; we generally do try to leave invalid HTML alone.  But 
we made a design decision about how to do that which is good for some cases and 
not this one.  The decision was that during attribute parsing, we would look 
for "garbage" characters and retain them in our data model.  In particular we 
saw sometimes <a b=c ; d> (or something like that).  We wanted to retain the 
";" and not eliminate it from our data model.

I think we would treat <a b="c" " d> the same way.  The tricky thing about this 
bug is that we don't have (currently) in our data model a way of distinguishing 
these two:
   <a b="c"" d>
   <a b="c" " d>
In either case we'd treat this as a valid tag with three attributes.  I guess 
to replicate this we'll have to add a new 'bool' field to 
HtmlElement::Attribute to indicate whether it is separated from the previous 
attribute by whitespace.  I don't think we want to retain all the 
intra-attribute whitespace as that would make our memory usage worse to handle 
this corner case.

I've confirmed this problem still exists after Maks' recent parser improvement.