How can I write this script correctly on ionic?:
<script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?key=xxx&libraries=places"></script>
Does not accept the '&'
HTML has few special characters, but when they appear in “content” they should be encoded using an entity reference:
& as &
< as <
Etc.
It turns out & is the special character that introduces one of those, so that explains why some parsers trip up when they see them unencoded in URLs.
Browsers are lenient so when they encounter an ampersand in a URL they know how to fix it; which I suppose has it’s pros and cons.
Related
Such as:
<img style="width:500px;height:150px;background:url(data:image/png;base64,BLAH)" />
The application I have displays an authorization letter, and then displays a canvas. The canvas allows touch/mouse events and the user is able to sign their name to it. Then the HTML and the signature are saved. The customer is requesting that these be saved to one single file so that they don't get mismatched signature PNG files and HTML text files in the future.
So, while I don't like the look of this approach, it seems to work fine in Chrome and even IE, and it solves the customers request of only having to store one single file with the signed authorization.
My question is - Is this legal HTML or is Chrome being nice to me?
Quote OP:
<img style="width:500px;height:150px;background:url(data:image/png;base64,BLAH)" />
"My question is - Is this legal HTML?"
No. According to the W3C HTML spec, the src attribute "must be present".
Why not change your img into a div?
<div style="width:500px;height:150px;background:url(data:image/png;base64,BLAH)"></div>
In general, any question regarding HTML validity should be put through the online validator before coming to SO: http://validator.w3.org/
The HTML is not valid. But if you dig a bit you'll find references to the Data URI scheme in the HTML4 spec:
<OBJECT id="clock1"
classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
data="data:application/x-oleobject;base64, ...base64 data...">
A clock.
</OBJECT>
... so the problem is not the data: uri. As for whether this is a chrome-only thing, the Wikipedia article on the Data URI Scheme contains a section devoted to browser support.
It looks like the CSS is not valid either. The following fails validation on the w3c CSS validator:
.wtv {
background:url(data:image/png;base64,BLAH);
color:red;
}
The validator gives the following error:
Value Error : background url(data:image/png;base64,BLAH) is an incorrect URL url(data:image/png;base64,BLAH)
So what you're doing works, but according to the letter of the law, it is not valid.
It is fine in my opinion. Having actual base64 image data in a CSS declaration is fine. Interesting approach if the output of the process is just an HTML file.
In this case the question would be if this is valid CSS. However, it can be used in both and should be valid. But be careful, not all browsers support it.
Wikipedia: Data URI scheme
I have the problem that my installed FCKEditor 3.3.1 changes all & to &.
I am posting lots of links in my posts and this makes them invalid. Where can I define that & ist NOT replaced with &?
Thanks :-)
No, you can't. FCKEditor does the right thing.
There is no situation where a standalone & in HTML is not an error. The ampersand always has to be encoded as & - unless it is the start of an escape sequence itself (like in <).
It is a misconception that the & in the HTML source code would make a link invalid. It does not. For HTML to be valid, all data in it must be HTML-escaped. "Data" means both text (in-between tags) and attribute values (like href). When the HTML source is then parsed, the parser will automatically HTML-unescape all data and & will become & again in the DOM. Do not let the fact that many browsers accept an unescaped ampersand deceive you. It is wrong nevertheless (and FCKEditor just tries to deliver valid HTML).
See the custom setting in the fckconfig.js file for FCKeditor.
FCKConfig.ForceSimpleAmpersand = true ;
Tomalak is correct about how it should be presented but I'm just pointing out that there is a configuration option in FCKeditor, in case you need to "break the rules". There are situations where this is necessary. Rendering the ampersand as a true HTML entity (&) does not work in some HTML mail clients, which rarely adhere to HTML standards properly anyway. And you may need to force the plain ampersand if you have an additional filter that will convert it to an HTML entity further along your process.
Say that you have a XHTML document in English but it has accented characters (e.g. meta name="author" content="José"). Let's say you have no control over the HTTP headers.
Should the characters be replaced for their corresponding named entities (e.g. á, etc)?
Should the xml:lang attribute be set to English?
I know I can check the W3C recommendation but I am asking more from a practical point of view.
Should the characters be replaced for their corresponding named entities (e.g. á, etc)?
Since you can't control the HTTP headers (and thus the declared character encoding) you should encode everything using ASCII (since it is a safe subset of just about everything).
This will require that you use entities for anything that isn't in ASCII. Named ones are preferred (as they are easier for people editing the HTML to handle) but not required.
Should the doc type and the xml:lang attribute be set to English?
The EN in the Doctype is a reference to the language that the comments in the DTD are written in. The HTML 3.x / 4.x and XHTML 1.x Doctypes must always use EN.
The lang attribute (and additionally the xml:lang attribute) should specify the language that the content is written in. If that is English, then it should be English.
Looks like I kind of missed the point, so here's the answer, and following up is the rant on encodings.
xml:lang="en" doesn't forbid you from using any character you want, it's only metadata for use by browser, search engines, accessibility software, etc. If you page is in English, then go ahead, write it.
As of diacritics, HTML supports both directly writing the character or writing the entity, both in attributes and in text nodes (and possibly in node names too, but I'm not sure; anyways, that's not going to happen with HTML). However, it's easier in my opinion to use UTF-8 everywhere than to escape entities; and there are like 4 ways to set the encoding of a page, so it would be hard to believe that, in a practical case, you can't do it.
From a practical point of view, being a French speaker with diacritics in my first name, I find it is a MAJOR annoyance (and markdown won't let me stress MAJOR enough) when websites don't support accentuated letters. Even if you set xml:lang to English, it's not going to solve this problem.
I recommend that you use UTF-8 because it is backwards-compatible with ASCII and it can encode every UCS character. If you have no control over the HTTP headers, you still have two options: the XML declaration, and the meta tag.
If I recall correctly, if you get an XML document, the encoding "attribute" in the <?xml?> tag has precedence. This is your first solution, but it's probably not supported by legacy browsers.
<?xml encoding="UTF-8"?>
Your other option, and by far better supported, is to use the meta tag to tell the browser about the encoding. In HTML4-, you can use this:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
In HTML5+, you can use this simpler form:
<meta charset="UTF-8">
Since you use XHTML, you'll want to self-close these (and use the appropriate application/xhtml+xml MIME type in the Content-Type <meta> tag).
Is it possible to pass w3 xhtml strict validation and still use google analytic code on my webpage?
Yes. If the specific code were to contain an &, >, or < (it doesn't), you would have to wrap the JavaScript in <script type="text/javascript">//<![CDATA[ and //]]></script> (ampersands are normally reserved for XML entities, and the others are for tags).
If you serve your web page using the XHTML MIME type application/xhtml+xml rather than the default HTML MIME type text/html, problems may result then. Serving pages under the latter MIME type only causes reduced cross-browser compatibilty and prevents many scripts from working. Though in the long term, I would focus on HTML5 compliance rather than XHTML compliance – that's the way further development of web standards is heading.
According to old AntiXss article on MSDN AntiXss.UrlEncode is used to encode link href (Untrusted-input in the following example):
Click Here!
My understanding was, that UrlEncode should be used only when setting something to URL, like when setting document.location with JS. So why don't I use HtmlAttributeEncode in the previous example to encode [Untrusted-input]? On the other hand is there a security flaw if I use UrlEncode to encode HTML attributes like in the above sample?
Url Encode encodes URL parameters for use in anchor tags.
Html Attribute encode encodes things for use in general HTML attributes.
Both encoding types vary - unsafe characters in HTML attribute encoding will be turned into a &xxx; form, in URL encoding they'll turn into %xxx. Whilst it's probably unlikely getting it wrong would cause a security problem your data wouldn't be properly rendered in the browser, or understood in a request.
(Indeed Url encoding is probably going to change because of an incompatibility with older browsers, and HTML Encoding will change in the next CTP drop to allow for safe listing of particular Unicode ranges).