I just spent an hour trying to figure out why a CSS script wasn't loading. It turns out it was because I typed:
<link rel="styelsheet" href="path/to/script">
instead of
<link rel="stylesheet" href="path/to/script">
It would have been nice had Firefox said something to me, like styelsheet is unknown, or whatever. I would have realized the typo immediately. Any way to get that in the console?
Nothing prevents you from extending the link element with your own custom rel attribute. Due to this, the browser probably chooses to remain silent, assuming you know what you're doing :)
I would encourage you to get an editor that helps here, and leverage the auto-complete/suggestion features of said editor. For example, Visual Studio Code (and other editors) will tab-complete the entire element for you: see below.
If you are using HTML5:
Any HTML5 validator (†) should be able to report this, because styelsheet is not a valid link type.
You may only use link types that are
defined in the HTML5 specification, or
registered in the Microformats wiki existing-rel-values page.
† There are various validators available for Firefox, and I can’t recommend one (and it would be off-topic here anyway), but our sister site Software Recommendations might help.
If you want to find misspellings within links specifically, this will catch most:
var links= document.querySelectorAll('link');
for(var i = 0 ; i < links.length ; i++) {
if(!links[i].rel || links[i].rel !== 'stylesheet' || !links[i].href) {
console.log('ERROR: '+links[i].outerHTML);
}
}
Fiddle
Firefox web developer tools will show that your stylesheet was not loaded, sometimes as an error if it can detect that. Right click on your page and select "Inspect Element" or ctrl-Shift-Q. You can look in the network panel to see what was downloaded. Perhaps other areas there will also highlight your link as a problem.
So, yes, Firefox, and other browsers, will flag that line as a problem in some way.
Related
I'm using mobile template HTML files on a PHPBB forum.
I tested the html for errors at http://validator.w3.org/
The test results showed the following error
Line 24, Column 66: {navlinks.FORUM_NAME}
Bad value up for attribute rel on element a: The string up is not a registered keyword or absolute URL.
Not having heard back from the author and not finding much on Google search, I'm trying to understrand what rel="up" does, if anything constructive.
Can't find any mention as an official HTML attribute
http://www.w3schools.com/tags/att_link_rel.asp
wondering if it's probably safe to just remove the phrase rel="up"
The Internet Assigned Numbers Authority (IANA) keeps a list of link relationships The latest version is from March 21 2013.
up: Refers to a parent document in a hierarchy of documents.
Unfortunately, despite the fact that this registry was long established, it was decided that HTML5 would not use this registry and would use a Wiki page to list the conforming link types instead.
Up, is listed in a rather insane section marked "dropped without prejudice", which nobody seems to know what to do with, or how to get those link types out of.
It's safe to drop it, but some browsers and browser plugins make use of it. For example, I use a Firefox plugin called "Link Widgets" like this to make use of the link type.
From: http://www.w3.org/MarkUp/html3/dochead.html
REL=Up
When the document forms part of a hierarchy, this link references the immediate parent of the current document.
If this is causing any specific problems or unexpected results, please post your code. Thanks.
Hello kind people of the internet,
I've been hacking at this for a while...and have seen several similar postings, but I can't seem to figure this out:
The HTML5 input field validation CSS works in Firefox, Chrome...but alas, not in IE8...and much of my target audience will be using IE8.
...and yes: I'm using Modernizr, and I used Initializr to get the page template and CSS...I'm a bit confused why I can't get things working properly in IE8.
Here's a link to my test page:
Test html5 page
The input field is red before proper entry, then validation simply turns green when input a valid account number, such as:
50011111111
The HTML5 code is as follows:
<label for="account">Account Number: </label>
<input id="account" name="inputAccount"
placeholder="input billing account number"
pattern="/(^500)|^\d{11}"
required
autofocus
type="text"/>
Any suggestions on what is probably a fairly simple thing to fix would be mucho appreciated!
IE just ignors HTML5 elements because it dosen't know about them. From the Modernizr docs
Modernizr runs through a little loop in JavaScript to enable the
various elements from HTML5 (as well as abbr) for styling in Internet
Explorer. Note that this does not mean it suddenly makes IE support
the Audio or Video element, it just means that you can use section
instead of div and style them in CSS.
What this says is that Modernizr will tell IE about the new tags in HTML5 so that you can use CSS on them, but dosen't actually make them do anything. Note too that Modernizr dosen't add default styles for the elements, so they recommend you use an HTML5 CSS reset that makes <section> tags display: block; for example.
With respect to your form validation topek was correct in explaining that Modernizr only detects browser capability, it dosen't actually do anything about it. The proccess behind Modernizr is that you use the built-in yepnope testing feature to see if the user's browser can do 'x' (in this case form validation) and then conditionally and asynchronously load a script or style to "polyfill" (a polite way of saying 'use javascript to mimic native behaviour) for it.
In your case, you will want to use Modernizr.load() to test for Modernizr.input.required and probably Modernizr.input.autofocus too, like this:
//the modernizr conditional load function
Modernizr.load({
//specify the tests, refer to the Modernizr docs for object names
test: Modernizr.input.required && Modernizr.input.placeholder,
//specify what to do if the browser fails the test, can be a function
nope: 'path/to/polyfill/script',
//sometimes you need to run some JS to init that script
complete: function(){ polyfillinitorwhatever(); }
});
And there you go, a pretty stripped-down Modernizr.load. While I find their docs meandering, they actually are very good. Every time I've had a problem and tweeted at Paul Irish, he's sent back a link to the docs where I actually did find my answer upon closer inspection.
Validation is one of the most complex HTML5 features for the browser makers to implement as a standard. While I really like it's simplicity, I've been continuing to use jQuery.validate in all cases except if the user has Chrome or Opera - the FF native validate is weak still. I'd recommend you stick with jQuery for now.
I recently found a new plugin jquery.h5form.
Using this, form validation, like in Opera, will be enabled in all browsers, even IE8.
I think, what you are still missing, is a html5 polyfill for the field validation. You could use for example: http://ericleads.com/h5validate/
More polyfills can be found under: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills
IE8 does not support all, if any, HTML5 elements. You need to have an addon for html5 to work. One addon is modernizer
List of browsers with their score/compatibility in HTML5
I've curious how this should be properly done.
I ran a page im working on through the w3 html validateor and I got one error message
Line 47, Column 54: Attribute "target" exists, but can not be used for this element.**
<ul><li>1000 Design PM</li>
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).
any idea on how i can have a link open a new window but not use the target tag?
You can use JavaScript to open new windows, which avoids the issue of target being invalid in modern HTML.
However, this bypasses various systems people have in place to warn them about new windows (or prevent them from opening) so you are better off using the target attribute (and switching to a Doctype that allows it).
Better still is to leave it to the user to decide when they want a new window. Aside from the annoyance factor, they do introduce accessibility problems.
target="_blank"
Will not validate strict because the 'target' attribute has been deprecated.
Instead, try something similar to the aforementioned onclick workaround, but you don't need the "_blank" in there either. Simply:
1000 Design PM
Will work. The reason for the deprecation of "target" is because HTML is used to semantically mark up data whereas the target attribute was providing behaviour, which is what javascript is for.
If the user has javascript turned off then the URL will simply open in the same window.
The target attribute is not part of the Strict variants of HTML 4 and XHTML 1.0 as well as XHTML 1.1.
So you would need to use a workaround using JavaScript:
1000 Design PM
var aElems = document.getElementsByTagName("a");
for (var i=0, n=aElems.length; i<n; ++i) {
if (/(?:^|\s+)_blank(?:\s+|$)/.test(aElems[i].className)) {
aElems[i].onclick = function() {
return !window.open(this.href, "_blank");
}
}
}
Or (in the future) CSS 3 (see Hyperlink Presentation Module):
a._blank {
target: new;
}
Shouldn't it be...
target="_blank"
Regardless... You could open a new window using javascript, but that breaks the beauty of simple browsing. What if I'm browsing using Lynx or something?
According to W3C, it seems that "target" attribute is not deprecated any more in HTML 5:
The target attribute for the a and area elements is no longer
deprecated, as it is useful in Web applications, e.g. in conjunction
with iframe.
http://www.w3.org/TR/html5-diff/
Using:
target="_blank"
breaks strict XHTML validation methods. Here's a document detailing a workaround:
Instead of target="_blank" (who will never validate) you could use javascript like this:
<a onclick='window.open("./jobops/1000 Design PM.pdf", "_blank");return false;' href="./jobops/1000 Design PM.pdf">1000 Design PM</a>
Then the link will open in a new window, and your page will validate.
The users who doesn't have Javascript enabled (even though that is only about 2% of all users), will still be able to follow the link with this method. The guy's have a good point in the comments :)
Have a nice weekend everyone...
This is something of a follow-up question to my question here. You can find the HTML source in a text file here.
When I load that page in IE8, I get the "Done, but with errors on page." message in my status bar. The detail view shows
Expected identifier
sms Line: 147
Code: 0 Char: 67
and I see absolutely no problems anywhere near there. In IE8, the page is still behaving erratically w/r/t the randomly losing focus as mentioned in my other question.
When I load the same exact page in Firefox (using Firebug) the console shows no errors and the page works perfectly. Any thoughts on what's going on here? This is driving me nuts and making me want to give up on even trying to write an IE friendly page.
Edit: Thanks for all the comments! This page is written as a JSP, so I edit in Eclipse. I found an Eclipse warning about the onblur event for the username field. I switched it from
onblur="alert(document.activeElement + ' class:' + document.activeElement.class)"
to
onblur="alert(document.activeElement)"
and that made the bizarre IE page error vanish. I had been trying to give more info (namely, its CSS class) about specifically which element is stealing focus - to my own detriment, apparently, since Javascript was interpreting the '.class' part in the Java(script) sense there is no class property (I should have been using className).
And, no, the page doesn't validate. But the errors were mostly/all ones that just didn't make sense to me, such as
Line 14, Column 41: Attribute "LANGUAGE" is not a valid attribute. Did you mean "language"?
But I'm still stuck trying to figure out why, as I enter text in the username & password fields, focus randomly switches to a div (working on figuring out which div currently).
Edit 2: It's the div between the two "global nav" comments, at the very top of the body. Still no idea why it's happening, though.
The problem appears to be the line
onBlur="alert(document.activeElement + ' class:' + document.activeElement.class)"
when you take off the ".class" it loads without issue. Are you sure ".class" is valid?
Does your HTML validate?
I agree, IE does a terrible job giving developers information about page errors. I only support IE on the principle that users shouldn't have to download twenty-odd browsers to go to their favorite websites. Web developers have a responsibility to make it "just work". Browser developers have a responsibility to communicate with each other and conform to standards.
Run your javascript through JSLint. You probably have a missing semicolon somewhere or a comma at the end of an object property that shouldn't be there. Firefox is more forgiving than IE when it comes to those types of syntax errors.
Edit: The inline js in your page seems to be OK. Check the contents of qm_scripts.js.
When I remove the .class from document.activeElement.class the error goes away.
The real issue is that you need to be able to debug your JS in IE 8, correct? There is a tool for that! :)
I'm looking for a tool that will give me the proper generated source including DOM changes made by AJAX requests for input into W3's validator. I've tried the following methods:
Web Developer Toolbar - Generates invalid source according to the doc-type (e.g. it removes the self closing portion of tags). Loses the doctype portion of the page.
Firebug - Fixes potential flaws in the source (e.g. unclosed tags). Also loses doctype portion of tags and injects the console which itself is invalid HTML.
IE Developer Toolbar - Generates invalid source according to the doc-type (e.g. it makes all tags uppercase, against XHTML spec).
Highlight + View Selection Source - Frequently difficult to get the entire page, also excludes doc-type.
Is there any program or add-on out there that will give me the exact current version of the source, without fixing or changing it in some way? So far, Firebug seems the best, but I worry it may fix some of my mistakes.
Solution
It turns out there is no exact solution to what I wanted as Justin explained. The best solution seems to be to validate the source inside of Firebug's console, even though it will contain some errors caused by Firebug. I'd also like to thank Forgotten Semicolon for explaining why "View Generated Source" doesn't match the actual source. If I could mark 2 best answers, I would.
Justin is dead on. The key point here is that HTML is just a language for describing a document. Once the browser reads it, it's gone. Open tags, close tags, and formatting are all taken care of by the parser and then go away. Any tool that shows you HTML is generating it based on the contents of the document, so it will always be valid.
I had to explain this to another web developer once, and it took a little while for him to accept it.
You can try it for yourself in any JavaScript console:
el = document.createElement('div');
el.innerHTML = "<p>Some text<P>More text";
el.innerHTML; // <p>Some text</p><p>More text</p>
The un-closed tags and uppercase tag names are gone, because that HTML was parsed and discarded after the second line.
The right way to modify the document from JavaScript is with document methods (createElement, appendChild, setAttribute, etc.) and you'll observe that there's no reference to tags or HTML syntax in any of those functions. If you're using document.write, innerHTML, or other HTML-speaking calls to modify your pages, the only way to validate it is to catch what you're putting into them and validate that HTML separately.
That said, the simplest way to get at the HTML representation of the document is this:
document.documentElement.innerHTML
[updating in response to more details in the edited question]
The problem you're running into is that, once a page is modified by ajax requests, the current HTML exists only inside the browser's DOM-- there's no longer any independent source HTML that you can validate other than what you can pull out of the DOM.
As you've observed, IE's DOM stores tags in upper case, fixes up unclosed tags, and makes lots of other alterations to the HTML it got originally. This is because browsers are generally very good at taking HTML with problems (e.g. unclosed tags) and fixing up those problems to display something useful to the user. Once the HTML has been canonicalized by IE, the original source HTML is essentially lost from the DOM's perspective, as far as I know.
Firefox most likley makes fewer of these changes, so Firebug is probably your better bet.
A final (and more labor-intensive) option may work for pages with simple ajax alterations, e.g. fetching some HTML from the server and importing this into the page inside a particular element. In that case, you can use fiddler or similar tool to manually stitch together the original HTML with the Ajax HTML. This is probably more trouble than it's worth, and is error prone, but it's one more possibility.
[Original response here to the original question]
Fiddler (http://www.fiddlertool.com/) is a free, browser-independent tool which works very well to fetch the exact HTML received by a browser. It shows you exact bytes on the wire as well as decoded/unzipped/etc content which you can feed into any HTML analysis tool. It also shows headers, timings, HTTP status, and lots of other good stuff.
You can also use fiddler to copy and rebuild requests if you want to test how a server responds to slightly different headers.
Fiddler works as a proxy server, sitting in between your browser and the website, and logs traffic going both ways.
I know this is an old post, but I just found this piece of gold. This is old (2006), but still works with IE9. I personnally added a bookmark with this.
Just copy paste this in your browser's address bar:
javascript:void(window.open("javascript:document.open(\"text/plain\");document.write(opener.document.body.parentNode.outerHTML)"))
As for firefox, web developper tool bar does the job. I usually use this, but sometimes, some dirty 3rd party asp.net controls generates differents markups based on the user agent...
EDIT
As Bryan pointed in the comment, some browser remove the javascript: part when copy/pasting in url bar. I just tested and that's the case with IE10.
If you load the document in Chrome, the Developer|Elements view will show you the HTML as fiddled by your JS code. It's not directly HTML text and you have to open (unfold) any elements of interest, but you effectively get to inspect the generated HTML.
In the Web Developer Toolbar, have you tried the Tools -> Validate HTML or Tools -> Validate Local HTML options?
The Validate HTML option sends the url to the validator, which works well with publicly facing sites. The Validate Local HTML option sends the current page's HTML to the validator, which works well with pages behind a login, or those that aren't publicly accessible.
You may also want to try View Source Chart (also as FireFox add-on). An interesting note there:
Q. Why does View Source Chart change my XHTML tags to HTML tags?
A. It doesn't. The browser is making these changes, VSC merely displays what the browser has done with your code. Most common: self closing tags lose their closing slash (/). See this article on Rendered Source for more information (archive.org).
Using the Firefox Web Developer Toolbar (https://addons.mozilla.org/en-US/firefox/addon/60)
Just go to View Source -> View Generated Source
I use it all the time for the exact same thing.
I had the same problem, and I've found here a solution:
http://ubuntuincident.wordpress.com/2011/04/15/scraping-ajax-web-pages/
So, to use Crowbar, the tool from here:
http://simile.mit.edu/wiki/Crowbar (now (2015-12) 404s)
wayback machine link:
http://web.archive.org/web/20140421160451/http://simile.mit.edu/wiki/Crowbar
It gave me the faulty, invalid HTML.
This is an old question, and here's an old answer that has once worked flawlessly for me for many years, but doesn't any more, at least not as of January 2016:
The "Generated Source" bookmarklet from SquareFree does exactly what you want -- and, unlike the otherwise fine "old gold" from #Johnny5, displays as source code (rather than being rendered normally by the browser, at least in the case of Google Chrome on Mac):
https://www.squarefree.com/bookmarklets/webdevel.html#generated_source
Unfortunately, it behaves just like the "old gold" from #Johnny5: it does not show up as source code any more. Sorry.
In Firefox, just ctrl-a (select everything on the screen) then right click "View Selection Source". This captures any changes made by JavaScript to the DOM.
alert(document.documentElement.outerHTML);
Check out "View Rendered Source" chrome extension:
https://chrome.google.com/webstore/detail/view-rendered-source/ejgngohbdedoabanmclafpkoogegdpob/
Why not type this is the urlbar?
javascript:alert(document.body.innerHTML)
In the elements tab, right click the html node > copy > copy element - then paste into an editor.
As has been mentioned above, once the source has been converted into a DOM tree, the original source no longer exists in the browser. Any changes you make will be to the DOM, not the source.
However, you can parse the modified DOM back into HTML, letting you see the "generated source".
In Chrome, open the developer tools and click the elements tab.
Right click the HTML element.
Choose copy > copy element.
Paste into an editor.
You can now see the current DOM as an HTML page.
This is not the full DOM
Note that the DOM cannot be fully represented by an HTML document. This is because the DOM has many more properties than the HTML has attributes. However this will do a reasonable job.
I think IE dev tools (F12) has; View > Source > DOM (Page)
You would need to copy and paste the DOM and save it to send to the validator.
Only thing i found is the BetterSource extension for Safari this will show you the manipulated source of the document only downside is nothing remotely like it for Firefox
The below javascript code snippet will get you the complete ajax rendered HTML generated source. Browser independent one. Enjoy :)
function outerHTML(node){
// if IE, Chrome take the internal method otherwise build one as lower versions of firefox
//does not support element.outerHTML property
return node.outerHTML || (
function(n){
var div = document.createElement('div'), h;
div.appendChild( n.cloneNode(true) );
h = div.innerHTML;
div = null;
return h;
})(node);
}
var outerhtml = outerHTML(document.getElementsByTagName('html')[0]);
var node = document.doctype;
var doctypestring="";
if(node)
{
// IE8 and below does not have document.doctype and you will get null if you access it.
doctypestring = "<!DOCTYPE "
+ node.name
+ (node.publicId ? ' PUBLIC "' + node.publicId + '"' : '')
+ (!node.publicId && node.systemId ? ' SYSTEM' : '')
+ (node.systemId ? ' "' + node.systemId + '"' : '')
+ '>';
}
else
{
// for IE8 and below you can access doctype like this
doctypestring = document.all[0].text;
}
doctypestring +outerhtml ;
I was able to solve a similar issue by logging the results of the ajax call to the console. This was the html returned and I could easily see any issues that it had.
in my .done() function of my ajax call I added console.log(results) so I could see the html in the debugger console.
function GetReversals() {
$("#getReversalsLoadingButton").removeClass("d-none");
$("#getReversalsButton").addClass("d-none");
$.ajax({
url: '/Home/LookupReversals',
data: $("#LookupReversals").serialize(),
type: 'Post',
cache: false
}).done(function (result) {
$('#reversalResults').html(result);
console.log(result);
}).fail(function (jqXHR, textStatus, errorThrown) {
//alert("There was a problem getting results. Please try again. " + jqXHR.responseText + " | " + jqXHR.statusText);
$("#reversalResults").html("<div class='text-danger'>" + jqXHR.responseText + "</div>");
}).always(function () {
$("#getReversalsLoadingButton").addClass("d-none");
$("#getReversalsButton").removeClass("d-none");
});
}