Sigil 0.9.x CSS refresh problem

[rubeus]

I've added an example... This is reproducable on my Computer. Changing the CSS and the changes are not reflected i can observe, too. But i cant reproduce it or give an example.
The svg wrapped image may help to find the root cause for this. May be not. Its the only reproducible problem i currently have where the bookview does not follow code changes.

[John2011]

Further to my previous query.

If I change a tag class in the HTML code directly. <p><b>words </b><p/> it will change straight away in book view to bold, or <p><em>words </em><p/> Italic etc.

However if I change it using the CSS it will NOT change until I reload Sigil and the book.

This is happening with every book I have tried it on.

Peace,
John P.

[Notjohn]

Originally Posted by John2011

If I change a tag class in the HTML code directly. <p><b>words </b><p/> it will change straight away in book view to bold, or <p><em>words </em><p/> Italic etc.

Are you doing this by typing the tag directly into Code View, or are you highlighting "words" and clicking on the *B* option in the icon menu?

<p/>

That's not actually how it reads, is it?

[rubeus]

I guess here are some things miced up. Changing a CSS file does not change BV/PV, thats true.

I'm speaking of seldom cases, where there is no change in the view even after reloading or changing from BV to CV and back to BV to get it running. Only closing Sigil and restarting it has an effect.

[KevinH]

I still can not see this or recreate this with valid css.
So please provide a reproducible example. The svg image issue was because the code generated was not valid. Does the new css pass css validation?
Thanks,
KevinH

[rubeus]

Ok i need to revise my last statement.

Open is: stylesheet Tab, Bookview Tab and Preview
Editing in the stylesheet does reflect the changes at once in Preview, switching to the Tab in Bookview mode does show the new setting if and only if the css is valid. I was wrong here.

But...

sometimes changes in the css do not affect Bookview or Preview, even if the css is valid. Sigil needs to be closed and restarted.
Unfortunately i cant reproduce this in a consistent way. It happens now and then (seldom) and i cant see a reoccurring pattern of what i'm doing. So i didnt brought this to attention. I only mentioned it here to just say: this does not happen to the OP only.

I thought that the AdjustSVG problem could be related to that issue thats why i brought it up, but it was a complete different root cause.

[KevinH]

Hi rubeus,

If you see this happen again, run the external css validator to make sure the css is valid.

If I have the following in a linked stylesheet and play with the color, it impacts Preview and BV almost instantly.


p {
color: red;
}

This proves that the proper signals are being sent almost immediately and that BV and PV receive those signals and update accordingly.

Now if I write invalid css such as

p {
hcolor: red;
}

and play with the value red, it is never reflected in BV and PV. In fact, having invalid css earlier on in the stylesheet may prevent later stylesheet elements that look perfectly correct from being processed. In other words, invalid css almost anywhere in the stylesheet can cause the entire stylesheet to be ignored at times. That is why we link to the external CSS validator to try and help people track this down.

Hope this helps,

KevinH

[rubeus]

Sorry to say that, but i've checked the css @ w3c and it was valiid. I beleive we cant tear that down until someone has a reproducible case.

[KevinH]

One other thing. Signals were broken in Sigil 0.8.7 version so this may well have been an issue in that version. It should not be an issue in Sigil-0.9.2. And I think you are right, without a reproducible test case, we can't really do anything about it as at a fundamental level it is working. So something strange must be going on.

[DiapDealer]

I'm tempted to dismiss it as "works for me," but I can't quite get past the fact that the reported cases all seem to be fixed by restarting Sigil. If it was a syntax error or other invalid css, a restart/reopen shouldn't have "fixed" it. A restart of Sigil should never make anything render differently, should it (provided there were no unsaved changes dismissed)? Are there any circumstances where a file rename/import or a split/merge could somehow leave something "stale" or disconnected? Those would be the areas I would focus on if I were looking to nail down something reproduceable. That or any automated task that was run prior to css changes not taking effect any more.

One other possibility is embedded fonts. I'd have no trouble believing there might be issues with css changes not immediately taking effect on text that was already being rendered with embedded fonts. Embedded fonts and WebKit have been pretty flaky from the beginning.

Help us find it and we'll fix it (or at least tell you we can't)!

[KevinH]

Hi,

One thing a restart does is pass all xhtml files through gumbo again to check/fix any link updates (and by doing so will fix any broken xhtml) and it will clear all caches that BV/PV will build for all resources linked to from that page. So if the link tag was broken in some way, or missing some pieces, that might explain everything. So I guess, if you ever see this problem, please try right clicking on the impacted xhtml page, and running ReformatHTML->Mend on the code and then verify the link tag in head is properly written/updated. URLs can be case-senstive while some file systems may not be so it may be as simple as wrong case being used in a file name or a broken link tag in head. Running Mend should rule this out.

KevinH

[theducks]

Originally Posted by Notjohn

Are you doing this by typing the tag directly into Code View, or are you highlighting "words" and clicking on the *B* option in the icon menu?



That's not actually how it reads, is it?

IIRC P is not a permitted self closing tag

[GrannyGrump]

@DiapDealer --- Re: embedded fonts --- I just want to mention that the only time I have any issue similar to this, it is invariably when I am dealing with embedded fonts. I can't reliably reproduce it (sometimes it seems to mostly happen with larger epub over 10mb, but some large ones work fine.)

What happens is this:
If I have @font-face assigned to a certain font, and then change it to a different font, it sometimes won't reflect in Preview Pane without "refreshing" the css with a re-launch of Sigil, OR by reloading the book. Once in a great while, changes to a css class REFERRING to that embedded font will likewise fail to update in the Preview.

I am sorry to say, it only happens sporadically, even with the same document. Next time it happens, I will try to provide more info.

[John2011]

Originally Posted by Notjohn

Are you doing this by typing the tag directly into Code View, or are you highlighting "words" and clicking on the *B* option in the icon menu?



That's not actually how it reads, is it?

Iam doing this by directly typing into code view. I have never used the buttons.

No it was a typo. I did the first line then did a copy and paste.
So the <p/> was displayed twice.

It should have been and is in the book </p> </em>

I have check the .ccs on line and all is good. The code passes both FlightCrew and ePubcheck.

I have tied "mend and prettify code" as well.

John P.

[rubeus]

As far as i know epubcheck doesnt really check the CSS deeply, i'm always using the CSS validator @ W3C