I have quite a large number of HTML fragments. These are included in other documents, however, I would like some way to verify them individually as fragments.
I can't very well put them in an HTML sandwich to make the validator happy, since that would make them unusable for inclusion. (though I suppose I could write a program to temporarily apply heads and tails to verify).
Here is a rough outline of a possible solution:
For batch, I can mark a directory as being a directory of "fragments", and I can provide the name of a head and tail file to logically apply to each fragment before validating.
Here is another approach. You have a relaxed fragment verification mode that forgives the initial missing <doctype, <html>, <head>, <body>, <table>, <tbody> and <tr> so long as all balances inside.
The feature might also be useful for validating hunks of raw JSP code where you don't have a complete HTML document. The rest of the document is generated dynamically.
Ideally the solution might solve a number of related problems.
I'd be interested in hearing any thoughts from your beta testing base on how this could be done.
Validating fragments
-
- Rank V - Professional
- Posts: 367
- Joined: Fri Feb 17, 2006 5:22 am
- Location: Victoria BC Canada
-
- Site Admin
- Posts: 3785
- Joined: Sat Dec 11, 2004 9:23 am
- Location: Near Dallas, TX
Re: Validating fragments
CSE HTML Validator already has something like this. Is it not working well for you? Could you email me some sample fragments? Thanks!roedygr wrote:Here is another approach. You have a relaxed fragment verification mode that forgives the initial missing <doctype, <html>, <head>, <body>, <table>, <tbody> and <tr> so long as all balances inside.
Albert Wiersch, CSS HTML Validator Developer • Download CSS HTML Validator FREE Trial
-
- Rank VI - Professional
- Posts: 726
- Joined: Mon Dec 13, 2004 1:50 pm
- Location: Tannhauser Gate
I've just had a look at this feature, works great for fragments stored as files. (I used both a *.htm and a *.txt, both worked.)
The analysis is prefaced:
"The first tag in the document was out of range. The document has been checked with the assumption that a block of HTML that belongs in a <html><body> ... </body></html> section is being validated."
This looks to be the best assumption (plain basic HTML) to me.
If you're using xhtml, or something more specific you'll need to do a bit more work. I remember my annoyance at the earliest implementation of xml on .NET. It adhered to a standard that had come out of a committee and was pretty programmer hostile, forced creation of xml documents to do any work with fragments. I realised, it's very easy to do, which blunted my hostility to a bad design.
If your material is stored in a database one approach would be to:
I find that these quick tools are often justified by the first use alone. The trick is to document it for re-use. Say on an internal web page with a quick write up (it can be roughly done, nobody else is going to read it!). Even if that takes almost as long as writing the code in the first place, it can save a lot of time later!
The analysis is prefaced:
"The first tag in the document was out of range. The document has been checked with the assumption that a block of HTML that belongs in a <html><body> ... </body></html> section is being validated."
This looks to be the best assumption (plain basic HTML) to me.
If you're using xhtml, or something more specific you'll need to do a bit more work. I remember my annoyance at the earliest implementation of xml on .NET. It adhered to a standard that had come out of a committee and was pretty programmer hostile, forced creation of xml documents to do any work with fragments. I realised, it's very easy to do, which blunted my hostility to a bad design.
If your material is stored in a database one approach would be to:
- Output as text encased in whatever html, body... tags you need
- Create a batch file (from code) to report on the fragments (give them good names)
- Invoke the batch wizard and get a report on any issues
- A variation on this is to write the pages to a site on your server, which will also give validation of css, js, jpg...
I find that these quick tools are often justified by the first use alone. The trick is to document it for re-use. Say on an internal web page with a quick write up (it can be roughly done, nobody else is going to read it!). Even if that takes almost as long as writing the code in the first place, it can save a lot of time later!
Last edited by MikeGale on Mon Jun 02, 2008 8:25 pm, edited 1 time in total.
-
- Rank VI - Professional
- Posts: 726
- Joined: Mon Dec 13, 2004 1:50 pm
- Location: Tannhauser Gate