I found the code below in a file called “jquery-1.11.3.js”, most of us know what jQuery is and so I thought it might be worth considering what this means for the Lucee dialect.
// Makes sure cloning an html5 element does not cause problems
// Where outerHTML is undefined, this still works
support.html5Clone =
document.createElement( "nav" ).cloneNode( true ).outerHTML !== "<:nav></:nav>";
I’m not sure why this code exists, but perhaps someone else does and can reassure me that there will never be a conflict between HTML and the new Lucee dialect?
This is kinda why I raised an eyebrow when I saw Lucee had actively decided to use an empty namespace.
Well: whatever namespace they use there’s a chance someone else will also use the same namespace I guess, but having no namespace at all is probably more likely to have collisions like this. Even if the collision is not a functional one - ie: the Lucee engine deals nicely with tags it doesn’t recognise - it’s a code clarity issue IMO. And it’s this very reason - code clarity - that is why tag namespacing exists in the first place.
I think it would be a better idea if .lucee tags had a specific namespace, probably lc. That’s indistinct in a sans-serif font, but it eye-parses OK in a serif one.
Unless I’m missing something essential here, Lucee’s decision for an empty namespace (whereever one would stand at about that decision) has nothing to do with the raised question about jQuery.
Yes, I can sympathise with your argument, however having a namespace uglifies the language imho, so I can totally see, too, why people would rather not having to deal with lc:output.
Did you find the jQuery library within the Lucee server code somewhere?
If not - I think there might be no issue here — nav is a clearly defined HTML5 element and I would expect there is not going to be a Lucee tag named nav.
If yes:
Where is jQ 1.11.3 used inside of Lucee and what’s its purpose? I can indeed see a potential issue coming from that end when and if a users wanted to use their own version of jQ and the libraries would potentially end up overwriting itself depending on how things are build and loaded. I have seen that with external jQ code in the past (3rd party providing a chat/IM service with a JS plugin what was built with jQ and causing conflicts with other jQ libraries). Such a situation can be dealt with though through scoping the different jQ libraries properly.
In its simplest form the question was, why does jquery use colons in the Html tag syntax outlined in my original post ( <:nav> ), I’ve not seen this syntax for html before?
No, as far as I’m aware jquery is not shipped with lucee.
I found the “issue” ( if you can call it that ) when using an in house development resource ( js/css ) manager that uses cfinclude and fails on that line when executing, not really a lucee problem if we are assuming <:nav> is not valid html right?
First of all, namespaces are not supported in the HTML5 spec (8.1.2 in the current spec), not even in what’s called “foreign” elements from the SVG or MathML specs.
I also had a look in the XHMTL 1 spec and couldn’t find any further info on the <:/nav>… syntax.
My assumption is (and in the context of checking for the ability of cloning an HTML5 element) is that on some older browsers, that line of code would in fact return the syntax with the colon (for whatever reason at this stage).
Regardless - all of this (as the jQuery code) would only be relevant when it comes to rendering in the browser anyway. Therefore — even if Lucee would have an un-namespaced nav-element as part of the language (note: not a good idea): as long as such a thing was converted into some HTML5-compliant structure for rendering I can’t see an issue here.