"addCSSString" not having immediate effect

seanc · December 26, 2011 2:15 pm

I have a number of inspector controls whereby the user can change CSS style values. They work, but are not immediately propagated to the pagelet currently "in view" while editing.

In order to see the changes, while editing, I have to select another page in the site outline. Exported site works fine.

The properties are all declared in .h, registered in "plugInKeys", initialized in "awakeFromNew", and dependencies set in "writeHTML". Inspector is correctly populated with initial properties.

Debugger console shows that "writeHTML" is being called. NSLog entries show that the inspector changed value IS being used to create the new style string, and that "addCSSString" is being invoked. It just doesn't "take hold" on the page being edited.

I have one control which DOES work, however, it's not a CSS value, just a conditional branch boolean.

All things considered, it seems to me that "addCSSString" does not overwrite a prior string w/the same selector set, but, because the style value is different, it must add it as a separate rule, above the existing rule, thus negating it's effect. Only by changing to a different page does the CSS get completely re-written anew. Is this how it works?

Is there any way to tell it to "rewrite" all the CSS in each "writeHTML" invokation?

Thanks, Sean

mikeabdullah · December 27, 2011 5:59 am

Hi Sean, looks like you're seeing a combination of problems here.

When your plug-in changes, Sandvox avoids reloading the entire web view by just reloading your plug-in's bit of the DOM only. In 2.2.3, any -addCSSString: calls are handled by writing that CSS out inline as part of the HTML. Unfortunately, when that HTML is copied in, WebKit chooses not to interpret it, and so it never takes effect.

For 2.2.4, I'm working on improving this so that any such CSS gets injected directly into the <HEAD> of the page where it belongs, and so takes effect. This hasn't made it into the current beta; will be in beta 4, due out shortly.

The other problem is that existing CSS doesn't get removed from the DOM. Most likely this won't affect you if the new CSS completely overrides the old, but let me know if it is still causing a problem. I'm putting it on my longer-term list to improve.

Also, note that there's a Reload command in the View menu, which is handy for this sort of thing, rather than having to navigate to a different page and back again.

seanc · December 27, 2011 8:49 am

Hi Mike:

When your plug-in changes, Sandvox avoids reloading the entire web view by just reloading your plug-in's bit of the DOM only. In 2.2.3, any -addCSSString: calls are handled by writing that CSS out inline as part of the HTML. Unfortunately, when that HTML is copied in, WebKit chooses not to interpret it, and so it never takes effect.

I suspected something of that nature. :(

In earlier (minimal function) versions of my plugin, SOME (but not all) of the CSS changes DID get rendered immediately. In fact, if I recompile that earler version linked to 2.2.3 (24182), those controls STILL do work immediately! Does that make any sense?

The only major change made from that earlier to most current version was to add more properties & inspector controls.

Also, note that there's a Reload command in the View menu, which is handy for this sort of thing, rather than having to navigate to a different page and back again.

Yah, I was aware of that, but page "relaod" is far slower than just selecting another page from the site outline. Selecting another page renders instantly, "reload" takes 3-4 seconds.

More importantly, asking an end user to do either, just to see the results of their change, isn't what I'd consider "user friendly". :)

I look forward to beta4.

Sean

mikeabdullah · December 27, 2011 9:38 am

seanc wrote:

In earlier (minimal function) versions of my plugin, SOME (but not all) of the CSS changes DID get rendered immediately. In fact, if I recompile that earler version linked to 2.2.3 (24182), those controls STILL do work immediately! Does that make any sense?
The only major change made from that earlier to most current version was to add more properties & inspector controls.

All that comes to mind is perhaps that older version also tweaked the HTML in some way such as the desired behaviour happened to kick in?

seanc wrote:

Yah, I was aware of that, but page "relaod" is far slower than just selecting another page from the site outline. Selecting another page renders instantly, "reload" takes 3-4 seconds.
More importantly, asking an end user to do either, just to see the results of their change, isn't what I'd consider "user friendly". :)

Ah, good point; Reload does do a full reload of any resources on the page, which tends to be somewhat slow if there's many scaled images or remotely located items there. I only intended it as a debugging aid for yourself; it's rarely useful to end users.

seanc · December 27, 2011 10:34 am

Mike:

All that comes to mind is perhaps that older version also tweaked the HTML in some way such as the desired behaviour happened to kick in?

They both actually "tweak" the HTML. That is the one control I mentioned which does work at all times.

