Can we use AJAX for updating a XHTML page?
To connect the html page, we used to write:
xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
document.getElementById("target").innerHTML=xhr.responseText;
}
}
However, we can't change innerHTML to innerXHTML, because AJAX doesn't accept it.
Yes, you can update XHTML pages using ajax. You still use innerHTML (or the DOM methods). The description of innerHTML in the HTML5 spec describes how XML vs. HTML should be treated.
Re the various DOM methods, some reading/reference material:
DOM2 Core
DOM2 HTML (which applies to XHTML documents as well)
DOM3 Core
HTML5 Web Application APIs
My first thought was "of course!". As T.J. Crowder points out, standards-compliant browsers which follow the spec should have no problem.
However, there does seem to be talk of some issues using innerHTML and maintaining well-formed XHTML markup in older versions of IE.
Keep in mind that this is old information. It may no longer be a problem.
http://www.stainlessvision.com/jquery-html-vs-innerxhtml (which uses innerHTML)
http://www.stevetucker.co.uk/page-innerxhtml.php
My experience has been to the contrary, i.e. using innerHTML to insert markup is not a problem.
The AJAX piece is really irrelevant here; the question is whether or not innerHTML can be trusted to preserve the integrity of the markup being inserted into the document.
My site linked in my profile is served entirely as XHTML served as actual XHTML, application/xhtml+xml. Clicking on 'Site Options' at the top-right will in example load content via AJAX.
Code is not text, do not use responseText, use responseXML.
Never EVER use innerHTML, it's a proprietary Microsoft JScript method that is not compatible with the DOM. Using it adds huge swathes of ambiguity to your code, JavaScript may see elements you've loaded via AJAX but probably won't.
Use importNode as I have, these are two different document owners and you have to use importNode to load content from different documents.
Related
OK I don't use js enough to know, but is there a way to get the real source code of the page with it?
document.body.innerHTML for example gives some kind of "fixed up" version where malformed tags have been removed.
I'm guessing using XMLHttpRequest on the original page might work, but seems kind of stupid.
This happens because browsers parse the DOM and don't keep the HTML in memory. What is returned to you is the browser's conversion of the current DOM back to HTML, which is the reason for the uppercase tags and lack of self closing tags where applicable.
An XMLHttpRequest would be the best way to go. In most cases, assuming the server doesn't send the no-cache header, and the HTML page has finished downloading, the XMLHttpRequest would be almost instant because the file is fetched from the cache.
For accessing JS of the same origin, XMLHttpRequest is quite fine. You can have access to any JS document in "raw" format using this technique without the browser getting in the way (i.e. conversion to DOM and back).
I am not sure I understand your comment re: XMLHttpRequest being stupid : is it because you are worried about the potential duplication of work? i.e. getting the code 2times from the origin server.
I typically use FireBug when I want to peruse or copy source files.
I've been working on a small project, which changes site content on load.
I used data-*attributes, and after job has been done (script replaces what has to be replaced) they would get removed.
However, I realized my very own attributes worked also. So instead of
data-myAttribute="value"
I could simply used
myAttribute="value"
What is browser support on those attributes?
(My very own attributes worked on Chrome v57)
You can pretty much add any attribute you want to any HTML tag. However, this is not supported by the HTML standard. It does work in pretty much any browser, but it might not be supported in the future. In addition, HTML validators will reject your HTML as invalid if you use non-standard attributes.
The whole reason we have data-* attributes is because those are standardized and are guaranteed to be supported and accepted by validators, and also are guaranteed to not clash with any future attributes that might get added to HTML.
Do not use custom attributes without the data-* prefix, as that might make your HTML break without any warning as the HTML standard evolves.
As for the question itself: As this is non-standard, browser support is not documented.
Just a quick validation question, I get:
document type does not allow element "div" here
And my code:
$('#wrapper').prepend('<div id="slider"></div>');
It's just a JS stuff, how do I handle this?
I can't think of any time you would get that error in the middle of a piece of JavaScript unless you are using XHTML, in which case the short answer is: Stop using XHTML, start using HTML 4 or 5.
The reason you get the error is described in the XHTML 1.0 specification:
In XHTML, the script and style elements are declared as having #PCDATA content. As a result, < and & will be treated as the start of markup
The latest version of the XHTML Media Types note provides work–arounds:
DO use external scripts if your script uses < or & or ]]> or --. DO NOT embed a script in a document if it contains any of these characters.
and
If you must embed the content, the following patterns can be used:
<style>/*<![CDATA[*/
...
/*]]>*/</style>
This is all rather a lot of effort, and just switching to HTML is a simpler option. Browsers are designed for HTML and their XHTML support is provided as an afterthought. If you get any benefits from XHTML it will be from using it with server side tools as part of your publishing process … and not many people are doing that.
I inherited an ancient codebase that includes pages with <script type="text/jscript"> -- yes, my life really does suck that much. The script appears to do nothing in modern, decent browsers (FF and Chrome, for a start) and I'm wondering if the stated script type is causing it to be ignored. I spent some time trying to figure out what's going on, and I see things like
As explained by JavaScript guru Douglas Crockford in his talk entitled The JavaScript Programming Language on YUI Theater, "[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues."
on Wikipedia. So Javascript == JScript? But then, I see conflicting information, like this answer which seems to suggest that script that's declared as JScript will only run in IE.
So: can I just change the type tag and everything will work fine? Is there a simple process for conversion? If not, I may just scrap the whole thing and start over.
From HTML 5 chapter 4.3
7) If the user agent does not support the scripting language given by the script block's type for this script element, then the user agent must abort these steps at this point. The script is not executed.
That same chapter also says
If either:
the script element has a type attribute and its value is the empty string, or
the script element has no type attribute but it has a language attribute and that attribute's value is the empty string, or
the script element has neither a type attribute nor a language attribute, then
...let the script block's type for this script element be "text/javascript".
so I would just remove type="text/jscript" save a bit on bandwidth and live happily ever after.
So Javascript == JScript?
JScript is what Microsoft calls JavaScript
But then, I see conflicting information, like this answer which seems to suggest that script that's declared as JScript will only run in IE.
That doesn't conflict. It just means that other browsers don't recognise the mime type.
Browsers will ignore script elements with a type they do not recognise. text/jscript is non-standard and most browsers don't recognise it (Internet Explorer considers it an alias for text/javascript).
can I just change the type tag and everything will work fine?
Probably. The script might depend on other proprietary Microsoft—isms (such as document.all) or other non-standard behaviour (automatic id attribute to JS global conversion or treating CSS lengths that are missing a unit as pixels) though.
The other answer you linked to is completely incorrect. There are no differences between JScript and JavaScript. Changing the script type to "text/javascript" should work (unless the intent of the author was to force it so that only IE ran the script)
the type= requirements have been taken out of html5. I believe the proper xhtml code would be ...
<script type="text/javascript">
<![CDATA[
// content of your Javascript goes here
]]>
</script>
... but browsers did not follow the requirements of xhtml of forcing an error. Most web hosts keep the delivery of xhtml and html docs as MIME-type "text/html", not the "application/xhtml+xml" which should force an error if the xhtml does not validate.
HTML4 uses are variety of types ... http://www.w3.org/TR/html4/interact/scripts.html ... but browsers do not force html4 validation.
vscript, tcl don't have common support - we are talking about Javascript or any of the other names it gets as in becomes a more powerful language.
A bogus "type" attribute will definitely make scripts not work. The browser thinks you don't want it to run the script, basically.
Really, the "type" attribute is not necessary unless you definitely don't want the browser to run a script (which people do when their "scripts" are actually template bodies, or other data like that). You could either change all yours to "text/javascript" or just get rid of the attribute entirely.
Google's JavaScript API makes use of the function document.write, thus is not usable in XHTML.
Do you know a workaround how to get the custom search working in XHTML? Or is there a working alternative?
Are you actually serving your XHTML as XML (application/xhtml+xml)? If not, you don't have to worry about it, yet. document.write will still work in text/html mode though it is certainly poor practice in general.
If you really are serving native XHTML... well, I suspect you may get more problems than just document.write, as there are a fair few things that can trip scripting up when it's not expecting to be run in XHTML. But you can hack it the problem by sabotaging document.write.
The simplest method would be something like:
document.write= function(s) {
document.getElementById('placetoputwrittenstuff').innerHTML= s;
};
however you would need more messing around if it tried to write <script> tags (since setting them through innerHTML doesn't execute them; you would have to pick them out with getElementsByTagName and run each one manually), or partial bits of elements across different calls to write (in which case you'd have to collect strings and glue them together when it's finished).