To close a tag or not to close a tag

Continuing the discussion from Lucee Lang Namespace, why and if so what?:

You do need to close a tag in many instances. For a custom tag with child tags you might have:

  <horn type="rhino">
  <horn type="narwhal">
  <horn type="unicorn">

But the same tag might accept an attribute instead:

<:hornyness horns=aHorns />

In the latter instance we need to indicate that the tag doesn’t enclose anything.

I’d be all for removing the closing / (slash) in tags that do not enclose anything.

For example:

<:argument name="unicornid" required=true>
<:set var rainbowLevel = 5>
<:set var rainbowSpectrum = "warm">

But should we be really enforcing this by not allowing it to compile, especially if the compiler is quite happy with the current status quo?


A tag should be closed when it serves a functional purpose, so having the compiler enforce trailing slashes that serve no functional purpose would be very undesirable :smile:

1 Like

Actually the opposite: should we throw a compile error for non necessary trailing slash?

I wouldn’t take this to custom tags, only built in tags. Custom tags can be customized to both have or not have body. Bad practice? Yes. Do I do it? Yes. :slight_smile:

I wouldn’t take that away from the people who like it… and it’s perhaps unnecessary engineering effort to try to enforce it :smile:

1 Like

Yes, because it promotes a strict syntax and a clean language design and not the mish-mash we have now.

The fact that the compiler allows it now is not a criteria imho because LuceeLang will change a lot of things the currently compile fine :slight_smile:

Someone could point here that there is the bloody optional semi colon. And this is something that javascript allows as a concept, so it is a strong point. Also html allows for optional closing , let’s say at <br> & <br/> for example.

does anybody remember “xhtml”? that was exactly the idea behind this, write more strict and proper code, enforce exactly this.
But that was no sucess at all, we should learn from history, i think enforce this is not a good idea.

technically this is not a problem at all, this is a simple configuration in the the “tag library description”, we have 3 different options for this you can configure.

  • none (most tag have this, this tag can have no body, so it does not matter if you define a body or not*, if there is one it is skipped by the compiler)
  • optinal (having a body is optional, in this category are tags like file or http)
  • required (tag needs to have a body, in this category are tags like catch,finally,if,interface,component …)

-* this <cfset x=1/> and <cfset x=1></cfset> is the same

add a 4th type would not be a big deal technically

With the difference that XHTML failed because x different browser vendors couldn’t get their shit together and they were fighting a growing wave of web developers whose WYSIWYG editors at the time couldn’t be arsed to produce correct XHTML code etc.

In this case it’s very different. There’s one runtime/compiler that’s in full control - this is not like the XHTML situation.

in my opinion it is, in my opinion the sucsess of html was that it was very easy and forgiving and people don’t liked if you took that away from them.
But if that comparsion don’t hold in your opinion let’s forget it, i don’t want to start a discussion about xhtml :wink:

1 Like

Essentially I don’t think XHTML holds, correct.

So - your concern is essentially that your’re in general against more strict language behaviour?

There’s always a give and take between strict and more loose. I find a strict language behaviour is usually preferable because there’s clarity on what a language allows or doesn’t.

Agreed there’s areas where flexibility has merit as it brings something to the table. That’s cool.

In other areas it just adds uncertainty (albeit not a lot).

I don’t think there’s any gain in allowing both was of closing a tag which doesn’t have a long-form closing tag requirement.

In my world (in which only I reside, I know) I think putting the closing “/” in where it’s not necessary is an odd practice (full opinion here: “/>”). However I acknowledge other people have the reverse opinion, and arguing it is about as sensible as arguing “tabs or spaces”. The one thing about the “tabs vs spaces” argument though is that no one advocates using a mix of both (*). There’s perhaps a lesson to be learned there.


(*) yeah, I know you do Dom :wink: