To close a tag or not to close a tag

[modius]

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

@agentK

@kliakos

@21Solutions

I don’t see what xml compliance have to do with anything. as soon as you write:

<cfset name = “Lucee”>

instead of

<cfset name = “Lucee”/>

your markup is not xml compliant.

Now that you mentioned the closing slash, what a mess it is. It should either be required, or not and throw an error when typed. Having it work both ways is confusing. Not to mention how much it confuses the editors. But that’s another topic I think.

That is actually a good idea. Either allow it or not allow it, but not the current mish-mash of whatever one feels like today.

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

<:hornyness>
  <horn type="rhino">
  <horn type="narwhal">
  <horn type="unicorn">
</:hornyness>

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?

[justincarter]

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

[kliakos]

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.

[justincarter]

@kliakos

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

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

[agentK]

@modius

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?

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

[kliakos]

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.

[micstriit]

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.
body-content:

• 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

[agentK]

@micstriit

does anybody remember “xhtml”? that was exactly the idea behind this, write more strict and proper code, enforce exactly this.

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.

[micstriit]

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

[agentK]

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.

[adam_cameron]

@agentK

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.

–
Adam

(*) yeah, I know you do Dom