Does Pretty Print/Fix does this

[rag_gupta]

In my site : http://www.indiacustomercare.com
almost all of pages are generated by a perl script which does not generate for example closing p tags etc.

Here is the sample page.

On checking this page as per strict doctype CSE correctly tells me that h3 is contained within p tag as p does not have a closing tag.

When I run Pretty Print/Fix for following code:
<p>Hello

this tool correctly generates:
<p>Hello</p>

Given that every code that has gone into my sites has been checked with CSE (with no doctype), so I want to use Print/Fix tool to convert back this html in the site pages to as per doctype:strict using Print/Fix. Will it be all fine?
Can this tool remove any structure or have any unnecessary side affects?
My all pages are similar to the sample page I mentioned above.

[Albert Wiersch]

Given that every code that has gone into my sites has been checked with CSE (with no doctype), so I want to use Print/Fix tool to convert back this html in the site pages to as per doctype:strict using Print/Fix. Will it be all fine?
Can this tool remove any structure or have any unnecessary side affects?
My all pages are similar to the sample page I mentioned above.

Unfortunately HTML Tidy can have side-effects. You'd have to see how it does on a case-by-case basis. I think it may be able to do what you want, however. Also, I'm willing to bet that the "cleaner" your pages are to begin with, then the better your results will be after using HTML Tidy. Since you used CSE HTML Validator on the pages already, they should be fairly clean.

Of course always keep backups of your originals in case you later realized that HTML Tidy did something you didn't want.

[rag_gupta]

Thanks for you reply. This helps.

Can you please tell me side affects in browsers in case(my case) some tags are not closed like p (as per some html standard) when the doctype of the webpage served from my site is Strict?
Although I find no issues when I looked cursorily in IE,FF,Opera.


Also I made another post yesterday and expecting a reply from you: viewtopic.php?f=1&t=1255&p=5530#p5530

[Albert Wiersch]

Can you please tell me side affects in browsers in case(my case) some tags are not closed like p (as per some html standard) when the doctype of the webpage served from my site is Strict?
Although I find no issues when I looked cursorily in IE,FF,Opera.

I am not sure if there would "real-world" issues with this. It may not be much of a problem other than not being technically correct for a strict document.

Also I made another post yesterday and expecting a reply from you: viewtopic.php?f=1&t=1255&p=5530#p5530

Yes, I have not had a chance to reply to that yet. I have to do a little research on that one. I should be able to reply tomorrow.

[Pickwick]

If I may jump in here, please. The "target" attribute was originally deprecated because it was thought there were getting to be too many Pop-up windows. Those of us who needed a new window and still had to use valid code quickly cane up with a "hack" or work-around.

From what I have read about HTML5, it looks like this attribute will no longer be deprecated.

Okay, that means if you plan to use XHTML1.0 Strict, you need to make use of something like the JavaScript work around. You can Google this and find the exact solution quite easily.

As for the real world side effects and not closing tags, browsers are auto-correcting the code for people who don't code properly. Case in point: I can write <p>A new paragraph. <p>A second paragraph. Looking at the code AFTER it is rendered in Firefox, I would see <p>A new paragraph. </p><p>A second paragraph.</p> (select over that portion of the web page with your mouse, right-mouse click on it, and choose "View selection source"). Please think about the cumulative amount of computer time for browsers to check every web page and then make the corrections needed. This slows the web down for everyone.

The public's expectation of browsers is that they will do more and do it faster. I heard a discussion by the lead developers for Opera, IE, and Firefox who all agreed they can't make all of the corrections forever. At some point the browser will simply render the page as written. They were asked if that wouldn't mean some pages won't be rendered properly or at all. Without hesitation, the answer from all of them was, "Yes!"

Finally, the day of web pages standing alone is basically over. Today, a web page has to communicate with the back end. You are doing this when you have Perl generate a web page. There is also AJAX. The biggest concern for many large companies is that their web pages are "Standards Compliant." If they aren't, other things start to break.

[MikeGale]

Good post Pickwick.

Things like that (no target attribute allowed) convinced me early on that XHTML Strict is not useful to me. I also thought it wouldn't catch on in a big way.

(I recently saw a comment that the Ubuntu (a Linux version) distribution had been taken over by a demonically crazed dictator. Which was killing it. (They made big changes to the GUI. A lot of users dumped those changes rather quickly.) This sort of thing is in a similar category, to my mind!)

I think that penalising incompetent markup would be a good idea. I don't see it happening though. Google did a survey a few years ago. (I've not seen a published paper on the detail, just references to some of the results.) They measured 97% of pages were fundamentally flawed. We're talking really basic markup mistakes here. My guess (again not documented) is that maybe 99.7% of pages (at that time) had unforgivable mistakes. These things make me think that browser developers are now well and truly trapped by the incompetence they have allowed to arise and flourish.

Like you I think it ridiculous that this idiocy is soaking up processor cycles, making my browsers slower and actively preventing browser developers from doing more useful things.

I'd like to see the days of flat pages waning. I don't see that happening though. The majority of the web is swinging to lower and lower quality. It's very easy to implement a half baked idea as bad HTML. Some of those half baked ideas then go on to churn out nearly content free pages. (The developers, to give them their due, often saw the first version as a test. They intended to do it properly if it worked. They then got trapped...)

(I personally don't count a page that could have been served up as plain HTML, but is instead made, over and over again, by code differently from flat HTML!)

The cool thing is that with a web that is so big, time is ripe to subset what you see. In other words make the bit dribble invisible by never seeing it! It's not yet particularly easy, but I think it inevitable that some people will find ways to filter it out. When that is easy some users are going to opt for smarter content. That will sometimes tap into the potential of the web.

HTML 5, Apps and the coming HTML-ified Windows UI are rays of hope.