#12799 closed bug (notabug)

Opened October 29, 2012 07:45AM UTC

Closed November 21, 2012 10:00PM UTC

Last modified April 17, 2013 11:55PM UTC

replaceWith fails when MIME is application/xhtml+xml

Reported by:	ndobrynin	Owned by:	ndobrynin
Priority:	undecided	Milestone:	None
Component:	manipulation	Version:	1.8.2
Keywords:		Cc:
Blocked by:		Blocking:

Description

I needed to use replaceWith to perform a very simple task. It didn't work, so I took the following demo posted on the website

<!DOCTYPE html>

<head>

</head>

<body>

<p>Hello</p>

<p>cruel</p>

<p>World</p>

jQuery("p").replaceWith( "<b>Paragraph. </b>" );

</script>

</body>

</html>

(The xmlns attribute was added by me).

It fails in Firefox 16.0.1 (Fedora) and Chromium 21.0.1180.89 (Fedora) when the content is served as application/xhtml+xml. It also fails on the Firefox (not sure what version) I have on my Android phone.

Attachments (0)

Change History (30)

Changed October 29, 2012 01:38PM UTC by timmywil comment:1

component:	unfiled → manipulation
owner:	→ ndobrynin
status:	new → pending

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket.

Additionally, be sure to test against the jQuery Edge version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/. Open the link and click to "Fork" (in the top menu) to get started.

Changed October 29, 2012 06:33PM UTC by ndobrynin comment:2

status:	pending → new

Please see http://jsfiddle.net/ndobrynin/Ygnu3/1/.

Changed October 30, 2012 10:32PM UTC by dmethvin comment:3

This is tricky to repro. What error do you get from Chrome when you do this? Please report the error from the UNMINIFIED file.

Changed November 05, 2012 09:55PM UTC by ndobrynin comment:4

I have not seen any errors in Chrome and FF alike. Also, you can catch this

bug in action:

http://horizontwenzel.de/html/test/test-unminified.xhtml

http://horizontwenzel.de/html/test/test-unminified.html

http://horizontwenzel.de/html/test/test-minified.xhtml

http://horizontwenzel.de/html/test/test-minified.html

Minified or not makes absolutely no difference, as far as FF and Chrome

are concerned.

Changed November 05, 2012 10:17PM UTC by ndobrynin comment:5

Just a quick follow up. I am using the latest Fedora 17 on 64-bit AMD.

The bug also presents itself on Android 2.<something> with FF-17 beta.

Changed November 21, 2012 10:00PM UTC by dmethvin comment:6

resolution:	→ notabug
status:	new → closed

From the XHTML Strict DTD it looks like a b tag can't be below the body.

http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict

If you read otherwise please explain via a traversal of the DTD and I'll reopen. I suggest you switch to HTML5 doctype and avoid this nonsense.

Changed November 23, 2012 12:11AM UTC by ndobrynin comment:7

I am using HTML5. I've updated the test case (see below), so it now has a div in place of the <b>, and the problem is still there.

Technically, <b> is not supported in HTML5, but in the actual code I was doing something totally different, so the problem is not due to that. The code below validates.

<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>replaceWith fails when MIME is application/xhtml+xml</title>

</head> <body> <p>Hello</p>

</body> </html>

Changed April 16, 2013 01:18PM UTC by adam.lakomy@outlook.com comment:8

Hi,

it is still a bug. But its not visible on jsfiddle.

When you create a valid xhtml file like:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
  <style type="text/css">
    button { display:block; margin:3px; color:red; width:200px; }
    div { color:red; border:2px solid blue; width:200px;
      margin:3px; text-align:center; }

  </style>
</head>
<body>
 
<button>First</button>
<button>Second</button>
<button>Third</button>
 
<script>
$("button").click(function () {
  $(this).replaceWith( "<div>" + $(this).text() + "</div>" );
});
</script>
    </body>
</html>

