Mark some Javascript blocks as "special" - javascript

For some complicated reason, I need to mark some Javascript as "special", like this:
<script type="text/javascript" someattribute="special">
var special = "I'm special!";
</script>
<script type="text/javascript" someattribute="special" src="special.js">
</script>
Is it possible to do this in way that complies with XHTML standards? According to http://www.w3schools.com/tags/tag_script.asp, all attributes for the script tag have very specific functions. But is there a workaround?
The idea is to pick up the tags as XML elements and put them in anther page, at server level, before it gets to the browser, so I need the special mark in the actual XML of the page. Adding it once the page has loaded, at browser level, using Javascript, will not work.
Any ideas?
Edit:
For the sake of standards-compliance, I can't use HTML5. The whole system I'm trying to be compliant with is XHTML 1.0.
Now that I've had time to think about it, I think that adding a GET variable or an anchor in the src of the script might just do the trick. For example, instead of the previous example, do
<script type="text/javascript" src="special.js?special"></script>
or
<script type="text/javascript" src="special.js#special"></script>
I'll try it now.

If you're using HTML5, you can do this:
<script data-special='true'>
</script>
and it'll validate. However, other than failing validation, you can get away with putting arbitrary attributes on tags and it'll generally work. Using the "data-" HTML5 convention is a safe way to go because you've got a 0% chance of accidentally triggering some weird behavior.
Note that with HTML5 you don't need the "type" attribute, and in fact it's deprecated in trendy Javascript circles.

Use data-* attributes.... They are standards-compliant:
<script data-foo="bar">

With XHTML you are able to create your own DTD and with your own DTD you can easily add an extra attribute to the script tag. However... since you probably want to use this in a real life website this won't work because Internet Explorer does not support that.
So I think these are your choices:
wrap a tag around it to mark it as special (completely standards compliant, works in every browser, but might not work for your check)
adhere to the standards and create your own DTD which will somewhat break IE support
ignore the standards and just add some attribute (noone besides the W3 validator will really care)
If you pick the last option, I suggest using the id attribute. Which, although not supported for script tags, is supported in both html and xhtml in general so browsers won't care too much about it and most validators won't care either.

I'm looking back a this post a long time later. This is just to say that what I wrote in my edit did work and was standards-compliant.

Related

Is placing javascript directly on HTML document deprecated?

I am shocked to read the following from Quirksmode:
Deprecated: Direct JavaScripts
Do not use direct JavaScripts for the reasons explained in section 2C
of the book. This section is only maintained for historical reasons.
The simplest method is to place your scripts directly in the page. How
to place
<script language="javascript" type="text/javascript">
<!--
script goes here
// -->
</script>
Based on my understanding reading the article, javascripts are to be included using the src attribute on <script> tags instead. I don't have the book and can't find further references online that says this. Does anyone know whether this is correct or did I misinterpret what it is trying to say?
No HTML specification marks inline JavaScript as deprecated or obsolete.
It is widely regarded as being less than best practise though.
PPK means that the section itself is deprecated. The advice presented there was generally accepted and relevant at the time of publication, but it no longer aligns with current markup languages and best practices:
The language attribute has been deprecated since HTML 4.01.
In HTML5, the default value of the type attribute is text/javascript—thus, it can often be discarded.
The HTML comments (<!-- and -->) surrounding the script itself are a workaround for the IE 2 and Netscape 1 generation of browsers, and have not been required for nearly 20 years.
Later he advises that you place scripts in the head of your document. This made sense in the days of dial-up, but nowadays it is recommended that outside of a few specific circumstances (e.g. Modernizr, html5shiv) you should place scripts at the end of your document body to prevent them from blocking rendering and parallel downloads.
More current advice
Avoid inlining scripts in general for better maintainability and cacheability. You are still allowed to inline scripts, and it may make sense if:
the script is dynamically generated for just that page; or
the script is very small, and you can demonstrate a measurable and worthwhile improvement in performance due to avoiding the additional HTTP request.
Unless otherwise necessary, use the following syntax for inline JS.
HTML5:
<script>
// ...
</script>
HTML 4.01:
<script type="text/javascript">
// ...
</script>
XHTML5:
<script>
//<![CDATA[
// ...
//]]>
</script>
XHTML 1.x:
<script type="text/javascript">
//<![CDATA[
// ...
//]]>
</script>
It is not deprecated, and it is still used widely.
If you look at this question: https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting it is very well explained why its a bad idea.
The biggest problem i have with it, is that it makes your html pages look stuffed. If you for example have a bit of javascript inline, and a bit of javascript in another file, it is pretty hard to find the right code if you need to change it.
Same goes for inline css. It makes your html files harder to read and understand.
script tag is not deprecated.
The relevant section is called "Deprecated: Direct JavaScripts", and
the note referes to the section's title. Must read:
"Do not use "Direct JavaScripts" recommendations for tag
syntax. This section is only maintained for historical reasons."
the section is deprecated
http://www.peachpit.com/articles/article.aspx?p=1338952&seqNum=3

