webbower commented 13 years ago

HTML5 allows for people to markup their documents in the stricter, XML-style and the lighter, old HTML style. Currently, the build script doesn't respect XML markup rules:

The tag for the main CSS file is hard-coded in build.xml to NOT have a self-closing "/"
The htmlcompressor flag to remove unnecessary tag attribute quotes is hard-coded in build.xml
For added compression, the htmlcompressor flag to remove boolean attribute values should be optionally included.

It seems to me a command line flag or project.properties setting to choose XML or non-XML style should be included. For XML-style markup, it should always include the closing "/" on any build script generated empty tags, not strip out quotes on attributes, and leave all boolean attribute values intact and the non-XML style should do the opposite of each of those.

mathiasbynens commented 13 years ago

Does it matter? If you compress your HTML why would you want to preserve the optional solidus?

webbower commented 13 years ago

For consistency, among other reasons. If you're going to strip that trailing slash of that empty link tag, you should also strip them off all the meta, br, img, embed, and hr tags. Other reasons:

People (myself included) still like writing our HTML in the style of XHTML as a personal preference and it's frustrating when something comes in and completely ignores your preference.
The only compression I ran on my HTML was stripping out comments. If I was doing the aggressive method to make my HTML as small as possible, then I'd say go ahead and strip of all the trailing slashes but you should also remove the boolean attribute values. But even, in that case, the script should respect my coding preference if I want XML compliance.
If, one day, it's safe so serve up your HTML5 docs as XML in browsers for whatever benefits it may grant, the build script will become unusable.

paulirish commented 13 years ago

So we take the position that the code you author shouldnt be the same code you serve in production.

Thats why you minify your javascript and concatenate your stylesheets and such..

We do minimal changes in markup by default, and lots more if you do ant minify..

I think you should be validating the HTML you author, not the HTML you serve. Just like you wouldnt run JSHint on your production javascript. :) Nahmean?

paulirish commented 13 years ago

lastly, for your purposes i would recommend just removing -htmlclean, from the build.production target in the build.xml

and it'll just skip the htmlcompressor entirely.

webbower commented 13 years ago

That all makes sense. But again, I bring to point the ability to serve a webpage as XML when it's safe in the future. Using the build script will prevent that from being the case since I'd author valid XML-style code and then it would get munged by the script. I do like that it strips out the comments and would recommend it also strips out the extra empty lines in addition so I don't want to completely drop the htmlcompressor.

If I'm not mistaken, minified JS will still be "valid" by JS[LH]int. But there's one set of rules for writing "valid" JS and that's no syntax errors. With HTML, there's 2 ways for it to be valid, depending on the needs of the project.

If I submitted a patch that provided the options in output that I'm talking about, would you consider rolling it into the release?

paulirish commented 13 years ago

sure.

it'd probably be like.. a config switch you place in project.properties.. xhtml = true... and the htmlcompressor goes on very light mode only taking out comments and maybe whitespace.

you can use <isset property="xhtml"> to conditionally do something based on that

adeelejaz commented 13 years ago

I'd just say a simple check over the extension of the file to negate and be done with it (.xhtml, .xht, .xml)... (Can we even do extensions checks with the build script? really??)

webbower commented 13 years ago

Does anyone really save files as .xhtml? It's usually an all or nothing deal and your files could be .php, .rb, etc.

Zearin commented 12 years ago

Actually I’ve been aching for an XHTML5 option in HTML5BoilerPlate. I have a lot of powerful XML tools I would love to be able to use that are currently unusable for HTML5BoilerPlate projects.

H5BP brings all the minutiae of best practices and cross-browser awareness to the table; my XML tools allow me to powerfully manipulate webpages in whatever ways I like. They are complimentary, but so far I have been forced to manually edit H5BP to make it compatible. It’s worth the effort because the payoff is huge, but it would be a thousand million times cooler to have the H5BP build script do it for me. ☺

(After all, isn’t this exactly the sort of thing build scripts are best at?)

roblarsen commented 12 years ago

I think the xhtml5 flag is a really good idea.

meglio commented 12 years ago

+1 to have an option for xhtml output.

Currently I cannot use html5boilerplate together with PHPTAL, because PHPTAL expects XHTML input, but it has an option to produce HTML5 output.

So I vote for XHTML output option for html5boilerplate.

meglio commented 12 years ago

Paulrish, I tried to remove -htmlclean as you recommended in your comment: https://github.com/h5bp/html5-boilerplate/issues/672#issuecomment-1787218

...but this way I get style.css missing in my "css" under "publish" after build, and in the same time I have no all-in-one css file inserted in my html, so it does not work.

the same happens to plugin.js and script.js

Any ideas on how to fix it?

kblomqvist commented 12 years ago

The tag for the main CSS file is hard-coded in build.xml to NOT have a self-closing "/"

923 fixes this

necolas commented 12 years ago

I merged in #923; the other issues remain for now.

h5bp / html5-boilerplate

2.0 build script does not respect XML-style markup #672

923 fixes this