Very recently the team at decided to migrate our blog from Medium to . If a bag-of-words analysis were run on transcripts from conversations we had around why to do this, the primary representation would encompass SEO and related jargon. Nevertheless, our lead designer has since poured many hours into building on Webflow - as well as migrated every post over to their CMS. 8base Webflow a beautiful new blog ‍Only once all the work was done did we realize that Webflow CMS has no support for code blocks 🤦‍ ‍This wasn't trivial for us. As we're gearing up for the launch our new 8base Tutorials project (coming soon!) and often publishing blogs that demonstrate - with code - all the awesome things you can do on , displaying properly formatted code both in-line and as blocks is a must. 8base Hopefully, Webflow is going to give some special attention to the CMS after its latest and most significant round of funding. Every other aspect of their product either flirts with or embodies awesomeness. So why would we anticipate anything less for the CMS? That said, we had to come up with another solution in the meantime. Moreover, as is the case with most problems, they're rarely unique to the person experiencing them! A quick search on the interwebs, and you'll find a blog post on daily detailing the same problem and proposing a solution. With all due respect deserved to the author, his solution wasn't one we felt comfortable using. puts def publish (solution = ) "our own!" "So, we came up with " #{solution} end Defining Custom Tags I'll keep this explanation short and sweet, in the spirit of the solution itself!‍ Firstly, we defined two simple custom tags. The tags are an ERB + HTML style mash-up that allows for the easy denotation for when a code example starts and ends. Originally, we attempted at using HTML style tags ( ). However, they were being escaped and just led to a messier script. <> In-line Code {% c-line %}shell command --options-maybe{% c-line-end %} Code blocks {% c-block language="js" %}
function logMessage(msg) {
    var preText = "New Message: "
    console.log(preText+msg)
}

