Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#12799 closed bug (notabug)

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> <html xmlns="http://www.w3.org/1999/xhtml"> <head>

<script src="ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>

</head> <body> <p>Hello</p> <p>cruel</p> <p>World</p>

<script> 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.

Change History (30)

comment:1 Changed 7 years ago by timmywil

Component: unfiledmanipulation
Owner: set to ndobrynin
Status: newpending

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.

comment:2 Changed 7 years ago by ndobrynin

Status: pendingnew

comment:3 Changed 7 years ago by dmethvin

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

comment:4 Changed 7 years ago by ndobrynin

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.

comment:5 Changed 7 years ago by ndobrynin

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.

comment:6 Changed 7 years ago by dmethvin

Resolution: notabug
Status: newclosed

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.

comment:7 Changed 7 years ago by ndobrynin

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> <meta charset="utf-8"/>

<script src="http://code.jquery.com/jquery-latest.js"></script>

<title>replaceWith fails when MIME is application/xhtml+xml</title> </head> <body> <p>Hello</p>

<script> jQuery("p").replaceWith( "<div>Good buy</div>" ); </script>

</body> </html>

comment:8 Changed 7 years ago by adam.lakomy@…

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.

comment:9 Changed 7 years ago by dmethvin

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

comment:10 Changed 7 years ago by ndobrynin

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

Many thanks, Nickolai Dobrynin

comment:11 Changed 7 years ago by dmethvin

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

comment:12 Changed 7 years ago by ndobrynin

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

comment:13 Changed 7 years ago by dmethvin

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.

comment:14 Changed 7 years ago by ndobrynin

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.

comment:15 Changed 7 years ago by dmethvin

@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/

comment:16 Changed 7 years ago by anonymous

@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.

comment:17 Changed 7 years ago by dmethvin

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?

comment:18 Changed 7 years ago by ndobrynin

@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.

comment:19 Changed 7 years ago by ndobrynin

@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.

comment:20 Changed 7 years ago by dmethvin

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.

comment:21 Changed 7 years ago by ndobrynin

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?

comment:22 Changed 7 years ago by dmethvin

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.

comment:23 Changed 7 years ago by ndobrynin

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.

comment:24 Changed 7 years ago by ndobrynin

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

It does validate the document in question.

comment:25 Changed 7 years ago by dmethvin

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

comment:26 Changed 7 years ago by ndobrynin

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.

comment:27 Changed 7 years ago by dmethvin

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

comment:28 Changed 7 years ago by ndobrynin

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.

comment:29 Changed 7 years ago by dmethvin

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.

comment:30 Changed 7 years ago by ndobrynin

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.

Note: See TracTickets for help on using tickets.