Most common use cases for the HTML5 shiv/shim JS script

I often see people suggesting I include the HTML5 shiv JS script to make HTML5 work in Internet Explorer but I can't find a clear explanation for the most common use cases this will cover.
Might someone give common scenarios of why one would need this JS script?
Also, does it need to be in the <head> or can I put it with the rest of my JS at the bottom of the <body> tag such that it doesn't block the UI thread?
Internet Explorer prior to version 9 refuses to apply any CSS styling to HTML elements it does not recognise, this includes the new elements brought in by HTML5. By creating the elements through the JavaScript DOM it suddenly and magically realises that the elements should indeed be styled.
You can write a naive and simple script that loops over an array of HTML5 tag names you want calling document.createElement(tagName). This may work for you in most cases, however, printing HTML5 pages in IE and adding HTML5 content through innerHTML will cause you further problems at which point it would be an idea to switch to the shiv.
HTML5 shiv can, to my best knowledge, be placed in the head or after the body tag if you prefer. I would recommend using conditional comments so that only IE loads it.

Using JS to write a noscript tag

Is there any practical reason why you would write out a <noscript> tag with JavaScript's document.write()? Our ad department has been doing this for years and still does it after I've pointed it out. I'm 99% certain that this is due to an ancient ad template written by someone who didn't know what he was doing and no one has thought to change it because, "why fix what ain't broke?" Or maybe someone is reading their "best practices" wrong ("Always include a alternative for browsers that have JS disabled"). Or maybe there's a really good reason I don't know about.
The only conceivable thing I can think of is that you could use it to modify the DOM without it appearing visible on the page and maybe use that content like a template for later use, but this seems pretty far-fetched.
(edit)
The tag in this case contains a standard <img src="/path/to/image" />. Because this is what the original, non-dynamic ad tag would have looked like, this makes me think this is just copy-pasted garbage.
The other thing I should say is that the reason I'm not 100% sure this is an oversite is because of the recent pattern of putting html templates inside <script type="text/x-my-custom-template">...</script>. I'm sceptical that someone on our end would have come up with this on their own, but it could have been a standard ad practice by someone with unusual cleverness.
Is there any practical reason why you would write out a <noscript> tag with JavaScript's document.write()
Nope. The two (<script> and <noscript>) are mutually exclusive. It's like writing a piece of code like this:
if (true && false) {
// do something important
}
If JavaScript is enabled, the browser ignores the <noscript> tag. On the other hand, if JavaScript is disabled, the <noscript> tag will never be written, because the <script> tag is ignored.
This is used for bot detection / fingerprinting.
For example if I use
document.write('<script src='...'>...</script><noscript><img>....</noscript>');
Chrome 55+ blocks not same origin scripts written from document.write(). This means the above <noscript> actually will run on certain/newer versions of chrome despite coming from a "script".
The assumed purpose is if the bot is pretending to be for example (via spoofing its user agent) a specific version of chrome, and the script is not blocked, it would point to the fact that its not really chrome (bot).
You can add child node in a specific html tags.
var noscript = document.createElement('noscript')
var iframe = document.createElement('iframe')
iframe.setAttribute('src', "<your source>")
iframe.setAttribute("height", "0")
iframe.setAttribute("width", "0")
iframe.setAttribute("style", "display:none;visibility:hidden")
noscript.appendChild(iframe)
document.body.appendChild(noscript)

