<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1639164799743833&amp;ev=PageView&amp;noscript=1">
Diagram Views

How to Keep Your Ektron and Episerver Projects Looking Sharp

Nick Melville Front End Developer
#Episerver, #Ektron, #Responsive Design
Published on August 22, 2017
warren-wong-323107-unsplash-1

Our teams use a lot of tools and techniques to build, repair, strategize, and analyze. We want your web project to run seamlessly, look sharp on any device and present your company as industry leaders.

Our teams use a lot of tools and techniques to build, repair, strategize, and analyze. We want your web project to run seamlessly, look sharp on any device and present your company as industry leaders. One of the best ways to achieve this is to begin with Responsive Web Design. Responsive Web Design adapts the website to always display properly on devices and browsers of differing sizes. Currently, there are two techniques to ensure that your website responds flawlessly on any device: media queries and element queries.

Media queries, the most common method, start with the content on a narrow screen width and introduce breakpoints as dictated by the content as the screen gets wider. For example, on a narrow screen, most content is presented in a single column, but when the screen is wide enough, secondary content may move up next to the main content in a smaller sidebar column. This breakpoint should occur when it benefits the presentation, such as to prevent overly long lines of text. Unfortunately, the process ends up not being as simple as adding a breakpoint when a line of text reaches the desired maximum length. If the implied breakpoint should be at, say, 760 pixels wide, what happens at 761 pixels? If the layout changes to have a sidebar, suddenly, the main content area is significantly narrower than it just was, so the line length will have gradually increased to the desired maximum, then, at the 760 pixel breakpoint, it jarringly jumps back to a narrower width. Ultimately, breakpoints based on the width of the screen have to make compromises about how to display different content types and how to them in such a way that, while not always ideal, isn’t ever broken.

Element queries aim to remove the need to make those compromises by directly adapting the content to its container. While a media query says “if the screen is wider than a given size, apply these various CSS rules to all of the elements specified”, an element query would say, “if the content container is wider than a given size, apply these CSS rules to just it.” That is to say, changes would only apply to the single element of content being evaluated for the given characteristics, ignoring all other elements and device characteristics. Continuing the example from above, instead of using a site-wide breakpoint to try to constrain line length, an element query could just add an automatically increasing right margin above the maximum width so the lines of text don’t continue to increase. Or center the column of text, or increase the font size to keep roughly the same number of characters on a line, or split the text into multiple columns, etc. When individual elements are being evaluated and affected with element queries, they allow the content itself to always be presented in the best way possible.

One very popular methodology of building responsive websites is Atomic Design, championed by Brad Frost. The general idea is that by building components from smaller discrete elements, an entire design system can be developed that results in a very cohesive design and predictable user experience. This approach can, however, be difficult to implement when building a site on a CMS, as it can be difficult to anticipate how content that can be placed virtually anywhere will be used and also ensure it will always be styled correctly. Element queries make a modular methodology like Atomic Design easier to implement because, when utilized correctly, they ensure that individual pieces of content will always display in the best fashion, regardless of where and how they are used on a page.

Currently, element queries are not directly supported by any browsers as they are not part of the World Wide Web Consortium (W3C) specifications, so the only way to utilize them is through JavaScript plugins. Relying on JavaScript is less than ideal as, at best, it isn’t as performant as native browser technologies, and, at worst, could take a moment to apply the changes or not apply them at all in an unsupported browser or if JavaScript is disabled. The choice to use them or not should weigh these limitations against the potential benefits. If they are used, at this point in time, they should be used with the mindset of progressive enhancement where any benefit they provide is merely cosmetic and isn't required to view the content.

Despite some of the current limitations implementing element queries, they are an excellent option to help ensure responsive websites, especially those that have modular content, consistently display content in the best way possible.

Whether we are working in a Content Management System like Ektron to get custom results for your content, or migrating content from Ektron to Episerver for greater content personalization, or helping you leverage a Marketing Automation Platform, like HubSpot, we use the best industry tools and techniques to help you meet your goals. Have you used element queries before? Let us know in the comments below or over social media.