<!-- <script type="text/javascript">/*<![CDATA[*/ c-- ;//]]></script> -->
When I have the above line in the <head> section of a plain html page, Firefox 3.5.5 renders the trailing --> as text. If I change c-- to c- it doesn't. Any ideas what's going on here? I getting an artifact on my pages with this due to a very large script that's been crunched. I can change the statement to c-=1 and avoid the problem for now but.... I'd like to know what bit/byte is biting my a$$.
This is due to Firefox implementing SGML (on which HTML was based) comments strictly. This will only occur when the document is loaded in standards mode (i.e. there is a DOCTYPE).
The first <! starts a comment. The first -- enters a section in which > characters are allowed. The second -- (in your script) leaves the section in which > characters are allowed. The > at the end of </script> then ends the comment. The following --> is therefore no longer part of the the comment and gets rendered as text.
See http://www.howtocreate.co.uk/SGMLComments.html for a comprehensive guide to the issue.
Its also worth noting that the HTML 4 Specification says that 'authors should avoid putting two or more adjacent hyphens inside comments' and the HTML 5 Specification says comments must not 'contain two consecutive U+002D HYPHEN-MINUS characters (--)'.
The solution, as you've found, is to not include -- in the middle of a comment.
Technically you are not allowed to have double hyphen in a comment in HTML (or XML). So even if browsers "allow" if it is not valid and should fail an HTML validator.
See Comment section of HTML 4 Specification
I can't replicate this. Doesn't show up on 3.0.1.
Related
In IE11 I'm getting the error Unexpected character in comment end. Expected "-->". because the commented code contains a double dash in the class. Does anyone know how to prevent this from happening?
Example:
<!--
<div class="block--attribute"></div>
-->
From this example I'm guessing IE11 thinks the end of the comment is --a
I have reproduced the warning on my side, this is an HTML5 parser warning, this warning can occur as part of the validation that is performed during HTML parsing. These warnings don't necessarily mean a page is broken, but that the provided HTML is invalid per the HTML5 standard.
When using the comment tag, it does not support any standard attributes (such as the class attribute). More information about Standard Attributes.
To solve this warning, you could remove the class attribute, code as below:
<!--
<div ></div>
-->
I have a code that saves (html code) plus (some text) in mysql from textarea.
I then take the text from the mysql and display it under the textarea. The thing is if I save the code
<div style="color:red">Hello</div>
in mysql and then display it, I see Hello in red, but I want to see the actual
<div style="color:red">Hello</div>
to appear under the textarea. I hope you understand my problem.
so when you've grabbed the data from the database you want to actually display the html, rather than the page rendering the html?
if so just use the php function htmlentities();
You can use the xmp element, see What was the tag used for. It has been in HTML since the beginning and is supported by all browsers. Specifications frown upon it, but HTML5 CR still describes it and requires browsers to support it (though it also tells authors not to use it, but it cannot really prevent you).
Everything inside xmp is taken as such, no markup (tags or character references) is recognized there, except, for apparent reason, the end tag of the element itself, .
Otherwise xmp is rendered like pre.
When using “real XHTML”, i.e. XHTML served with an XML media type (which is rare), the special parsing rules do not apply, so xmp is treated like pre. But in “real XHTML”, you can use a CDATA section, which implies similar parsing rules. It has no special formatting, so you would probably want to wrap it inside a pre element:
<![CDATA[
This is a demo, tags will
appear literally.
<div style="color:red">Hello</div>
]]>
you can refer this ans : https://stackoverflow.com/a/16785992/3000179
If you want to do on browser level, you can follow the steps :
Replace the & character with &
Replace the < character with <
Replace the > character with >
Optionally surround your HTML sample with <pre> and/or <code>
tags.
Hope this helps.
The HTML5 specification for tag omission (http://www.w3.org/TR/html51/syntax.html#syntax-tag-omission) starts with the following two statements (emphasis mine):
An html element's start tag may be omitted if the first thing inside
the html element is not a comment.
An html element's end tag may be omitted if the html element is not
immediately followed by a comment.
Those to statements read similarly, but not the same and I am wondering if someon can offer clarification on what they mean.
The following case seems unambiguous - you can't remove the start or close tags:
<html><!-- start --> ... </html><!-- end -->
But what about when whitespace is introduced into the mix. Can the start tag for html be eliminated in the following case?
<html>
<!-- comment after whitespace -->
...
Can the end tag be eliminated in a similar scenario?
...
</html>
<!-- comment after whitespace -->
Some of the other rules make specific mention of whitespace characters which leads me to believe that they should be taken into account. Most of the rules say "...immediately followed by..." which is different than the first bullet point listed.
The important factor here is that the phrases first thing inside and immediately following are talking about nodes i.e. the DOM, not tags or other markup, so the distinction it is making is about whether the node is a child (first thing inside) or a following sibling (immediately following).
As far as spaces go:
An html element's start tag may be omitted if the first thing inside
the html element is not a comment.
The first thing inside an html element cannot be a space character because at that point in the parser algorithm, space character tokens are discarded and not added to the DOM.
An html element's end tag may be omitted if the html element is not
immediately followed by a comment.
Space characters, regardless of whether they appear just before or just after the </html> tag, end up inside the html element (in fact, also inside the body element), so the comment will be immediately following the html element regardless of whether there are spaces in between in the markup.
In html, space between tags doesn't matter. <html> <head> and <html><head> are the same thing to the browser. In content (e.g. between words inside a span/p tag) it's rendered up by the browser, but when you want to use space between elements (as a design resource) you should use  .
So, as I see, immediately followed by doesn't mean "the next character" but "the first thing after the place that end tag was supposed to be, no matter how many spaces between them.
Then, removing html tags in both cases would invalidate the html, because no matter how many spaces are betweeen the place </html> was supposed to be and the comment.
edit: I think they were trying to express the same thing by using another words and avoid being repetitive, but ended up being confuse;
The rules about tag omission are somewhat misleading in that for the most part they're not actually saying when tags can be omitted, but rather how they should be interpreted when they are omitted. Take, for example, the following document:
<!DOCTYPE html><!-- A comment --><title>A title</title>
This is a valid HTML5: you can run it through the W3C validator yourself. But the tag omission rules clearly state that
[a]n html element's start tag may be omitted if the first thing inside the html element is not a comment.
How do we reconcile this? The answer is that these are disambiguation rules. Because an html element's start tag may not be omitted if the first thing inside it is a comment, we are free to assume when parsing that the comment is not the first thing inside the html element. Similarly, the tag omission rules state that
[a] body element's start tag may be omitted if the element is empty, or if the first thing inside the body element is not a space character or a comment [...]
So we are free to assume that the comment is also not the first thing inside the body element. So in fact this document can be unambiguously parsed as equivalent to
<!DOCTYPE html><!-- A comment --><html><head><title>A title</title></head><body></body></html>
The parser algorithm for HTML5 specifies that if we are in the before html insertion mode, which is the state the parser transitions to after seeing <!DOCTYPE html>, and we see
A character token that is one of U+0009 CHARACTER TABULATION, "LF" (U+000A), "FF" (U+000C), "CR" (U+000D), or U+0020 SPACE
then we are to "Ignore the token." If on the other hand we see a comment token, then we are to
Insert a comment as the last child of the Document object.
It's not until we see some other kind of tag that we emit an html element. So we should expect this behavior not to be affected by whitespace, and indeed both Firefox 54 and Chrome 60 interpret the document
<!DOCTYPE html>
<!-- A comment -->
<title>A title</title>
identically to
<!DOCTYPE html><!-- A comment --><title>A title</title>
That is, both of them are treated like
<!DOCTYPE html><!-- A comment --><html><head><title>A title</title></head><body></body></html>
Line 10, Column 43: Bad value FRSH Studio for attribute href on element link: Whitespace in path component. Use %20 in place of spaces. <link rel="pingback" href="FRSH Studio" />
--- It is my understanding that this is pulled from my settings in Wordpress. When I change the setting to include the %, I'm given an error stating that "Path component contains a percent sign that is not followed by two hexadecimal digits." How do I fix this?
Line 146, Column 7: End tag for body seen, but there were unclosed elements. </body>
--- I believe this is referring to <div id="container">...
Line 54, Column 20: Unclosed element div. <div id="container">
--- When I close the container using </div><!-- end container --> in the footer, I'm told that it is a stray tag. Where should </div><!-- end container --> be?
Not sure why this was sent away from Wordpress Stackexchange. The site validates as HTML. It is only when validating the site, which is Wordpress, using the URI via w3c's validator that these errors arise.
Put the full code inside the HTML Tidy and make it valid. Use this: http://infohound.net/tidy/
HTML Tidy is a tool for checking and cleaning up HTML source files. It is especially useful for finding and correcting errors in deeply nested HTML, or for making grotesque code legible once more.
This online version enables you use it without installing the client tool on your PC.
The "stray tag" error may be due to the fact that the page is being parsed as XHTML, where every opening tag (e.g. <!-- end container -->) requires a closing tag.
The best HTML validator is here:
http://validator.w3.org/
That will offer an option to clean up with HTML Tidy as others have mentioned.
1) The href has to be a valid link.
<link rel="pingback" href="http://frshstudio.com" />
2/3) Perhaps you have closed it in the wrong place?
Can you please post code?
Your site appears to be generating bad HTML pages.
1) The value for "href" should be a URL.
2) If you have a "div" start tag, then there needs to be a "div" end tag as well. This may be missing.
3) Would need to see the entire source to be helpful.
As someone suggested, you can use http://validator.w3.org/. Another validator (for Windows so it's offline and it does a lot more) is CSE HTML Validator at http://www.htmlvalidator.com/
Instead of
<!--
,
I used
<!-
...and it is working.
How?
It's not actually working - it's just interpreting it as an actual tag, and then throwing that tag out as invalid.
<!- foo bar -->
is treated as a tag, <!-foo bar--> which obviously isn't a standard HTML tag, and thus is ignored.
Try this, and you'll see it's not truly working as a comment:
<!- >foo bar-->
Modern browser parsers (i.e. those that use the HTML5 parsing algorithm) work like this. If they are expecting text or a new tag next, and they see <! then they check the next few characters to see if they are -- or DOCTYPE or, if they are processing embedded SVG or MathML, [CDATA[. (See http://dev.w3.org/html5/spec/tokenization.html#markup-declaration-open-state)
If, as in the case of <!- foo, none of these match then the parser enters the bogus comment state where all the characters following, up to the next >, are read and and converted into a comment to be put into the DOM.
Hence the behaviour you see with <!- working like a comment start. Note that such behaviour is "repair" behaviour for broken markup and it's wise not to rely on it.
You can see how such markup forms a DOM here: Live DOM Viewer
Also note that this is different to what #Amber says. It is not treated as a tag in any meaningful sense, and it is certainly not ignored.