6 ms·
I prefer HTML over XHTML, because it is easier to write. I don't get the reasoning behind closing tags. LIs close before the next LI, or the UL. <BR> saves two
by jeswin 13y ago
I prefer HTML over XHTML, because it is easier to write. I don't get the reasoning behind closing tags. LIs close before the next LI, or the UL. <BR> saves two characters over <BR /> and causes no harm. XHTML feels like trying too hard to make the machine overlord happy.
It is plain wrong to make a standard easier for machine-parsing at the expense of humans who are typing it in.
EDIT: Another example. I write some HTML in a text-editor/textarea and send it across to someone. If I missed a </LI>, should the parser reject it? If not, the standard should be accommodating enough so that this is valid.
- kalleboo 13y agoThe tradeoff is that allowing quirks like that means that either you need to make a massive specification to deal with each way someone might goof in their code (edit: which is what HTML5 tries to do), or you end up with each browser engine reacting differently. The main push behind stricter document control is making it easier to make all the browsers render documents consistently. Also, in the age of XHTML, manual document editing was seen as dead - tools like DreamWeaver were popular, and XSLT was touted as the answer to server-side templates. The web refuses to be anything but a pile of dirty hacks upon dirty hacks though, which while frustrating, may have a hand in it's popularity :)
- zimbatm 13y agoThat's why HTML5 specifies the parser, so that every browser extract the same DOM tree from the same input. The specification is strict in the sense that any parser has to behave the same while also allowing for human error.
- DougWebb 13y ago... so that every browser extract the same DOM tree from the same input That is, every browser whose engine has been updated for HTML5 and which also implements the parser specification correctly and without bugs. Which is most, but not all, of them. My personal preference is to include the optional closings, because XHTML has been around a lot longer and therefore a larger proportion of browsers have been coded to handle it properly and have had more time to work out bugs. I do like that HTML5 browsers can work around invalid markup in a well-specified way, which is much better than XHTML browsers just showing an error. It's the best of both worlds, especially when the browser's Developer Tools give you warnings about the invalid markup too so you don't need to use an external validator to find them.
- talmand 13y agoI'd rather the browser show the error then trying an educated guess at rendering the HTML soup that people/editors create.
- bhaak 13y agoIt does not only make the machine overlord happy, it also helps the humans when they do make a mistake. Humans throw some HTML-like stuff at the browser and the browser tries hard to make sense out of it. If the browser misinterprets, you have a hard time finding out what went wrong. Whereas with XML and XHTML you get told immediately what's wrong and you don't have to hope that every browser implementation works the same way. It's also a bit strange to argue about "easier to write manually" in this day and age of Markdown, HAML, etc.
- danbee 13y ago> If the browser misinterprets, you have a hard time finding out what went wrong. This is what HTML validators are for. Browsers should do their best to interpret the page authors intention and actually display a page. The developer doesn't always have 100% control over the page markup (think about user generated content, ads etc...)
- talmand 13y agoWhy can't the browser be the validator itself? You load the page and the browser tells you what's wrong with the code.
- rwj 13y agoThis would work as long as the browser was in a dev mode. Usability would suffer if normal users had to deal with errors in the pages that they visit.
- talmand 13y agoThat's a good point, but I wasn't necessarily thinking it should error out to render nothing at all. What I would like is if somehow the browser could insert an error class name into the offending element so that in my CSS I could give it a set of rules to make it stand out after render.
- bhaak 13y ago
- mkohlmyr 13y agoPersonally I see saving a few characters here and there as a completely inadequate reason for making the spec less consistent. I don't think any of the things you mention actually make html considerably more legible or easier to write for a person. Just harder to parse for a machine. I would rather have a strict language and have solid parsers that can thoroughly and decisively reject improper markup and help stop people from making mistakes while writing markup. Rather than trying to interpret what they really meant after the fact.
- recursive 13y agoHow many HTML parsers do you need to write on average?
- mkohlmyr 13y agoYou're only addressing half my argument. Just because we can invent the wheel once doesn't mean it's a good idea to make the problem it solves overly complicated for no good reason.
- Illotus 13y agoSo you are of the opinion that convenience is not a good reason?
- mkohlmyr 13y agoI'm of the opinion that there is nothing that much more convenient about what he was describing. And definitely not to the point where it makes a more complex specification worthwhile, whether one or a million parsers need to be written isn't really the point. There is some virtue in having a clean, consistent and well defined specification, for writing simpler parsers or just for being able to learn the language and be sure of how to parse it in your head. Fewer edge cases in specification = fewer mistakes and bugs in source. Attempting to fix mistakes and bugs after the fact by guessing what someone meant however will just make for new mistakes, hide bugs and does less to encourage a solid understanding of the language.
- untog 13y agoLIs 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.
- enraged_camel 13y agoIn 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.
- jonhohle 13y agoWouldn'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).
- callahad 13y agoFWIW, inventing arbitrary tags is coming with Web Components / Custom Element :) http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/
- untog 13y agoSure, 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.
- anonymouz 13y agoBut 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.
- 13y ago
- keeperofdakeys 13y agoThe two main advantages were XML parsing performance, and the ability to embed XML directly in the XHTML. For phones of the era, the performance benefits are obvious. As for XML embedding, it'd give you the ability to embed SVG, MathML, and any other XML language directly. This avoids a second retrieval/parsing step, and allows extensibility without changing the XHTML spec.
- mcv 13y agoYou've got a system with lots of exceptions and special behaviour. I don't see that as easier for humans at all. (The machine doesn't care; it parses anything you can put in rules. But the more complex the rules are, the harder it is for you to understand the error message. XML is really easier on humans.)
- romaniv 13y agoIt is plain wrong to make a standard easier for machine-parsing at the expense of humans who are typing it in. It is far worse to sacrifice consistency of the mental model behind the language for the sake of not typing two extra characters. Core XML is much easier to read than modern HTML, because you can read it without knowing the context of what you're looking at and without memorizing tons of exceptions. It's easier to parse for the same reason. Also, the savings on avoiding " /" are offset by the need to needlessly close some of the HTML5 tags. The only really stupid things in XML I remember is the need to do checked="checked" and people using namespace prefixes on every tag. It's pretty obvious how to fix the former. The latter is entirely avoidable if you have a fully working parser.
- 6cxs2hd6 13y agoYou'd like s-expressions. As in Lisp. (ul (li "one") (li "two")) Although I hadn't heard of the SHORTAG feature before: <strong>Hell yea</> It's a slightly more verbose version of s-expression.
- al2o3cr 13y ago"It is plain wrong to make a standard easier for machine-parsing at the expense of humans who are typing it in." No, it isn't - especially not when the intended use case is for literally every viewer of the document to use "machine-parsing" to read it, doubly so when a significant fraction of the users will actually BE machines...
- joesb 13y ago> LIs close before the next LI, or the UL. Unless you have nested list.