Inline file wrapping changed

2019-09-30

This blog post is aimed at developers.

When inlining (rendering) files, they are by default wrapped in a <div> so that the Frontend Toolchain can identify it and provide selection, drag-and-drop, contextmenu support, etc. out of the box.

That div structure looked like this:

<!--- THIS IS NOW OUTDATED! -->

<div class="o1-file o1-inline" data-o1-path="//example.com/path">
    [...file specific HTML code...]
</div>

It is a single div to add minimal bloat to the HTML structure of the page. At the time this was introduced, the options available in CSS were much more limited than they are today. To make sure that file can be properly highlighted on pages (that is, with the correct size), I made a very opinionated decision to set the CSS rule on them:

/* THIS IS NOW OUTDATED! */

.o1-inline {
    overflow: hidden
}

This means that the element can not display anything outside the boundaries of its box. This allowed us to force elements into their containing divs which allowed to greatly simplify working with them. This gave you the impression that you were editing the real thing, not using some clunky editor that was thrown at it as an afterthought.

On the other hand, it required some deep changes to how user interfaces were developed. Some classic UI solutions became impossible or overly complex.

As time passed and CSS 3 became widespread, I could finally revisit the decision.

New file wrapper

The new solution uses the flexbox layout to force HTML blocks into their containing divs. This removes all the limitations on how UIs are designed which is an important improvement.

<div class="o1-file o1-inline" data-o1-path="//example.com/path">
    <div>
        [...file specific HTML code...]
    </div>
</div>

And the accompanying CSS:

.o1-inline {
    display: flex;
    flex-direction: column;
}

On the flip side, it requires 2 levels of divs to achieve it which greatly bothers the artist in me. It was no easy choice but functionality has to trump code aesthetics. (And most developers probably don’t care anyway.) I hope some future CSS solution will let us get rid of the extra div. (For avoidance of any doubt, this has zero practical downsides, it’s purely code aesthetics.)

We can finally use shadows, tooltips and popovers all over again. Yayy!


Cheers,

Subscribe to our newsletter!