its not working. On other hand when you change only a doctype to html valid it works perfectly.

Changed April 16, 2013 01:37PM UTC by dmethvin comment:9

Nope, that document isn't valid according to the W3C HTML Validator. A button element can't be directly below the body.

Changed April 16, 2013 07:47PM UTC by ndobrynin comment:10

Guys, I am requesting a reopen for this bug. Thankfully, this still gets attention.

Many thanks,

Nickolai Dobrynin

Changed April 16, 2013 07:53PM UTC by dmethvin comment:11

You have not provided a valid test case yet, so it won't be reopened.

Changed April 16, 2013 08:12PM UTC by ndobrynin comment:12

This is surprising. The code I posted in comment 7 validates. Am I missing something?

Changed April 16, 2013 08:22PM UTC by dmethvin comment:13

Not validating here: http://i.imgur.com/R4bqYI6.png

In particular, <button> elements are not block elements and therefore can't be direct children of the <body>, just like I said in comment 6 above.

Please, please, PLEASE just use HTML5 and give up on XHTML if you aren't going to follow its stupid restrictive rules. Very few pages that are marked XHTML on the web are actually XHTML.

Changed April 16, 2013 09:07PM UTC by ndobrynin comment:14

PLEASE PLEASE PLEASE read carefully. The button example is NOT the one I was talking about and was posted by a different person. I referred to comment 7, *NOT* comment 8.

The code I posted in comment 7 does validate.

PS Of course, button is not a block-level element. And, of course, I've been using HTML5 throughout this entire bug report.

Changed April 16, 2013 09:17PM UTC by dmethvin comment:15

@ndobrynin, your example seems to work for me. If you have a failing test case and it's not XHTML, please don't add to this ticket. Create a new one with a failing test case. I didn't see that your failed here:

http://jsfiddle.net/5LdAa/1/

Changed April 16, 2013 09:32PM UTC by anonymous comment:16

@methvin, are you sure you served it as application/xhtml+xml as opposed to text/html? I have just re-tested it on FF-20 running on x86_64 Fedora-18 and Chromium 25.0.1364.172 and, sadly, got the same outcome. It also fails on FF-20.0.1 on Android.

Changed April 16, 2013 09:43PM UTC by dmethvin comment:17

Comment 7 says you are using HTML5 and uses an HTML5 doctype. So are you now saying you are serving that markup as XHTML? If you serve it as HTML5 does it work? If so is there a reason to not use HTML5 since the doctype says it's HTML5? What does the browser do with a document served as XML+XHTML that has a doctype that isn't XML+XHTML? Is there a reason to do that?

Changed April 16, 2013 10:04PM UTC by ndobrynin comment:18

@methvin,

Answering point by point:

So are you now saying you are serving that markup as XHTML?

Yes, this was in the title of the original bug report.

If you serve it as HTML5 does it work?

Didn't really try, I admit. This was outside the scope of the bug report.

is there a reason to not use HTML5 since the doctype says it's HTML5?

The <!DOCTYPE html> is common to both HTML5 and XHTML5. The XHTML preamble (<?xml version="1.0" encoding="UTF-8"?>) is optional. The reason I omit the preamble is that I also want to serve this to IE7+.

What does the browser do with a document served as XML+XHTML that has a doctype that isn't XML+XHTML?

It *is* XML+XHTML (see above). No yellow screen of death here, if this is what you have in mind.

Changed April 17, 2013 01:35AM UTC by ndobrynin comment:19

@methvin, unless you have further reservations, I am requesting that the bug be reopened. I posted my comment 7 a long time ago, and I assumed you were satisfied. I did not realize we had a misunderstanding going on. Thx.

Changed April 17, 2013 02:08AM UTC by dmethvin comment:20

Your document in comment 7 does does not validate as XHTML in the W3C XHTML Validator, it sees the document as HTML5 not XHTML due to the doctype. I can reopen this ticket if you can provide a test case that validates cleanly as XHTML in the W3C HTML Validator.

