Make WordPress Core

Opened 11 years ago

Closed 10 years ago

#23729 closed defect (bug) (worksforme)

Ticket #11289, IE bug fix: always pad the error page with enough characters

Reported by: wp4j's profile wp4j Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: reporter-feedback close
Focuses: Cc:


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)

#1 @dd32
11 years ago

for reference: [11340] - #8942
and later [12309] - #11289

#2 @SergeyBiryukov
11 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?

#3 @SergeyBiryukov
11 years ago

  • Keywords reporter-feedback added

#4 @wp4j
11 years ago

What problems does it cause?

Will cause errors if output is being parsed by dom parsers. Basically breaks XML.

#5 @brokentone
10 years ago

  • Cc kenton.jacobsen@… added

#6 follow-up: @nacin
10 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 @rmccue
10 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.

#8 @nacin
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Thanks for that, rmccue.

Note: See TracTickets for help on using tickets.