Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

LIs close before the next LI, or the UL.

But the problem is that you now have a specific behaviour that depends on the tag name. DIV tags don't need to close before the next DIV, but LI tags do. So you've gone from a simple tag parser to one that needs to know the intricacies and rules surrounding every element type.

Personally, I feel that two extra characters per <BR/> tag is worth it.



In addition, not having to close some tags might make it easier to write HTML, but it makes it more difficult to learn it. I remember back in the day I had to keep looking up which tags need to be closed and which ones do not.

Nowadays I just close everything because my OCD outweighs my laziness.


Yes, it makes parsers harder. Or more accurately, it shifts some of the complexity from producers to parsers.

Given the landscape of HTML (lots of producers, comparatively few parsers), this shift seems reasonable to me.


Wouldn't having a reasonable schema specification specification solve this? Its not like you can invent arbitrary tags (there are arbitrary attributes, but an expressive enough schema language could capture that as well).


FWIW, inventing arbitrary tags is coming with Web Components / Custom Element :) http://w3c.github.io/webcomponents/spec/custom/


But then you need a schema to be able to parse the file. XML files can be checked for well-formedness and parsed without a schema file.


Sure, but presumably that schema will change with time. Then you'll have a parser built around HTML5, but another new release for HTML6, so on and so forth. It just needlessly complicates things.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: