Category: User Interface

How to Easily Overlap HTML Elements Without Position CSS

Discover how to easily overlap HTML elements in one simple way by leveraging the power of the CSS grid layout.

Sometimes an approved user interface design requires us to overlap HTML elements. This article describes how to do this with just HTML and CSS using the CSS grid layout.

The primary aim of the examples in this article is to prove a point. They may meet your requirements with similar code but may not fit exactly.

HTML

Starting with the definition of the HTML, we need at least three elements: the grid container, the background element, and the foreground element.

<div class="grid-container">
  <div class="background">
    This is the background
  </div>
  <div class="foreground">
    This is the foreground
  </div>
</div>

The grid container wraps each of the elements that need to be overlapped. Meanwhile, the child elements have classes specifying where in the grid the browser should place them.

Thereupon we can control which elements overlap implicitly via the order of HTML elements specified in the grid container. Conversely, we can explicitly control them with the z-index CSS property.

CSS

Although the HTML has been defined, the CSS still needs to be specified. The CSS is more involved and includes detail about the CSS grid. Therefore, understanding these details will allow you to change this code to meet your requirements.

.grid-container {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr 1fr;
  grid-template-rows: 1fr 1fr 1fr 1fr;
  
  .background {
    grid-column: 1 / 5;
    grid-row: 1 / 4;
  }
  .foreground {
    grid-column: 2 / 4;
    grid-row: 3 / 5;       
  }
}

The Grid to Overlap HTML

The grid container specifies the definition of a 4 x 4 grid. I am using fr units for ease of use in this article. Your requirements may differ. Learn more about the flex value here: https://developer.mozilla.org/en-US/docs/Web/CSS/flex_value.

Firstly, a grid’s definition includes setting the display property to grid. Additionally, the grid-template-columns and grid-template-rows CSS properties define the rows, columns and their sizes. Learn more about CSS grid layout at: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout

Furthermore, we still need to specify where elements are placed within the grid. As an illustration using the CSS above, the background class positions an HTML element behind the foreground. Do this by setting the shorthand properties grid-column and grid-row to span more of the grid than the foreground.

To clarify, the grid-column property specifies the horizontal start and end edges of the HTML element within the grid.

Similarly, the grid-row property specifies the vertical start and end edges of the HTML element within the grid.

Remember: The grid’s edges start at 1, yet the end is one more than the number of rows or columns in the grid. We are specifying an edge not a cell.

In addition to the background class, we need to create the foreground class. The foreground class positions an element in front of the background element. Much like the background class, do this using the grid-column and grid-row properties.

Even though a requirement to overlap HTML elements can mean several things, adjusting the background class’s grid-column and grid-row properties can help position the background element to better match your requirements.

Overlap HTML

In summary, defining the CSS grid layout allows us to overlap HTML elements with just HTML and CSS. To that end, the grid-column and grid-row specify where each element is placed within the grid.

To demonstrate, the image below shows the grid lines from Google Dev Tools. You can see the 4 x 4 grid and the positions of the HTML elements.

See the grid lines and how CSS grid is used to overlap HTML elements
The grid lines and the position of the HTML elements.

See a working example using jsfiddle below or https://jsfiddle.net/asusultra/5cho1p2g/2/.

Note: You may notice that I use a few CSS properties for colors, height, and width. This is only for display purposes.

How to Manage an Ever-Changing User Interface

Discover a philosophy of user interface management leading to adaptable front-ends that exceed dynamic market requirements and the ever-changing user interface

The user interface is the window into the needs of a business. These needs should be driven by customers either internal or external. We’ll refer to these customers as the market. As market needs shift the user interface will need to change. A responsibility of a professional front-end developer is to design the user interface implementation to support this change. How do we manage an ever-changing user interface?

Identifying what areas of the front-end are most impacted is an essential first step in managing shifts in the market. As we know from Robert C. Martin or Juval Lowy, each of these areas is an axis of change. Considering the volatility of an area can help when designing the front-end to more easily adapt to change.

We’ll see that the user interface is never done and certain areas of the user interface will likely change more frequently than others. We will also consider how we could exploit the axis of change to deliver a user interface designed with enough fluidity in the right areas to more easily flow with fluctuating market needs.

Volatility Rating

Everything about the user interface will change. This means color, size, position, text, user experience, design – everything – will change. There is no judgment here. The user interface is encouraged to change if it better suits the market. However, there are some areas that will change more frequently than others and have a greater impact on the system when they do. Considering these areas is essential when designing the user interface implementation.

Frequency

Starting with a simple example, the look and feel of the user interface may change. If, for instance, the look and feel will always change, the frequency is 100%.

Another area that may be added or altered is a data model. When a user interface contacts a service, there is a contract that defines the data that will be sent between the front-end and the service. This is the data model. When the market decides it needs an extra field in a form, that it needs a “button here that does x”, or removing a column from a table, it means altering or adding a data-model. This has its own change frequency.

Determining how frequently an area will change will help determine its volatility and how to approach its design and the design of future changes.

Impact

The look and feel of the user interface may always change which is only one part of the volatility rating. The impact of a change needs to be considered. Areas that impact the entire system will have the most impact when changed. The impact of change is reduced as its impact on the system is reduced. An example of this can be found in a previous article titled The Monolith Component. While the article focuses on a malformed component, it describes the kinds of impact code can have. Considering the impact is an important part of deciding how to make a change.

Exploiting the Evolution

Some areas are innately difficult to alter, especially when they impact a website user interface as a whole – such as look and feel. There are common practices when dealing with something like this: use a CSS pre-processor to leverage common principles and practices such as OOCSS, BEM, and SMACSS. With the advent of Modular CSS and other principles and practices, managing the look and feel of a website is less painful.

There are libraries and frameworks that aim to make front-end development less painful. Yet, they can only go so far. It will depend on the use, the application of these helpful libraries and frameworks – let’s call this advantaged code. Leveraging advantaged code becomes dependent on the application of two concepts: continuous improvement, and designing for change. These concepts attempt to answer a fundamental question: How can I make it easier to manage new or existing code in an ever-changing user interface?

Continuous Improvement

As more is learned, more can be applied. The details of the code begin to be deeply understood. The areas of the code that change most begin to reveal themselves. And, of course, the impact on the system of each change has a greater chance of being measurable.

When learning these things about the user interface, and how it is impacted by changing market needs, the code can be continuously improved to anticipate those changes.

Design for Change

Designing a user interface for change is only valuable if the rate of change and its impact on the system are measured and deemed inevitable. This is to avoid unnecessary costs such as increased user interface complexity and reduced available budgets.

As the user interface evolves with market needs it should continuously improve in the areas where the rate of change and the impact on the system are high enough. What is high enough in terms of change rate and system impact is largely determined by project concerns – available time and budget, developer experience, accessible business knowledge, etc.

I am not saying all changes are valid – meaning, there are some cases when a change should not be made. A simple example of this is security. If a requested change will compromise the security of the application, it is a responsibility of a professional developer to say, “no” preferably with an amount of tact appropriate for your relationship with the market. And hopefully, there would be enough trust in the partnership that the market will thank you for looking out for them.

Excluding the requests that are detrimental to the system, by measuring the rate of change and the impact on the system, changes to the front-end can be more easily supported, maintained, and you may even welcome them.