logMessage("Multi-line code blocks are important.")
{% c-line-end %} Adding Highlight.js Many solutions advised using Prism for syntax highlighting. Reading through their docs, it just felt like overkill. So instead, we landed on . What's great about Highlight is that it allows you to style code to reflect a preferred text editor theme easily. Meaning that if you're a fan of Sublime Text 3 or Atom, code samples can be highlighted using editor themes. Highlight.js So, we added the following inside our Blog Post Template tag. The script tag loads the Highlight.js library and the first link tag imports syntax highlighted CSS styling for all supported languages while the second one imports the [Atom One Light editor theme](https://highlightjs.org/static/demo/).‍ <head>...</head> < = > script src "https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.9/highlight.min.js" </ > script < = = = > link rel "stylesheet" type "text/css" href "https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.9/languages/css.min.js" < = = = > link rel "stylesheet" type "text/css" href "https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.9/styles/atom-one-light.min.css" Writing the Script By default, Webflow requires jQuery and makes it available globally. This allows us to use it in any custom script that we choose to add to our page templates. Naturally, the same thing could be accomplished using Vanilla JS. However, using jQuery felt just a bit tidier.‍ $( ).ready( { $( ).each( {
    $(el).html(el.innerText.replace( , ))
  }) $( ).each( {
    $(el).html(el.innerHTML.replace( , ))
  }) $( ).each( { codeBlock.removeChild(codeBlock.childNodes[ ])
    hljs.highlightBlock(codeBlock)
  })
}); /* Run when the page has loaded*/ document ( ) function event /* This formats all the inline code examples. */ 'p:contains("c-line"), li:contains("c-line")' ( ) function index, el /{\%\s*c-line\s*\%}(.*?){\%\s*c-line-end\s*\%}/gi '<code class="inline-code">$1</code>' /* This formats all the code block examples. */ 'p:contains("c-block"), li:contains("c-block")' ( ) function index, el /{\%\s*c-block\s*language=[\"|\'](.+)[\"|\']\s*\%}(.*?)\{\%\s*c-block-end\s*\%}/gi "<pre><code class=\"$1\">$2</code></pre>" /* Run Highlight JS on every code block */ 'pre code' ( ) function index, codeBlock /* Remove first child <br> */ 0 So, there are a couple of important things worth noting. The script executes on the event. $(document).ready() The selectors return all DOM elements that contain the specified tag. $("HTML_TAG:contains('CODE_TAG')") The Regex statement(s) match the custom opening and closing tags with proper HTML tags and preserve the language attribute - for the block - and all inner text. Once the DOM is updated, the resulting code blocks are highlighted using the Highlight.js function. hljs.highlightBlock() ‍We decided to forgo using syntax highlighting on the in-line examples. Instead, we added a custom inline-code class to the template that's independently styled. Additionally, we didn't like the extra space ( tag) that gets added to every code block. This is why we added the line. <br> codeBlock.removeChild(block.childNodes[0]) In Summary As soon as Webflow updates their CMS to support either Markdown or native code blocks, we'll likely scrap this solution that we just shared. That said, we're pretty happy with what we came up with for its the readability and maintainability! Feel welcome to use this strategy yourself and let us know how it works.

Funding

Friends 404 | 8base 301

Read My Stories

How To Add Code Blocks in Webflow CMS with Language Highlighting

You’re a North Korean engineer who’s been selected to develop a new government project. It’s an HTML form, which North Korean political leaders will fill in for purposes. [REDACTED] One of the fields requires the user to select the title by which they prefer to be addressed. , you decide to go for your good old > element. It looks like this on Windows (Chrome): Since the list can get pretty long <select Nothing out of the ordinary, perfectly acceptable in most cases. You know that . But you're not sure if the is aware of this. You feel like this is not too big of a deal, as long as the list is in alphabetical order. <select> has that kind of "search" that jumps to the items as you type Great Leader What about mobile? This is how it looks on Android (Chrome): Android tries to use as much of the screen as possible, covering the address bar. Here it is on iOS (Safari): On iOS, the small number of visible items makes for an awful experience with larger lists. Both of them lack a way to search or filter list items. Will the look the other way? Not wanting to take any chances, you take this matter into your own hands. You want something that can be filtered on mobile, and makes better use of screen real estate. Father of the Nation On desktop platforms this is not too hard to achieve: just a custom dropdown with a text input for filtering. For mobile, you’ll need something different. Let’s focus on the mobile version, and presume that you’ll have some way to pick the correct implementation depending on the platform. This is your plan for mobile: A full-screen modal with a fixed text input at the top for filtering, and a scrollable list of items below it. Your first instinct tells you the implementation should go like this: Select a title X Item 1 Item 2 < = > button onclick "openModal()" </ > button < = = > div class "modal" id "modal" < = > div class "modal-header" < = = > input type "text" id "filter-input" < = > button onclick "closeModal()" </ > button </ > div < = > div class "modal-body" < > button </ > button < > button </ > button  </ > div </ > div { : none; : fixed; : ; : ; : ; : column;
} { : flex;
} { : ; : auto;
} .modal display position top 0 left 0 height 100vh flex-direction .modal .show display .modal-body flex 1 overflow-y modal = .getElementById( ) filterInput = .getElementById( ) {
  modal.classList.add( )
  filterInput.focus()
} {
  modal.classList.remove( )
} const document 'modal' const document 'filter-input' ( ) function openModal 'show' ( ) function closeModal 'show' The important bits: to fix the modal to the screen; position: fixed to make the height 100% of viewport's; height: 100vh Modal divided in two parts: header and body; Header’s height defined by its children, no need to set it explicitly; Body fills the remaining height with ; flex: 1 : auto in the body to make it scrollable when the list doesn't fit. scroll-y Works as expected on iOS: But on Android the last items are being cut off: Why? Some mobile browsers hide the address bar when the user scrolls down. This changes the visible viewport height, but not the meaning of . So actually a bit taller than what is initially visible. 100vh 100vh Your modal has , so you don't need to use units. will fill the available height correctly: position: fixed vh height: 100% Neat! This is already an improvement from the native versions of on mobile. Now you need to implement the filter behavior. <select> You’re pretty sure that your wouldn’t want to go through the trouble of having to touch the filter input every time after opening the modal. So you should the filter input as soon as the modal opens. This way, the keyboard pops up and the user can start typing right away. Guiding Sun Ray focus() Everything looks good on Android: On iOS, the modal header is scrolled out of bounds once you try to scroll the list: What’s going on? When you filter by “Leader”, the list becomes small enough to fit the screen without scrolling, but only if the keyboard isn’t visible. On Android, opening the keyboard shrinks the viewport down to the visible area. But . iOS lets you scroll the page while the keyboard is open, revealing that missing portion of the page. This behavior can break elements like yours. on iOS, the viewport size remains unchanged; it is just being covered by the keyboard position: fixed To make matters worse, there’s no way to know how tall the keyboard will be, or if it is there at all (the user can be using a hardware keyboard). No clever CSS trick can save you this time. So you need to have a scrollable list, where all the items are accessible, without knowing if an arbitrary portion of the lower part of screen is visible or not. This is your workaround: You add a spacer at the bottom of the list (highlighted in green for visibility). The height of this spacer is the height of the list area, minus one element. This way, it’s always possible to scroll all the way to the bottom, bringing the last element to the very top of the list. There are still ways to make the modal scroll outside the viewport, and you need to patch them. One way is by swiping on any non-scrollable elements currently visible. In your case, that’s the modal header. You can’t just disable all pointer events through CSS, since you need the inner elements (filter input and close button) to still be usable. The solution is to disable scrolling on events: touchmove header = .getElementById( )

header.addEventListener( , event => {
  event.preventDefault()
}) const document 'modal-header' 'touchmove' The default reaction to is scrolling, so blocking that with preventDefault() will make it unscrollable. touchmove Now let’s take a small detour. I’ve been writing these examples in HTML + JavaScript to make the article a bit more universal. But I came across this spiral of workarounds while developing in React. This is how I define my event handler in React: {
  event.preventDefault()
} <Element onTouchMove={handleTouchMove} /> ( ) function handleTouchMove event // … The expectation might be that in plain JavaScript, this would translate to something like this: element = .getElementById( )

element.addEventListener( , event => { }) const document 'element' 'touchmove' // call the callback for this element But what happens is closer to this (not real code): .addEventListener( , event => { element = React.getElementFromEvent(event) }) document 'touchmove' const // call the callback for this element React binds the events at the document level, instead of binding them at the level of each individual node. Here is what happens when I try to touch events in React: preventDefault() The browser blocks it. , and those can’t be blocked with at the document level. The solution is to bind the event manually at the node level, instead of doing it through React's event system: This was introduced with a Chrome update that made events be “passive” by default preventDefault ref = React.createRef();

componentDidMount() {
  ref.addEventListener( , handleTouchMove)
} {
  event.preventDefault()
} <Element ref={ref} onTouchMove={handleTouchMove} /> 'touchmove' ( ) function handleTouchMove event // … So yes, particularly in React, this workaround requires a workaround. As I write this, , so the problem may no longer exist by the time you read this article. React’s event system is being rewritten Now back to problem. your There is one more way to scroll your hopes and dreams away. If the user insists on scrolling when there are no more items to show, the viewport can be scrolled up. None of this fazes you anymore, you just jam another workaround in there: modalBody = .getElementById( )

menuScroll = { (modalBody.scrollHeight - modalBody.scrollTop === modalBody.clientHeight) {
    modalBody.scrollTop -= }
}

modalBody.addEventListener( , menuScroll) const document 'modal-body' => () if 1 'scroll' You push the list’s scroll position one pixel away from the edge when the scroll reaches the bottom. This way, the outer scroll is never triggered. The solution is already pretty solid, but there is one more thing you’d like to improve. The modal suddenly covering the screen might be a bit jarring. What if isn’t paying attention and gets spooked? Who will take care of your kids? His Excellency A simple transition animation could make it easier to follow. Perhaps you could slide the modal from the bottom of the screen? Easy to achieve with CSS transitions: { : flex; : ; : top ;
} { : ;
} .modal /* ... */ display top 100vh transition 500ms .modal .show top 0 Now, instead of initializing your modal with and , you start it already with , but pushed outside the viewport with top: . When the modal is set to visible, it will scroll smoothly to the top of the screen. Let's see the result on Android: display: none top: 0 display: flex 100vh Android behaving well again! And now on iOS: iOS blasts the modal to outer space as soon as it is visible. It seems like toggling the keyboard while the modal is being animated isn’t a good idea. You feel pretty confident that showing the keyboard only after the animation is done should fix it: {
  modal.classList.add( ) setTimeout( {
    filterInput.focus()
  }, )
} ( ) function openModal 'show' // new => () 500 Simple enough. You wait for 500ms, the same as the transition duration, and only then you the input to make the keyboard pop up. You tell yourself that you'll clean this up later, maybe using events or some fancy library, instead of relying on the values being consistent between JS and CSS. But you know it won't happen. The result: focus() Now iOS doesn’t seem to be focusing the input at all. Of course, it couldn’t be that easy. , and isn't that. Your workaround is to turn the "Select a title" button into a text input: iOS only allows focus events to happen as a direct result of a user interaction setTimeout < = = = > input onfocus "openModal()" readonly true placeholder "Select a title" The hides the caret and makes sure the user can't type anything into this new input during the transition. This way, iOS will show the keyboard based on the first focus event, allowing you to change the focus to the second input after the transition is done. readonly And it works! You’re finally done. You feel proud of your work, knowing your family will live at least another couple months. Find the full code for the modal here

HackerNoon Tech Stories Archive September 1st, 2019

How To Add Code Blocks in Webflow CMS with Language Highlighting

@sebastian-scholl
Sebastian Scholl

In North Korea, Front End Devs Face Platform Inconsistencies That You Might Not Know Even Existed

@raicuparta
Ricardo L

HackerNoon Tech Stories Archive September 1st, 2019

How To Add Code Blocks in Webflow CMS with Language Highlighting

@sebastian-schollSebastian Scholl

In North Korea, Front End Devs Face Platform Inconsistencies That You Might Not Know Even Existed

@raicupartaRicardo L

@sebastian-scholl
Sebastian Scholl

@raicuparta
Ricardo L