English: fat

英 文 : Bole online – coagulation maple

Link: http://hao.jobbole.com/mediu-css/

Click → To learn how to join a columnist





Whether it’s temperament, dress or behavior, I always want to be the best I can be. Even what I put in the trash is better than what other people put in the trash.


– Lil Wayne


Here’s how we optimized Medium’s CSS, step by step, and get a glimpse of how we got there and where we’re headed.


First Acquaintance stage (a little history)


I joined Obvious about two years ago, working on product development for Medium.com. By then, Medium had already gone through a series of “redesigns” (meaning that designers had completely overthrown the previous scheme and rewritten a lot of CSS/LESS/SASS, etc., to make the design more beautiful). It is because of these “redesign”, but more dross – a lot of reliance on LESS language features, not using Sprite or HD technology processing image materials and other bad habits.


I pulled out the old page and put up a configuration page to take a look at what we were missing from the old version:


  • All elements are nested in a class named.profile-page, with no components available (almost all class names are prefixed with.profile);

  • The variable name is super meaningless, like @link-color, which does not know what element it is associated with, but seems to only appear in profile-page.less.

  • Too deep nesting (like.profile-page.profile-posts.home-post-summary. home-post-collection-image img should not appear);

  • Image call without CSS Sprite technique;

  • Z-index, fonts, colors, etc…


https://gist.github.com/fat/a4af78882d0003d2345e


Stage one: Big picture, big picture


At that time, I knew a lot about code libraries (Bootstrap, Ratchet, etc.), and after learning them all, I tried to write the best CSS I could with these tools. The Medium CSS at the time was not only completely different from those codebars, it was so poorly formed that I had to find a way to fix it.


Your first task is to organize your image resources. I remember, it was 2012 and the old version didn’t use Sprite technology at all… There were hundreds of images, placeholders, arrows, ICONS, all in the /img/ directory. It was like a graveyard.


To get rid of the image clutter, I did two things — first, I wrote a little CSS feature script called SUS (we still use it, I open-source it here) with the help of Guillermo Rauch, The effect is to extract images from the stylesheet and lazily load them into separate data-URI files. I’m not original with this idea, I just think this script is more appropriate here.


The second thing I did was Geoff Teehan and I designed the first icon font in Medium’s history. Back then, we had no idea what we were doing… With the help of Iconmoon (a github blog post), and a couple of nights later, we were able to design Medium to look aesthetically pleasing. That’s a big improvement — not only do we save a lot of space by deleting 97 percent of the images in our gallery, but the improvements make them look much better on my Retina MacBook Pro.


The second stage: scale setting


The next important task is to solve the Z-index property. This guy is poorly trained and easily out of control, and he always drives me crazy at the end of the day, and I don’t want to do that on Medium.


Before the change, the code was littered with all kinds of confusing z-index values. You couldn’t imagine z-index: 5 following z-index: 1000000, Z-index: 1000001, z-index: 99999 or something like that, I have no idea how to sort through all this clutter. So I had to make the difficult decision to manually review all the Z-index values in the entire code base. Later, I introduced an internal scale (written in the internal file z-index.less) that limits the values of components that use z-index to 1-10. I’ve linked all the z-indexes in the code base to this scale, so you can see how different components are now located at different levels (and it’s easy to use).


The following z-index file is the current version of Medium.com:


https://gist.github.com/fat/1f6da6b3bd0311a1f8a0


Of course, we also use this method to scale z-index for color (black, gray, white, brand color, etc.) and font (font size, weight, spacing, height, etc.). You may also notice that these variable names use more rigorous and semantic values, which we’ll get into later…


Stage 3: New style guide


Not long after phase 2, we started another major redesign — codenamed “Cocoon.” The Cocoon project overturns several of the old journaling templates (Medium wasn’t just a single article template; it initially offered images and quotes as well) and introduces journaling lists instead of journaling “cards.” We ventured to take a step back and wrote a new style guide for Medium.


For a long time, we focused on developing a major upgrade with CSS/LESS:


  • Limit the use of LESS variables and mixins (not nesting, guard, extend, etc.) — while these languages are powerful, they can be tricky for LESS experienced developers. We prefer the visuals (and uniformity) of Pure CSS and plan to optimize the code base in that direction.

  • Write Class and ID in lowercase letters, separated by dashes — that’s what most of us do with frameworks like Bootstrap, Skeleton, Ratchet, and so on, and the same applies here. Another reason is that CSS has its own property names in this format, such as border-radius-top-left, and it always makes sense to follow them.

  • Component level over page Style – try to think of front-end development as a code base made up of multiple components, breaking a page whole (like profile.less) into small, specialized code snippet files (like button.less, dialog.less, Tooltip.less, etc.).


