Websites That Break (Sometimes): Dev
Tags: webdev, frontend, design, ux
Published: 2020-06-14 12:59:16

**Note:** This articles contains GIF which might take some time to load.

Welcome to *Websites That Break (Sometimes)*, a series of post where we take a look at *Frontend Design* of popular websites and find out *why they break, sometimes*.

For the first post, I'll be taking about the **Write a new post** section of our beloved [dev.to](https://dev.to)

### The Problem

Let us take a look at the *Write a new post* section's *New Post Title* field when we land on it

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/s26xrq5wr3f6fggyfr5z.PNG)

Everything looks great and exactly as Developers expected. Next thing I do is click on the the tile field to write a title for my new post and surprisingly this happens

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/e4pin5ep76soxfqi7g7v.PNG)

A major part of the initial placeholder is clipped vertically. This happens hand in hand with any focus event. Let me show you what I mean

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0rfbsnfmkgo61gqbtbg1.gif)

Here, I click on the post body, yet, the title field shrinks. Hence we can say with a good confidence, this is linked to the click events or the focus event on *Tile*, *Tag* and *Post Content* fields

### Is this a rule defined wrongly in the StyleSheet?

This is not a problem in rule defined in StyleSheet but rather linked to JavaScript loaded by the *New Post* page.

How did I reach this conclusion?


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/q267ha7cov9tfb3r74vu.gif)

In the above GIF, we can see for the first few seconds when the page is still partially loading according to Firefox, everything works as intended but soon after a quick re-render, the issue pops up.

Let us open the *Network Monitor* to see if we can spot something specific.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/egywsadf4pii3941zula.gif)

As we can see, the issue corresponds exactly with the transfer of a JavaScript chunk and the editorial hints at the side of input field begin to appear.

Now before we say something about Firefox, let's take a look at Chrome

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/uuc67kadifetccnsnti0.gif)

The behavior is identical. So we can say with good confidence, this chunk that is responsible for toggling hints is also responsible for causing this problem.

**Note:** I couldn't find any evidence of JavaScript in the particular chunk that could set the height but I have a possible cause listed in the *You have spotted the problem?* sections below.

### Analyzing CSS changes and a possible fix

Turns out, there is a **height** rule changes when the Click event is sent.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ga4nh5aytvhjfo3i3hlk.gif)

As we can see, the height initially *60px* (first drops to *38px* on a narrow viewport and then) drops down to *27px*

A simple fix would be find the cause for setting *27px* and change it to *38px* for smaller viewport and *60px* for larger viewport

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/iki9s1xpdc3r9ret4iyj.gif)

Another possible fix is to reduce the font size of the *Title* but I'll leave it up to the decision by the developers.

### You have spotted the problem?

Dev.to is [open-sourced on Github](https://github.com/thepracticaldev/dev.to) and the component for the *New Post Title* can be found [here](https://github.com/thepracticaldev/dev.to/blob/master/app/javascript/article-form/components/Title.jsx) on Github. The component used *preact-textarea-autosize* for the *input* area. From the Inspector, we can see the height is an inline CSS property that is changed programmatically. No evidence of an inline style can be found in the *Title* component and hence it might have something to do with the underlying library used to render the input field.

If you had a similar problem that you fixed, please leave a Pull Request on the project, helping in development of [Dev](https://dev.to/), a wonderful platform for sharing knowledge, one that gets sweeter by the day.

### Test Environment

No frontend web development report is complete without specifying the platform and the browsers you have tested it on. In my case, I face this issue on both Windows and Manjaro [GNU/Linux].

I can reproduce this issue on both Firefox(77+) and Chrome(83 and Canary - 85). I use a display with resolution *1920 X 1080*.

All the screenshots and GIF provided above were recorded on Windows on Firefox Nightly and Chrome Canary.

Thank you for reading the first installment of *Websites That Break (Sometimes)*. I write this post with the intention of highlighting the process of detecting a frontend issue and going in depth using Developer Tools available in browsers to help the website developers by giving more information about the problem so they can fix it easily and quickly.