Opened 12 years ago
Closed 11 years ago
#23729 closed defect (bug) (worksforme)
Ticket #11289, IE bug fix: always pad the error page with enough characters
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | General | Keywords: | reporter-feedback close |
| Focuses: | Cc: |
Description
Is it really such a good idea to put the padding where it is currently in the error pages? This causes all sorts of problems with Dom parsers... it should be placed somewhere after the html tag or better yet in the body... almost looks like someone is very proud of their fix and wants the world to see it lol
Change History (8)
#2
@
12 years ago
Is it really such a good idea to put the padding where it is currently in the error pages?
Per ticket:11289:3, it should be where it is now. We could probably only print it if $is_IE though.
What problems does it cause?
#4
@
12 years ago
What problems does it cause?
Will cause errors if output is being parsed by dom parsers. Basically breaks XML.
#6
follow-up:
↓ 7
@
11 years ago
nginx's msie_padding directive ends up putting things below the <html>. Still not too sure why we care. I can get a parser to handle this OK. What am I missing?
#7
in reply to:
↑ 6
@
11 years ago
- Keywords close added
As per the XML standard:
Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar.
Therefore, any parsers that can't parse this are violating the XML standard.
for reference: [11340] - #8942
and later [12309] - #11289