To view the full article, please click:


https://gist.github.com/fat/b27700946c777adacdf4


This may not be true for all development, but it helps clarify some ground rules that you can’t go wrong with.


However, even after this style upgrade, many colleagues still seem to have trouble using it and are still confused about when to create components and when to create child components. Of course, we do get silly occasionally and call the class names inappropriate, such as. Nav-on-light-background-button or. Button-primary-sidebar -over-blur.


Instead of “page” as a prefix to “class”, there’s a long list of random words separated by dashes: Button-primary →. Button-primary-dark →. Button-primary-dark →. Button-primary-dark → . The button – primary – dark – the container – label… It’s so long, I can barely read it.


Stage 4: Blueprint


Now, I started writing Medium’s internal code with the lofty goal of becoming “the best site in the world.” Although I do not know whether this will succeed, BUT I am sure, at least we are in the right direction in the effort.


… Everyone was confused. To make matters worse, I thought everyone was good at writing CSS, but they weren’t.


So I started looking around for solutions — tweaking frameworks, trying different tools, turning to philosophy, asking friends and friends of friends… Finally came to a conclusion, proposing three main areas of improvement that needed to be broken down one by one:


  1. Introducing new CSS variables, mash-ups, and class names to improve readability and avoid arbitrary selection;

  2. Ditching LESS for Rework, which has better mash-up support and a syntax more similar to Vanilla CSS.

  3. Using tools to improve CSS performance (starting with things like load time, frame count, layout time, etc.) makes it easier to track and trace style changes.


Stage 5: Semantic improvement


Given the small size of our team, it would have been easier to implement if we had a specification, so I wanted to make the semantics in the code more strict. Also, I want to make the rules more complex so that people will be more careful when creating new classes. Anyway, I just want to avoid arbitrary naming, if not at least make it more difficult.


I had a long conversation with my friend Nicolas, and after several nights of discussion, I was finally convinced by his SUITCSS drawing that was similar to mine but slightly better. I threw away the old style specification, borrowed from him, and tweaked some of the details to form our current style. The main additions are:


  • The JS class selector name is prefixed with.js-;

  • Single function class names are prefixed with. U -, such as. U -underline,. U -capitalize, etc.

  • Meaningful hyphens and humps were introduced to emphasize the separation of component, subcomponent, and modifier names.

  • The name of the state class (usually controlled by JS) is prefixed with.is-disabled, for example.

  • Use new CSS variable name rules: [properties]-[value]–[component];

  • Muddling occurs only when there is a last resort and can only be prefixed with.m-.


For the full text of the style specification click:


https://gist.github.com/fat/a47b882eb5f84293c4ed


Copying and modifying a new style scheme is easier than rewriting all the CSS code. I’d like to thank the company for supporting this project, and I hope I didn’t make the wrong decision – if you’ve been following the progress of our project, you know that putting together the new CSS specification is only a small part of our work. The code rewrite was a catharsis, cleaning out styles that were no longer needed, breaking large files into smaller features and simplifying the site. Of course, templates were refactored — more parts were encapsulated, and semantics were tightly controlled. Like now, instead of having hundreds of <IMG> tags and random avatar class names, you can use a uniform avatar template that triggers different modifiers such as size, style and so on via Boolean values, making it much easier to manipulate and much less prone to detail bugs.


Phase X: What does the future hold?


There is no doubt that we have changed dramatically since we were two years ago. Working on CSS at Medium has been a lot of fun with people with different experiences. However, performance optimization will be the next step. I will continue to add new ideas and notes later in this article, and you can see how important it is to choose reliable layout measurement and performance rendering tools… I didn’t realize that in 2014.


It’s a miracle you made it through here. Thank you for your patience. Finally, thanks to Katie, Dave, Mark, Koop, Kristofer, Nicolas and other friends for their help, without you, there would be no success ❤


Translator introduction (click to join the columnist)

Condensing maple: atypical programmer, love to do some and write programs irrelevant things