In this article I want to share my thoughts regarding responsive design. I made several talks on this subject and this post is some kind of summary. The article presents concepts like mobile first and design in the browser.
By definition :before and :after are CSS pseudo elements. You can use them to insert something before or after the content of an element. There are some great articles giving the basics, but I wanted to write down a blog post for the real use cases. Or, at least, to show what I'm using them for.
These days I'm working on this little thing. It's a CSS micro framework following atomic concept. My preprocessor of choice is SASS. That's why I wrote several articles on this subject. Today's post is about media queries mixin.
Before a couple of weeks I published Techy. It's a flat CMS based on Node.js and Markdown. I made it because I wanted to write my articles in Markdown format and avoid the annoying publishing workflow which I'm using now. I feel that it's not very clear how Techy works and decided to create a simple blog illustrating the processes.
We all know what responsive means nowadays. We, as developers, normally develop responsive applications. There is a dozen of instruments helping us achieving our goals. Some of us use extensions and even pay for them. However, I'm using one thing - Google Chrome browser. In this article, we will see what the Chrome's capabilities for testing responsiveness are.
Every front-end developer that starts reading about CSS preprocessors thinks “Oh, finally variables in CSS". Indeed, the ability to create and use variables in CSS makes our code much more flexible. However, I think that there is no need to use a preprocessor to create flexible stylesheets.
One of the things that I really like at work is the fact that we spend time in research tickets. We have unknowns and we make a research to find out more information on particular topic. We then base our decisions on the results. Recently we had to decide whether to use an
<iframe> for a third party widget development. I feel that the collected information may be handy to someone else so I decided to write it down here.
Long long time ago in a kingdom far far away there was an app. The app was supported by the well known React and Redux families but there was a problem. It was damn slow. People started complaining and the app had to do something. It had to deliver its content quickly so it provides better user experience. Then the server-side rendering was born.
I ❤️ markdown. I like its simplicity and minimalistic API which is good enough to cover most of needed HTML markup. At least for textual content. At work we have a small node based microservice that delivers data from Contentful in exactly markdown format. It's all working well but we started having cases where part of the text is in Contentful and the other part is in that microservice. For example when we have a button with a catchy design. We want to content manage the label of the button but the actual markup to be on our side.