As an experiment, I ran an html book through html tidy online. I got one error and 58 "warnings." The Tidy output had incorporated all the warnings.

I then fixed the one error in the original html file and opened it in Sigil. I saved it as filename.epub and clicked on the Tidy icon. (I am using 5.3.) The "validation results" window at the bottom of the page remained blank.

So!

1) Am I correct in assuming that those 58 warnings have all been tidied up without my knowing about it?

2) Is there a chance that Tidy could cause a problem with all that dusting and sweeping behind the scenes?

0.5.3 is a bit old, but if I remember correctly the files were always run through Tidy and therefore would have cleaned up certain types of errors. Full HTML Tidy does change your code some, and if you had certain errors in it it could delete parts - though rare. Pretty Print Tidy only formats and fixes basic issues. But you would have to upgrade to the latest version to have the full options on cleaning.

Pretty Print Tidy makes very few changes to most code, and is the only way at the moment to get the code formatted nicely automatically. In fact, without Pretty Pretty Tidy (with Clean Source set to off), you would be surprised at the number of books that won't open due to errors. At least that's what happened when the setting was defaulted to off for a version. Its really only HTML Tidy that makes, in my view, too many changes - but still some people prefer it so its available for them. Turning Clean Source completely off is certainly possible - and may be useful for those who know exactly how their code is formatted and don't want any changes, which is why its there too.

Not acceptable to you I guess but it is acceptable to many folks and certainly to ePubCheck. Quit pushing your agenda on everybody else.

Dale

We've already had the discussion on the styles (SGC-1, SGC-2, etc) that Tidy can create in the XML files. They are hardly ever the same and if you are trying to do a search/replace to change/fix some code, you may find it doesn't work as expected.

Most people that do dive into the code don't want Tidy making those styles.

Most people that do dive into the code don't want Tidy making those styles.

Tidy won't make those styles if you know what you're doing (aka: one who dives into the code), and those who don't know what they're doing won't care in the least about those styles. It's a moot point.

Tidy won't make those styles if you know what you're doing (aka: one who dives into the code), and those who don't know what they're doing won't care in the least about those styles. It's a moot point.

So how do you get Tidy to stop making those styles other then turn it off?

Full HTML Tidy does change your code some, and if you had certain errors in it it could delete parts - though rare.

Not that rare in my experience. I class it as a very dangerous function, to be avoided unless you have a special reason - and I can't imagine what that reason could be! The chance of data loss is a pretty negative feature.
On a related point, we still badly need a 'save it as it is - I'll fix the errors later' option. Sometimes an editing session has to end NOW.

Allowing to save an epub in an invalid state means Sigil would have to allow opening an epub in an invalid state. How would Sigil possibly know that the error is one that you intentionally saved it with and not one that it would normally fix? The only way I could see that working is by saving it as some other file-type; which is likely to cause confusion when people don't know that they need to open the new error-state-saved project file in order to pick up where they left off. I just don't see it happening.

Allowing to save an epub in an invalid state means Sigil would have to allow opening an epub in an invalid state. How would Sigil possibly know that the error is one that you intentionally saved it with and not one that it would normally fix? The only way I could see that working is by saving it as some other file-type; which is likely to cause confusion when people don't know that they need to open the new error-state-saved project file in order to pick up where they left off. I just don't see it happening.

It's better than being in a position where you've broken something, don't quickly see the error, can't save but have to end the editing session and be somewhere else! Auto-fix can lose data.

I'm not saying it wouldn't be handy. I'm saying I don't think the way Sigil's currently structured will easily allow that kind of "anything goes" save/open scenario. The vast majority of Sigil's feature set is predicated on xhtml being well-formed to begin with.

As I said, the only way I see around it is saving epubs in invalid states as a different filetype. Which while feasible, comes with it's own headaches and considerations. There simply is no "just save it as it is" solution to the problem. Never has been. It would be implemented already if there were.