Changed April 17, 2013 02:44AM UTC by ndobrynin comment:21

W3C XHTML Validator, it sees the document as HTML5 not XHTML due to the doctype.

Correct me if I am wrong: DOCTYPE has no significance when the document is XML+XHTML. From http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#writing-xhtml-documents and http://en.wikipedia.org/wiki/Document_Type_Declaration

"XML documents may contain a DOCTYPE if desired, but this is not required to conform to this specification."

and

"The DOCTYPE is optional in XHTML5 and may simply be omitted. However, if the markup is to be processed as both XML and HTML, a DOCTYPE should be used."

What puzzles me is that the validator does not provide XHTML5 as a possible option for doctype. Maybe because it's in preliminary stage.

Objections?

Changed April 17, 2013 02:54AM UTC by dmethvin comment:22

No objections at all. Just provide a test case that passes the W3C XHTML Validator. I don't think it's unreasonable to start there.

Changed April 17, 2013 03:08AM UTC by ndobrynin comment:23

At present, the validator does not have that ability: it does not support XHTML5 validation, as per my previous post. Otherwise how could it have deduced the doctype as HTML5 given the xml+xhtml mime type?

This is why the only choice is to look at the code and decide if it's valid, and if not, why not. This is also why I am providing all these arguments.

Changed April 17, 2013 04:38AM UTC by ndobrynin comment:24

I found a validator that does support XHTML5: http://html5.validator.nu/

It does validate the document in question.

Changed April 17, 2013 04:04PM UTC by dmethvin comment:25

Wow, so the validator doesn't catch scripts that aren't in CDATA blocks? Yet another reason to use HTML5 if you ask me.

Changed April 17, 2013 08:38PM UTC by ndobrynin comment:26

Is it fair to say that jQuery does not support XHTML5? If so, it's worth mentioning on the website.

Any discussion concerning XHTML5 and application/xhtml+xml will hit the same roadblock I hit.

Changed April 17, 2013 08:49PM UTC by dmethvin comment:27

What are you talking about? Your page isn't valid XHTML. The script isn't in a CDATA block.

Changed April 17, 2013 09:48PM UTC by ndobrynin comment:28

Yes, sir! Placing it inside a CDATA block solves it, which is extremely helpful. Having said this, the supposedly invalid test in comment 7 was a well-formed XML document, and, according to

https://developer.mozilla.org/en-US/docs/Writing_JavaScript_for_XHTML

there is no requirement to enclose Javascript in XHTML, unless it's got special characters that break XML validity (e.g. if (i < 10)), which was not the case here.

Well, at least we now have a definitive solution. For that I'm grateful.

Changed April 17, 2013 10:09PM UTC by dmethvin comment:29

there is no requirement to enclose Javascript in XHTML,

Right, you can take your chances and then spend a lot of yours and someone else's time trying to debug the problem instead of consistently using CDATA.

unless it's got special characters that break XML validity (e.g. if (i < 10)), which was not the case here.

Yes it was. What's inside that JavaScript string that XHTML doesn't understand? Markup.

Well, at least we now have a definitive solution.

Not if you don't understand the problem.

If the problem isn't obvious still, don't use XHTML. It sure wasn't obvious TO ME for a while. I don't use XHTML and I am happier for it, except when people post bug reports like this and I remember then why XHTML is such a dumb idea.

Changed April 17, 2013 11:55PM UTC by ndobrynin comment:30

Very sorry, and I mean it, for wasting your time, which I probably did. Hopefully, this will become yet another source people can refer to in the future.

For the problem you mentioned, it must have something to do with infinite recursion. Trees (XHTML trees, in this particular case) are "naturally recursive", so replacing may never end UNLESS you cut it at the knees by putting CDATA around: no more self-referential data strucs. By doing so, you mimic the old HTML (without X) behavior.

Side navigation