Custom Tags and Javascript

I am building a web application which is supposed to be (on the development level) highly standardized.
To accomplish this i want to use custom namespace tags which in the sourse code appear as they do, but are modified by javascript depending on what they are.
For example:
<script type="text/javascript">
<!--
alert($('sy\\:icon').attr('location'));
//-->
</script>
<sy:icon id="icon1" location="/path/to/icon"></sy:icon>
Now i have tested this and it does work. What would happen in this example is the entire tag would be replaced by javascript with one or more tags and styles which are valid in html.
My only concern is how different browsers of various versions would respond to an invalid tag, even though it is about to be immediately replaced.
For the record, i am aware that using something like a <div> with a specific class for reference is the normal approach, however using a custom tag would both save space in the source code, and look a lot nicer in my opinion, im just concerned with the implications, if any.
You should declare your custom namespace in the <html> tag as described here. That blog author notes that it's cross-compatible between the various browsers, with IE support back to IE7, so you should be fine.

Generating/selecting non-standard HTML tags with jQuery, a good idea?

I've noticed that jQuery can create, and access non-existent/non-standard HTML tags. For example,
$('body').append('<fake></fake>').html('blah');
var foo = $('fake').html(); // foo === 'blah'
Will this break in some kind of validation? Is it a bad idea, or are there times this is useful? The main question is, although it can be done, should it be done?
Thanks in advance!
You can use non-standard HTML tags and most of the browsers should work fine, that's why you can use HTML5 tags in browsers that don't recognize them and all you need to do is tell them how to style them (particularly which tags are display: block). But I wouldn't recommend doing it for two reasons: first it breaks validation, and second you may use some tag that will later get added to HTML and suddenly your page stops working in newer browsers.
The biggest issue I see with this is that if you create a tag that's useful to you, who's to say it won't someday become standard? If that happens it may end up playing a role or get styles that you don't anticipate, breaking your code.
The rules of HTML do say that if manipulated through script the result should be valid both before and after the manipulation.
Validation is a means to an end, so if it works for you in some way, then I wouldn't worry too much about it. That said, I wouldn't do it to "sneak" past validation while using something like facebook's <fb:fan /> element - I'd just suck it up and admit the code wasn't valid.
HTML as such allows you to use any markup you like. Browsers may react differently to unknown tags (and don't they to known ones, too?), but the general bottom line is that they ignore unknown tags and try to render their contents instead.
So technically, nothing is stopping you from using <fake> elements (compare what IE7 would do with an HTML5 page and the new tags defined there). HTML standardization has always been an after-the-fact process. Browser vendors invented tags and at some point the line was drawn and it was called HTMLx.
The real question is, if you positively must do it. And if you care whether the W3C validator likes your document or not. Or if you care whether your fellow programmers like your document or not.
If you can do the same and stay within the standard, it's not worth the hassle.
There's really no reason to do something like this. The better way is to use classes like
<p class = "my_class">
And then do something like
$('p.my_class').html('bah');
Edit:
The main reason that it's bad to use fake tags is because it makes your HTML invalid and could screw up the rendering of your page on certain browsers since they don't know how to treat the tag you've created (though most would treat it as some kind of DIV).
That's the main reason this isn't good, it just breaks standards and leads to confusing code that is difficult to maintain because you have to explain what your custom tags are for.
If you were really determined to use custom tags, you could make your web page a valid XML file and then use XSLT to transform the XML into valid HTML. But in this case, I'd just stick with classes.

Categories