The joys of HTML5 validation
-
So:
</div>is an invalid self-closing tag and is viewed as a new tag while:<img></img>is seen as a stray ending tag, And all the while, it sort of looks like XML. 1. I can see now why there was a push for XHTML 2. Learning the details of this makes me loathe HTML even more 3. The W3C people are....wait for it...IDIOTS 4. This is why I'm writing a DSL to generate HTML. I never want to write a line of HTML again. Or Javascript. Or CSS. There. I'm done. For the moment. MarcThe ones you mention are just the tip of the iceberg. Unfortunately HTML5 is great for this - since it unifies the browser's error handling. Before HTML5, errors have been handled by all browsers differently.
-
CPallini wrote:
Now, you have to persuade the
DSLto write theHTMLfor you.:) I'm well on my way. Marc
-
The ones you mention are just the tip of the iceberg. Unfortunately HTML5 is great for this - since it unifies the browser's error handling. Before HTML5, errors have been handled by all browsers differently.
Florian Rappl wrote:
The ones you mention are just the tip of the iceberg.
So I'm noticing. Well, I'll fix them in the HTML generator as I encounter them. Marc
-
Florian Rappl wrote:
The ones you mention are just the tip of the iceberg.
So I'm noticing. Well, I'll fix them in the HTML generator as I encounter them. Marc
It will be hard to fix them all, as most HTML rules depend on the context. If you think parsing HTML is easy - it is not. There are crazy rules - especially for tables. And don't get even started on foreign elements... Additionally you just mentioned
<img>, but the specification also explicitly provides information on<image>- which is crazy. There is a huge number of other edge cases, but I think the foster parenting + formatting reconstruction are among the hardest. -
It will be hard to fix them all, as most HTML rules depend on the context. If you think parsing HTML is easy - it is not. There are crazy rules - especially for tables. And don't get even started on foreign elements... Additionally you just mentioned
<img>, but the specification also explicitly provides information on<image>- which is crazy. There is a huge number of other edge cases, but I think the foster parenting + formatting reconstruction are among the hardest.Generating HTML is still a lot easier than parsing it. :) In theory, a proper HTML5 and/or javascript generator could help us break free of the current web standards, without sacrificing browser or platform compatibility. I've thought about building something like that a few times, and I've got a few ideas how to go about it, but nothing concrete yet. If I find the time I'll make a public workspace for it, and throw my hat in the ring.
-
So:
</div>is an invalid self-closing tag and is viewed as a new tag while:<img></img>is seen as a stray ending tag, And all the while, it sort of looks like XML. 1. I can see now why there was a push for XHTML 2. Learning the details of this makes me loathe HTML even more 3. The W3C people are....wait for it...IDIOTS 4. This is why I'm writing a DSL to generate HTML. I never want to write a line of HTML again. Or Javascript. Or CSS. There. I'm done. For the moment. MarcDo it. I support you 100%. I would love to have something more programmy for working with HTML, CSS, and JavaScript. They're ridiculous and the syntax is unnecessarily complicated. *Le Sigh* If only those languages was more like C++ or C# or Java.
-
Do it. I support you 100%. I would love to have something more programmy for working with HTML, CSS, and JavaScript. They're ridiculous and the syntax is unnecessarily complicated. *Le Sigh* If only those languages was more like C++ or C# or Java.
-
Well - at least for the example you've submitted I don't see your squawk: <div/> is most likely an error, and at best, pointless (<br> works better and is clearer and has no closing '/'). How would XHTML handle this better? One's opinion enters in upon what better means. <img ...> has no end tag - but this makes sense: one is not supposed to have any content potential between tags of the image type (were they allowed). One sure way of preventing this is to flag the closing tag as invalid. Now - eliminating the internal closing tag for (i.e., no <img ... /> - I can see a good argument for that as the closing tag is a good flag that this is, indeed, the end, of a self closing element. Remember . . . above all . . . it's for the internet. Is it really worth being any more rigorous when you consider what will be done with it?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
So:
</div>is an invalid self-closing tag and is viewed as a new tag while:<img></img>is seen as a stray ending tag, And all the while, it sort of looks like XML. 1. I can see now why there was a push for XHTML 2. Learning the details of this makes me loathe HTML even more 3. The W3C people are....wait for it...IDIOTS 4. This is why I'm writing a DSL to generate HTML. I never want to write a line of HTML again. Or Javascript. Or CSS. There. I'm done. For the moment. MarcI know that this is a really old thread, and it's possible that you may have already finished your
DSL, but you should know that you've been reinventing the wheel here. Try HAML[^] (there are ports for languages[^] other than Ruby too) There are other similar things out there too, but HAML is by far the most well-known. -
I know that this is a really old thread, and it's possible that you may have already finished your
DSL, but you should know that you've been reinventing the wheel here. Try HAML[^] (there are ports for languages[^] other than Ruby too) There are other similar things out there too, but HAML is by far the most well-known.Moshe Katz wrote:
I know that this is a really old thread, and it's possible that you may have already finished your
DSL, but you should know that you've been reinventing the wheel here.Except that HAML and others, like Slim, are still implemented in a separate file, just like HTML. What I'm hoping to achieve is a set of re-usable blocks, HTML, CSS, Javascript, etc., that is implemented in code and can be glued together for the desired rendering. HAML isn't really a DSL, it's just a different syntax. Marc
Automating Semantic Mapping of a Document With Natural Language Processing