However, I have now discovered why the earlier version worked for CSS changes. Perhaps you can make use of the discovery :)

I had been using a small snippet of javascript in the template just for test & debug purposes (I had been using "em"s to set line-heights, and needed to see what the pixel values were. The javascript simply reported the final "calculated" line height of the DOM elements). I changed the property from ems to pixels in the current version, so I no longer needed the javascript, and deleted it from the template.

It was the javascript that caused it to render immediately! As it happens, no code is needed, an empty script declaration in the template suffices:

<script type="text/javascript"></script>

This works for all numeric CSS values (ints, floats & booleans), but still not for text (filenames, eg: "bullet1.gif")

Sean

Last edited by seanc (December 27, 2011 10:34 am)

mikeabdullah · December 27, 2011 6:26 pm

OK, beta 4 is live at:

<http://karelia.com/beta/1/_Sandvox-beta-24188.dmg?>

Let me know if you're still seeing problems with CSS using it.

seanc · December 28, 2011 9:42 am

mikeabdullah wrote:

OK, beta 4 is live at:
<http://karelia.com/beta/1/_Sandvox-beta-24188.dmg?>
Let me know if you're still seeing problems with CSS using it.

That works Mike, w/out the javascript "tickle", thank you! Same results as the javascript though: only numerics propagate. However, I think I know why:

My plugin uses custom list bullet images, but the user has the inspector option to use the designs default bullets.

when set to use the custom bullets, the style string includes an explicit "list-style-image" declaration.
when set to use the designs bullets, the style string includes NO "list-style" declaration at all, depending entirely on inheritance.

It's the inheritance that doesn't propagate, view is holding on to the last explicit declaration. I may have to write some kind of intermediate dummy style to kick the inheritance in, then subsequently overwrite it. Will investigate that.

Thanks Mike! Sean

mikeabdullah · December 28, 2011 11:41 am

In general in Sandvox's own plug-ins, we've tended to use a single CSS file, and then change the classes in use. That sort of approach doesn't expose the original bug, and might well be something you could do in this particular case: generate the CSS for both list styles, choose the right one from the class.

Having the CSS completely regenerate from scratch (which is what should ideally happen to squash all such bugs) is a surprisingly tricky problem within Sandvox, so that probably won't happen in 2.2.4, but a later update.

seanc · January 12, 2012 8:12 am

Mike:

I've tried all manner of "tricks" with no success. Just can't get it to inherit graphics w/out changing page.

I had already been declaring multiple class elements, and generating the appropriate class in the CSS strings, to no avail. Increasing specificity didn't help, nor did redeclaring "inherit" with "!importants".

It does ultimately work fine, so I'll just have to warn the user of this anomaly.

Sean

mikeabdullah · January 12, 2012 9:36 am

If you can send me a plug-in that demonstrates the problem, I'll have a better chance of debugging the problem :)

seanc · January 13, 2012 8:25 am

mikeabdullah wrote:

If you can send me a plug-in that demonstrates the problem, I'll have a better chance of debugging the problem :)

Will do. Do you want the source, or just the compiled plugin?

Either way, it will be tomorrow or after. I've got a lot of non-working code to clean up, from attempts to work out the "index" plugin issues I've come across, and have to run off early today.

Where to send it?

Thanks! Sean

Last edited by seanc (January 13, 2012 8:26 am)

seanc · January 17, 2012 6:04 pm

Mike:

Following up from the other thread: I've implemented 2 placeholder strings, (via -(NSString*) placeholderString;). They do work, but there's one rather bizarre behavior:

With a placeholder active:

I can switch from "sidebar" to "inline" and back all day long, and they render.
I can switch from "sidebar" to "callout" and back all day long, and they render.

But, if I switch from "callout" to "inline" it fails to render: the outline is collapsed. NSLog entries show that the placeholder string IS being set & invoked.

Just as with the CSS images, if I change to another page in the Site Outline, and then back, it DOES render. I don't know what to make of this, unless it is also related to the same cause as the CSS inherited images not immediately updating.

Sean

mikeabdullah · January 18, 2012 8:39 am

Drop an email to testing@karelia.com, that'll make it through to me. If you send me the full project that me be easier to debug, but a compiled plug-in should probably be fine.

seanc · January 22, 2012 5:24 pm

Mike:

I've got this issue figured out. It was due to a combination of things:

1) because some designs use "!important" on list rules, I also had to use "!important" to override them

