Hi,

What seems to be happening is that in Rockaway, the button div in a page title is given an element-level style attribute with “display:inline-block”. This is absent in pre-Rockaway environments. Therefore, if a button is given the CSS property “display:none”, it’s getting overridden by the element-level property.

I’ve created a sample page with the following properties which demonstrates this issue:

-There’s a page title with one button that has the “hiddenButton” CSS class.

-There’s inline css that hides the button: (.hiddenButtonClass{ display:none;} )

In a Rockaway environment, the button is visible; however, in a pre-Rockaway environment the button is hidden.

Here’s the code for that sample page:

<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true">    <models>

        <model id="AccountModel" limit="1" query="true" createrowifnonefound="false" adapter="salesforce" type="" sobject="Account">

            <fields/>

            <conditions/>

            <actions/>

        </model>

    </models>

    <components>

        <pagetitle uniqueid="sk-E3rAt-70" model="AccountModel">

            <actions>

                <action type="multi" label="Hide this Button" cssclass="hiddenButtonClass">

                    <actions/>

                </action>

            </actions>

        </pagetitle>

    </components>

    <resources>

        <labels/>

        <javascript/>

        <css>

            <cssitem location="inline" name="newcss" cachelocation="false">.hiddenButtonClass{

    display:none;

}</cssitem>

        </css>

    </resources>

    <styles>

        <styleitem type="background" bgtype="none"/>

    </styles>

</skuidpage>

The parent div in both environments does have the inline style “display:inline-block” - maybe in Rockaway that style was accidentally applied to the child div for the button as well?

Thanks for looking into this! It’s causing issues with several of our pages, and thus delaying our ability to rollout Rockaway to our Production environment.

Tanzir and Kartik,

We are able to reproduce what you are seeing with the button css property and have notified the developers. We will let you know when this is fixed on a future release.

Thanks!
Amy

In short, Kartik’s analysis is correct… a style attribute now appears on buttons when they first render, which will override your custom CSS rule.

The Longer Explanation

The internal implementation of buttons within a Page Title changed between Superbank and Rockaway. Buttons always added the style attribute once they were “un-rendered” (and would keep them even after rendering again). This was inconsistent with the behavior of some other components, however, so the rendering logic was refactored to be more consistent across all of Skuid.

Unfortunately, this means that regular CSS rules will no longer be able to change the “display” property for initially rendered buttons in Rockaway orgs since the style attribute has a specificity of 1,0,0,0 which wins against most other rules.

Next Steps

In general, Skuid recommends that you use Conditional Rendering to show and hide buttons. Conditional Rendering is a supported feature and we run many tests to ensure that it works the same from one version of Skuid to the next, unlike custom CSS rules which may break (though we do our best to minimize that as well).

If Conditional Rendering isn’t an option for you for some reason, there are a couple other things you could try, though keep in mind that it is the responsibility of the org admins/developers to support and maintain custom extensions since, unfortunately, we cannot guarantee that they will work in future versions of Skuid.

The !important rule is one solution and would probably require the least amount of effort on your part. It’s like bumping your CSS specificity up to 1,0,0,1,0 (which beats 1,0,0,0). There are, of course, many potential issues with a rule that uses !important, but that doesn’t mean that you should never use them. See !important CSS Declarations: How and When to Use Them.

Another option is to use custom Javascript, but this is probably overkill for your requirements and would be far more complex and difficult to maintain.

We are always listening to our customers!

If you feel that there is a gap in Skuid’s features requiring a CSS rule (like “display: none”), please tell us your use-case and we’ll consider how we might improve the product to address your scenario. We’ve delivered many features based on user feedback, and we’d rather have something baked into the product and fully supported than requiring you to fall back on custom CSS.