Please turn Tidy off by default

[Hitch]

Originally Posted by DaleDe

I agree, a sigil.css is a good solution. The code needs to ensure the reuse of an entry instead of creating a new one. I had one file that was edited in several sessions and even in the on page CSS I found that the same exact CSS entry would be stored under several different Sigil CSS classes.

Dale

Hmmmm. I'm thinking about this. Generally, we don't encounter this issue often, as we import CSS with our html files, and thus don't have the infamous Tidying Infernal CSS styles showing up, but...

@DaleDe, thinking about that idea, the Sigil.css issue, what would happen, for example, thinking through the mechanics, if someone had two stylesheets? (We often do, as we build Kindle8-compatible ePUBs for our publisher clients, which they upload via eBookbase [essentially, although not actually] rather than the KDP [and thus, the ePUB must convert perfectly to K8 MasterMobi], and our experience is that 2 stylesheets, for the K7 & 8, work best.) Would the Sigil.css file simply be a third Stylesheet--or, for that matter, without overthinking it, would it be a second for those books that already have them?

I mean, we've all imported books with existing stylesheets, or used an xhtml file that was in Book A (like, an "About this Author" page) in Book B and imported the stylesheet along with it, so my initial thoughts are that as long as the Sigil.css didn't supplant the existing, I'd think that might be a usable compromise solution. Personally, I think it's a little overhyped as a problem, simply being an internal ss, which is fairly easy to find/fix, BUT, if people using BV are having issues, then maybe it does need some sort of compromise.

My $.02, FWIW.

Hitch

[JSWolf]

Why is it that Tidy feels the need to modify full paragraph styles? The styles Tidy is messing with are perfectly legal styles. There is no need to change them. All it does is make it harder to edit the ePub as a whole. And the changes are not consistent throughout each XML where Tidy changes.

SGC-1 in chapter 1 could be bold where SGC-1 in chapter 2 could be italic. So there is no way to search/replace to fix this. And if you wanted to change things on a global level, you might not be able to.

All this does is make it harder to work with the ePub (depending on what you want to do).

Can this monkeying around with the Styles by Tidy be removed? Is the source code out there such that it can be deleted from within Tidy?

[DaleDe]

@Hitch, yes a Sigil.css file would be in addition to whatever style sheets were already present. The idea is just to help ensure that SGC-1 always means the same thing wherever it is used so that JSWolf's problem would not occur. I have the exact same problem myself and even inside the same file after multiple edits of the file. This makes any kind of global change very difficult.

Having everything Sigil does in one file and inspecting the file for content before picking a new name for something that already exists would make things much better. Easier changes, more consistent recognition when looking at the code view.

Dale

[Hitch]

Originally Posted by DaleDe

@Hitch, yes a Sigil.css file would be in addition to whatever style sheets were already present. The idea is just to help ensure that SGC-1 always means the same thing wherever it is used so that JSWolf's problem would not occur. I have the exact same problem myself and even inside the same file after multiple edits of the file. This makes any kind of global change very difficult.

Having everything Sigil does in one file and inspecting the file for content before picking a new name for something that already exists would make things much better. Easier changes, more consistent recognition when looking at the code view.

Dale

I guess my next question, Dale, would be, why does this occur? Wolf asserts that it's happening with "perfectly legal styles," but this doesn't happen to us with the usual p tags with italic or bold tags wrapped around text contained within the p element (taking this as the simplest exemplar). So: what causes the SGC styles to show up as an internal stylesheet in your or Wolf's xhtml file, while it doesn't in ours? (This isn't disparagement--I'm trying to understand what actually causes it to occur). Is it the lack of an external stylesheet, or...?

Hitch

[theducks]

I have seen a small number of SGC tags appear (without my using any BV formatting) on books WITH stylesheets.

I have not pinned down why, there?

Almost all include Bold and or Italic and many times a heading with other than default (no) style.

[DaleDe]

I suspect they are being generated as part of things like centering a paragraph, at least this is one example I have seen. Also bold and italics showing up as SGC instead of being generated as inline b and em tags. I am not sure why they appear. I can't remember an SGC tag being automatically placed in a CSS file, instead I always find them in a style section within the head section of the file itself. I haven't played with post 5.0 versions to know if this is continuing but it certainly was in 4.2. I know I used to do this in page mode (WYSIWYG) before I realized it would sometimes do me in.

Dale

[Toxaris]

I only it see it when the style could be encapsulated. Examples:

<p><b>This is bold.</b></p>
<p><i>This is italic.</i></p>

Those kind of lines will result into an internal stylesheets.

[Hitch]

Originally Posted by DaleDe

I suspect they are being generated as part of things like centering a paragraph, at least this is one example I have seen. Also bold and italics showing up as SGC instead of being generated as inline b and em tags. I am not sure why they appear. I can't remember an SGC tag being automatically placed in a CSS file, instead I always find them in a style section within the head section of the file itself. I haven't played with post 5.0 versions to know if this is continuing but it certainly was in 4.2. I know I used to do this in page mode (WYSIWYG) before I realized it would sometimes do me in.

Dale

