As most Dynamics 365 Portal developers start as CRM developers, we often try to take the same approach to solve similar problems on both platforms. However, it’s important to remember that a D365 Portal implementation is using different technologies, and sometimes there is a better way. Case in point – consider using CSS instead of JavaScript to control visibility of out-of-the-box features you don’t want.

JavaScript – It’s In Our Blood

Before the introduction of business rules in Dynamics CRM 2013, developers used to use JavaScript all of the time to conditionally hide fields on the form. Even since then, if you want to hide entire tabs or sections, JavaScript is the way to go. Those familiar with the Dynamics 365 Portal offering know that it doesn’t respect business rules, and often we are wanting to hide elements on a portal that aren’t necessarily related to a CRM form. So if there is something on the page we want to get rid of, should we take the same approach?

In some cases, JavaScript is a great choice. This includes situations where the visibility of something is conditional (i.e. you want to build some logic that determines if a field is hidden or not). In this case, JavaScript would work well. However, if you’re simply trying to hide something all of the time (because maybe there is something that comes out-of-the-box that you don’t want to show users), I’d strongly recommend considering CSS.

Many CRM developers may not be overly comfortable with CSS – it’s not something you typically need to use a lot when working in Dynamics 365. While you may use JavaScript to perform custom business logic, Dynamics 365 usually handles the interface side of things, and you could go through many successful Dynamics 365 implementations without ever needing to write a line of CSS. However, this isn’t so true with the implementation of a Dynamics 365 Portal. As it is often a customer-facing tool, extra emphasis is placed on the interface. While the Dynamics 365 Portal product can handle a lot of the styling due to its use of Bootstrap, projects do, more often than not, require some sort of custom CSS.

CSS Classes Here, There, and Everywhere!

Thankfully, the way that the Dynamics 365 Portal product has been developed makes using CSS really easy in a lot of cases.

The Portal product team has done a great job of including CSS classes pretty much everywhere we’d need them.

As an example, let’s look at the Dynamics 365 Community forum post that inspired me to write this blog post. In this case, the user wanted to know how to hide the “Created By” area that appears when you display the notes related to a particular record on an Entity Form. The user was asking for some JavaScript to do this, but my first thought was to use CSS instead.

The markup used to display the note look something like:

<div class="notes">
    <div class="note" data-candelete="false" data-canedit="false" data-id="09044b2a-29f3-e811-a977-000d3af49bf8" data-isprivate="" data-subject="" data-unformattedtext="">
        <div class="row">
            <div class="col-md-3 col-xs-12 header">
                <div class="col-md-12 col-xs-3 portalcommenticon"><span class="glyphicon glyphicon-user"></span></div>
                <div class="col-md-12 col-xs-9 metadata">
                    <div class="postedon">
                        <div class="timeago" data-datetime="2018-11-28T16:17:57Z" title="11/28/2018 10:17 AM">2 days ago</div>
                    </div>
                </div>
            </div>
            <div class="col-md-9 col-xs-12 content">
                <div class="from">
                    <h5>
							Nicholas Hayduk
							<span class="glyphicon glyphicon-arrow-right"></span> SYSTEM
					</h5>
                </div>
                <div class="description">
                    <p>content</p>
                </div>
                <div class="">
                    <div class="createdby text-muted">Created by SYSTEM</div>
                    <div class="attachmentasync-1543600614644 attachment-loadmore-section"></div>
                    <div id="attachment-load-more" style="display:none;">
                        <div class="attachment-separator"></div>
                        <div class="row load-more-action"><a class="load-more-attachment-btn" href="#" data-total-records="0" data-page-id="1" style="display: inline; cursor: pointer;">Load more</a></div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

You can see that all of the various elements have class attributes which makes it easy to target them with CSS. In our case, they wanted to hide the “Created By” area, which we can see has a class of “createdby”. Therefore, the following rule should work to hide it:

.notes .note .createdby {
  display: none;
}

In this situation, I targeted the parent “notes” and “note” classes just to ensure my rule only applied to this area, in case the “createdby” class was used elsewhere.

After dropping that CSS rule in the Custom CSS attribute on the Web Page, the Created By section disappeared as expected.

As I said, the Portal product team has done a great job of including classes that make it easy to target elements we might want to change. This is most important for areas where we don’t really have control over the way functionality is rendered, like forums, idea, and blogs. By using the developers tools included in your browser, you can easily discover the class of the element you want to target.

As an aside, I wish that Entity Forms, Entity Lists, and Web Forms had Custom CSS attributes like Web Pages do. That way we could follow my best practice of always putting JavaScript/CSS is the most reusable place possible. As it stands now, if you have an Entity Form on more than one page, you’d have to copy the CSS to more than one page as well (or better yet, include a reference to a Web Template that contains the CSS in more than one place).

Why You Should Use CSS Whenever Possible

While in most cases whatever you do with CSS would also be possible in JavaScript (keeping in mind that a lot of these techniques in JavaScript are actually just applying the CSS for you, like in the example of hiding a field), I prefer to use CSS whenever possible because:

1. CSS rules take effect as soon as they are loaded – you don’t have to wait until the document is ready to apply them.
2. CSS rules are always on, and apply when new elements are added to the page, even after page load.
3. Once you get the hang of it, CSS rules are often simpler to write than the required JavaScript.

There are some other benefits (technically CSS is usually better from a performance standpoint, and it’s technically possible for users to disable JavaScript), however these aren’t issues we typically run into in the real world.

On the other hand, it’s true that with JavaScript you can remove the elements from the DOM instead of just hiding them, and that perhaps there may be some performance gains by having a smaller DOM, however in practical terms you’d need to be dealing with a lot of elements before this would have any noticeable effect.

Security Through Obscurity

Now, if you’re thinking of using CSS to hide fields because you don’t want users to see them for security reasons, stop right now. Using CSS only hides it from being visible on the page, but someone who knows what they are doing can easily use developer tools to see them. JavaScript suffers from the same problems – even if you use JavaScript to remove the DOM element, it’s easy for someone to see the value before it’s removed. This is because both CSS and JavaScript are client-side technologies, which means the information needs to be within the browser before you can do anything with it. And since a user can see everything that the browser has access to, the information is at least momentarily accessible.

Using CSS or JavaScript for security in this way is called security through obscurity, and is a bad idea. Security through obscurity means you use secrecy in place of real security, hoping that a malicious user doesn’t figure out what you’re doing. You should be handling security using a server-side technique (such as Liquid), which means sensitive data will never be visible to the user, even for a moment.

—

If you’re new to Dynamics 365 Portals and you don’t consider CSS to be a tool in your toolbelt, I strongly recommend that you invest some time in developing that skill – it will most definitely pay off!