What's in YOUR script tags?


#5191 (In Topic #1172)
Standard member
Joe is in the usergroup ‘Honoured member’
So recently I've been trying to make my website W3C standards compliant. It seems to be a never ending battle as I'm always adding, removing, and editing content/HTML. Unfortunately the thought of being standards compliant always comes to mind AFTER making numerous edits and customizations but never before or during.

One thing I've noticed with the standards checker within Composr, is its strictness for script tags and the content inside them. I contemplated for a bit what is truly considered "valid" -- when to enclose content in CDATA tags, why the checker appears to "complain" about the slashes before those tags, why should we use noscript tags, and another question I'm asking, "should we be commenting out the content between the script tags?" (I've recently learned W3.org suggests doing this; more on that later…)

I've also noticed that most (but not all) content between these script tags, namely the ones pre-programmed into the default templates, are encapsulated with CDATA tags. This made me include them with every script tag I added to the templates; I assumed it was required entirely. I'm not very knowledgeable when it comes to CDATA, so I decided to do some research on the subject. And we all know how sources on the internet are -- too many people giving just their personal opinion instead of explaining what's truly considered "valid".

From what I understand and as far as I can tell, the use of the CDATA tags are required to ensure that code is parsed correctly and not mistaken as HTML. Since Javascript uses some of the same syntax as HTML (like the ampersand symbol), you'd apparently want to use these tags in a situation like this so your JS code isn't mistaken as HTML markup. Some code within Composr, though it doesn't contain any ampersands, still uses the CDATA tags. On the flipside, there are some areas that don't even have them (but it's possible I've removed them myself so I cannot say with any certainty).

Even though the Composr web-standards compliance checker doesn't show an error about the slashes used prior to opening the CDATA tags, it does however highlight the first slash in red. So what's this mean? Are we only supposed to have one slash here?

Composr said

(X)HTML: Script tags must contain // -->-style end comments (and appropriate start comments). In fact, if this is XHTML they should not use comments like this at all, but rather a <[CDATA[ … ]]> wrapper

So, does this mean we aren't supposed to be using the slashes at all?

Here's something else Composr harasses me about:
Manual check: The < noscript > tag is not given – perhaps it should be
I didn't even know this tag existed to be honest. But I like to learn new things so I researched this one too -- we're supposed to use this as a placeholder or alternative to users who do not have script-enabled browsers. Don't most newer modern browsers have this anyway? When should we be obligated to use this tag? And, since Composr doesn't offer these "alternatives" in most areas, should I just display a message to the user to "get with the times" and update their browser?

Lastly, I found an interesting tip on W3.org (I mentioned a little about this in the beginning of my post):

W3.org said

Tip: It is also a good practice to use the comment tag to "hide" scripts from browsers without support for client-side scripts (so they don't show them as plain text)

Yet, I've never heard of this, nor does Composr even implement this into its scripts. So, is it a good rule of thumb, or should I not bother changing dozens of templates to conform with this tip? By the way, on a side note, W3 also suggests using two slashes right before closing out the commented script code, to avoid JS executing the --> tag, like so:


< script >
function displayMsg() {
    alert("Hello World!")
</ script >
Online now: No Back to the top


Item has a rating of 5 (Liked by Adam)
Site director
Chris Graham is in the usergroup ‘Administrators’
I wouldn't worry too much about it. Consider validation a tool to help you catch unintentional errors, such as non-closed tags, or when you don't realise stuff has been deprecated.

Rules regarding HTML script tag parsing changed with HTML5. Part of your problem is your seeing advice that is in some ways out-dated, or at least doesn't reflect what people actually now do. Also honestly a lot of people who write about markup are kind of ideologues and not very practical. Stuff on w3.org will be out-dated as nobody is really being paid to go back over it to keep it updated, and the people who were originally responsible for it are at different stages in their career.

For XHTML4 the CDATA stuff was needed. The "//" comments were needed so the CDATA stuff was compatible with HTML4 (as CDATA wasn't commonly supported in non-XML HTML).

HTML5 and XHTML5 defined the script tag as implicitly CDATA, so you no longer needed to compare it.

Composr's inbuilt validator isn't a strict-standards/grammar validator, but a practical tool based on what Composr thinks are best practices. Those are also subject to change, and change is reevaluated between major Composr releases (not within maintenance times). I think in v11 Salman and I decided to remove the CDATA stuff, to reflect all browsers now supporting HTML5.

The mood regarding validation in general flipped when HTML5 came out. Pre-HTML5 loud people were predominantly prescriptionists, insisting on getting perfect validation as a mark of quality. Google basically headed the HTML5 effort and they were pragmatists, focusing on standardising how to deal with bad markup and simplifying the language.

google.com - 21 errors
amazon.com - 121 errors
microsoft.com - 115 errors

These error counts reflect current thinking.

I consider validation much more strictly because I'm trying to get the defaults as perfect as possible and use validation as a good bug-catching method across the code-base (all the templates are validated by automatic tests, using our inbuilt validator).

Regarding 'noscript' - I wouldn't worry much about it, honestly none of the big web companies are doing so. However, it's a part of WCAG (accessibility guidelines). At least, the version 1 of the guidelines which the validator was coded 2. Version 2 of WCAG is much more vague about what to do. Even blind users have working JavaScript. Some users with more severe disabilities could have issues, e.g. someone who is blind and deaf and using a primitive braille reader. So interpret what we're saying as something like "is this script code doing something that is inaccessible to some people and needs a plain-text equivalent". And being brutally honest, you could spend 100% of your time making your website accessible, as it's a never-ending task with diminishing returns - focus on what your real users need and what you can reasonablly do.

Regarding ampersands - if you see them in script tags it's because the script code is itself putting out HTML. E.g. foo.innerHTML = 'a &amp; b'; – so the HTML it's putting out has to be properly escaped. The script code itself should not be escaped using HTML entities.

however highlight the first slash in red

That's not what I'm seeing. It must be something more specific.

Screen Shot 2018-10-27 at 12.05.22 PM.png
Maybe our use of red to highlight a 'manual check' is a bit harsh. I'll add a tracker issue to reconsider that.

Become a fan of Composr on Facebook or add me as a friend. Add me on on Twitter. Follow me on Minds (where I am most active). Support me on Patreon

Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about Composr whenever you see the opportunity or support me on Patreon.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying Composr on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Online now: No Back to the top
1 guest and 0 members have just viewed this.


Users online:

Manu, gabriel58, babu, MVLipwig, bobmiers, Vaiva, mytracker

Forum statistics:
  • 1,252 topics, 5,779 posts, 6,943 members
  • Our newest member is godrejahiri
Back to Top