... in combination with ...

2) declaring HTML elements with multiple CSS classes

eg. an <LI> element with both "classA" & "classB" styles. If the generated CSS was a rule for "classA" with a "!important", then later changed to a "classB" via inspector, the view would not immediately override the "!important". This is what required the page change/refresh to re-render.

I've rewitten the HTML elements w/single class, and it works fine now. It did need more specificity to some of the CSS strings too.

Thanks for your help! Sean

seanc · February 6, 2012 2:07 pm

Mike, this has come up again. I thought the issue was solved, but that only applied to a single plugin "view".

When 2 or more instances of the plug are shown in the sidebar, manipulating inspectors controls for one, cross-couples to the other(s).

As before, this ONLY occurs on the page being edited. Switching to another page, or "reloading" the current page, brings it all back into proper display. Also as before, export & publish work perfectly.

I'll be sending an email shortly, with a link to download the working plugin, so you can see what's happening.

Sean

mikeabdullah · February 17, 2012 4:41 am

For the benefit of any other developers reading this, this bug should be fixed for Sandvox 2.2.6+ on Leopard, and 2.5.3+ on everything else.

seanc · February 18, 2012 7:44 am

Yes, it IS fixed. Thank you Mike!

seanc · March 4, 2012 8:51 am

Mike:

2.2.6b1 has expired. Any timeframe for release?

Sean

mikeabdullah · March 4, 2012 12:21 pm

Hi Sean,

We're focusing on getting 2.5.3 wrapped up right now, but after that 2.2.6 will be up. I'll post a new beta shortly.

seanc · March 5, 2012 8:10 am

OK, thanks Mike!

mikeabdullah · March 8, 2012 1:43 pm

Sorry for the delay on this; beta 2's now live!

seanc · March 8, 2012 5:06 pm

Got it, thank you Mike!

seanc · April 1, 2012 2:46 pm

Hi Mike:

2.2.6b2 has expired now. Got another? :-)

Thanks!

mikeabdullah · April 3, 2012 9:25 am

Sorry about that. Beta 4 is live now!

seanc · April 3, 2012 2:12 pm

Thank you Mike!

Karelia Community Forum

#1 December 26, 2011 2:15 pm

"addCSSString" not having immediate effect

#2 December 27, 2011 5:59 am

Re: "addCSSString" not having immediate effect

#3 December 27, 2011 8:49 am

Re: "addCSSString" not having immediate effect

#4 December 27, 2011 9:38 am

Re: "addCSSString" not having immediate effect

#5 December 27, 2011 10:34 am

Re: "addCSSString" not having immediate effect

#6 December 27, 2011 6:26 pm

Re: "addCSSString" not having immediate effect

#7 December 28, 2011 9:42 am

Re: "addCSSString" not having immediate effect

#8 December 28, 2011 11:41 am

Re: "addCSSString" not having immediate effect

#9 January 12, 2012 8:12 am

Re: "addCSSString" not having immediate effect

#10 January 12, 2012 9:36 am

Re: "addCSSString" not having immediate effect

#11 January 13, 2012 8:25 am

Re: "addCSSString" not having immediate effect

#12 January 17, 2012 6:04 pm

Re: "addCSSString" not having immediate effect

#13 January 18, 2012 8:39 am

Re: "addCSSString" not having immediate effect

#14 January 22, 2012 5:24 pm

Re: "addCSSString" not having immediate effect

#15 February 6, 2012 2:07 pm

Re: "addCSSString" not having immediate effect

#16 February 17, 2012 4:41 am

Re: "addCSSString" not having immediate effect

#17 February 18, 2012 7:44 am

Re: "addCSSString" not having immediate effect

#18 March 4, 2012 8:51 am

Re: "addCSSString" not having immediate effect

#19 March 4, 2012 12:21 pm

Re: "addCSSString" not having immediate effect

#20 March 5, 2012 8:10 am

Re: "addCSSString" not having immediate effect

#21 March 8, 2012 1:43 pm

Re: "addCSSString" not having immediate effect

#22 March 8, 2012 5:06 pm

Re: "addCSSString" not having immediate effect

#23 April 1, 2012 2:46 pm

Re: "addCSSString" not having immediate effect

#24 April 3, 2012 9:25 am

Re: "addCSSString" not having immediate effect

#25 April 3, 2012 2:12 pm

Re: "addCSSString" not having immediate effect

Board footer