Well, this makes perfect sense to me, if you are using the alignment icons for these functions, rather than a named style in a stylesheet; of course Sigil will create a paragraph style of whatever name for this, and make an internal stylesheet entry for it. I'd have a fit if Sigil placed the ss entry into my own CSS sheet--so the internal entry is the place for it, OR, as suggested, a separate Sigil stylesheet. BUT, in order to remedy the major complaint here-that Sigil uses different style names in each xhtml file for the same things, i.e., italics in the base para style--this means that Sigil would have to track that specific style across all files--which is the whole POINT of a stylesheet. In other words, Sigil would have to a) create a Sigil.css stylesheet, place any created styles there, and then reference and use them across all xhtml documents in the file. What happens if, for example, someone has a stylesheet for file 10.xhtml, that has an italicized style for a base paragraph, which is named, e.g., p class="italic", and Sigil creates the same thing for another xhtml file, which is called SGC-3? (This begins, BTW, to feel remarkably like Calibre styles, which I personally loathe.) And does Sigil automatically place the Sigil.css stylesheet in the head of all xhtml styles in the entire book? I'm not sure this is as simple in execution as some of you think it is--but I'm not a coder, so it might be, but I see the possibility of some real conflicts here.

Sigil indubitably currently creates internal styles for each xhtml file, as would be absolutely correct coding if an external stylesheet does not already have the particular desired style covered.

@toxie:

I've not had that happen, when we have a stylesheet in place. I've only seen italic and bold tags cause internal ss entries when no stylesheet exists. You've seen differently? In recent Sigil releases?

FWIW,
Hitch

[DiapDealer]

With Tidy turned off I'm seeing absolutely no auto-creation of any internal styles. I never use any of Sigil's built in formatting capabilites (headings, bold, italic, indent, etc...), so I've been assuming that's why. Plus, as Hitch has already mentioned, I always have my own stylesheet in place (and linked). Perhaps that's part of it—I've not tested. All I know is I've not run into any auto-generated, inline Sigil styles in quite some time.

[Toxaris]

Originally Posted by Hitch

I've not had that happen, when we have a stylesheet in place. I've only seen italic and bold tags cause internal ss entries when no stylesheet exists. You've seen differently? In recent Sigil releases?

I see it still when I import a HTML file which has constructions like the ones I specified. Centering is of course also very common.

However, for me it is not really a problem. I only see 1 or 2 of them (usually only italic) and that is easy to fix before splitting the document.

It is all depending on the source of course. If the source has no stylesheet or is a crappy HTML conversion, this can lead to serious work.

[JSWolf]

Originally Posted by DaleDe

@Hitch, yes a Sigil.css file would be in addition to whatever style sheets were already present. The idea is just to help ensure that SGC-1 always means the same thing wherever it is used so that JSWolf's problem would not occur. I have the exact same problem myself and even inside the same file after multiple edits of the file. This makes any kind of global change very difficult.

Having everything Sigil does in one file and inspecting the file for content before picking a new name for something that already exists would make things much better. Easier changes, more consistent recognition when looking at the code view.

Dale

No. You have it somewhat incorrect. We shouldn't have a sigil.css file. Tidy should not be changing any valid code and turning it into any sort of style. So all these SGC styles should not be created in any form. The code is correct. It doesn't need to be changed.

[JSWolf]

Originally Posted by Hitch

I guess my next question, Dale, would be, why does this occur? Wolf asserts that it's happening with "perfectly legal styles," but this doesn't happen to us with the usual p tags with italic or bold tags wrapped around text contained within the p element (taking this as the simplest exemplar). So: what causes the SGC styles to show up as an internal stylesheet in your or Wolf's xhtml file, while it doesn't in ours? (This isn't disparagement--I'm trying to understand what actually causes it to occur). Is it the lack of an external stylesheet, or...?

Hitch

Here are the styles Tidy put in one of the XML files.

/*<![CDATA[*/

  div.sgc-2 {font-style: italic; font-weight: bold}
  div.sgc-1 {font-weight: bold}
  /*]]>*/
  </style>

Here is the original code.

<div class="ct"><b>CHAPTER ONE</b></div>
<div class="cst"><b><i>June 22, 1911</i></b></div>

Here is the code after Tidy changed things.

<body>
  <div class="ct sgc-1">
    CHAPTER ONE
  </div>

  <div class="cst sgc-2">
    June 22, 1911
  </div>

The first code to style change gets to be SGC-1, the second gets to be SGC-2 and so on. It just goes in order creating the styles. That is why the SGC styles are not always the same. It depends on the top down order of the code Tidy is changing to styles. Tidy is changing paragraph level code that is not in a style. It's not allowing the free form code to exist in the XML file. It wants all the free form codes to be styles. But the free form styles are legitimate.

I have found a bug in Tidy's styling. I went into the CSS and changed the styles .ct to include bold and .cst to include both bold and italic. Tidy still created styles instead of seeing that the styles it created are not actually needed ad just deleting the bold and italic codes for .ct and .cst.

[mmat1]

Originally Posted by JSWolf

I have found a bug in Tidy's styling.

It's not a bug, it's a feature. I think Tidy examines just one single (x)html, without looking for CSS or other html's, so it can't know that you have already set your "ct" / "cst" accordingly.

[DaleDe]

Originally Posted by JSWolf

No. You have it somewhat incorrect. We shouldn't have a sigil.css file. Tidy should not be changing any valid code and turning it into any sort of style. So all these SGC styles should not be created in any form. The code is correct. It doesn't need to be changed.

You are welcome to your opinion but I am not wrong with my opinion on how it should work. You methods are not the only ones in the world.

Dale

[JSWolf]

Originally Posted by DaleDe

You are welcome to your opinion but I am not wrong with my opinion on how it should work. You methods are not the only ones in the world.

Dale

We could have it done both ways. When the file(s) are run past Tidy and Tidy wants to change things to add in new CSS style(s), it could ask if that's what we want to do.