[nitpicking] html syntax considers some optional closing tags as mandatory

[olaf-k]

</li> and </p> are the ones I noticed since I usually never use them.
Would be nice to not enforce their use.

[PK1A]

This was partially handled via 917a580. I'm afraid that this is the best we can do as we've got our own HTML parsing semantic and it will always be de-synchronized with what browsers do - currently browsers are much more permissive and don't have unified parser. What I mean here is that we've got HTML spec but browsers will do their own thing anyway...

Now - the most important part - I was under the impression that the strict parsing of #space was actually a feature / selling point, no? If so we should, IMO, stick with what is described in the HTML spec and for now the only elements that don't need closing (so-called void elements) are: area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track, wbr.

[olaf-k]

This is not exactly the same issue as these are not void elements. The HTML spec actually says their closing tags are optional (and I've never used them until hashspace forced me to :)

[olaf-k]

For reference/fun/scaring ourselves with the compiler code, the complete list of optional tags is here: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

[jakub-g]

http://www.w3.org/TR/2013/CR-html5-20130806/syntax.html#optional-tags

We don't want to implement all this logic, do we? :)

I'm omitting certain closing tags when I'm writing a one-off HTML files for testing. Having said that, I think it's not a good practice in general and IMO it should be avoided in production code.

It's the same thing like not putting braces around if-else

if (foo) 
     foo();
else
     bar();

Then comes a new guy and changes this to:

if (foo) 
     foo();
else
     bar();
     bar2(); // FAIL!

I think it's good that compiler doesn't allow people to shoot their feet :)

[benouat]

It's something that we might consider to be better than competition ! 😃

https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md#html-dialect
They also describe the topic, but do not handle it for now

[olaf-k]

@jakub-g

We don't want to implement all this logic, do we? :)

Well I do, at least for those I mentioned, otherwise I wouldn't have opened this.

I think it's not a good practice in general

Coding style is a matter of opinion if not, sometimes, religion. I would refrain from such definitive statements in the matter :)

[benouat]

I would myself stands in between you two.

Coding style is a matter of opinion

Yes, I could not agree more, it's usually a matter of personal preference.

But here, I would tend to say that we should make a difference between « coding style » and « coding guidelines ».

coding style belongs to personal matter, and coding guideline belongs to a whole project. and to me there is a clear difference: the last one could be imposed to anybody, the first one not at all.

Thus I would be in favor of implementing the <p> and <li> execption, but none of the others one.

[ymeine]

As far as I remember, Hashspace content syntax is based on XHTML, not HTML, hence the mandatory closing tags.

Personally I find it more consistent to always close something that has been opened, instead of relying on less obvious parsing rules. It's the same as for the use of semi-colons in JavaScript, some don't use them...

[dpreussner]

It should be kept consistent. Either allow all optional closing tags or none.

Adding an exception just for <li> and <p> elements would be arbitrary and confusing for users. Although I can understand that this might be annoying for some people. But why introduce a special case into the language and your implementation for saving a few chars?

[PK1A]

I'm with @ymeine and @dpreussner - I would vote for enforcing closing tags for all but void elements.