The future of Fix

[ghost]

Hi Jayden,
I really like this approach, do you plan to update - improve the code for this year? For example: basic style for the form elements.
Thanks :)

[jaydenseric]

Thanks for the kind words :) This project is in an interesting place... The crowds seem to love it in it's current form more than I do, and seem to be using it in a different way than I intend.

What the people want

People want an alternative to reset or normalize that they can drop into their project as a stylesheet and build on top of. This is where I began. If we were to embrace this we would:

• Add some more styles for things like form elements. This is harder than it seems, as almost any global style is opinionated and wasteful or inconvenient some of the time.
• Make Fix easier to install in projects properly via Yarn or NPM. This is kind of tricky, because:
  • The future is CSS in JS. Stylesheets are already dead for many of us.
  • How to handle vendor prefixing? Every project with stylesheets should be using Autoprefixer with a custom browserslist config. Do we distribute the stylesheet with vendor prefixes for an arbitrary level of browser support, or ship only proprietary rules prefixed?

My vision

I have come to the conclusion that all global styles are undesirable; each component should style itself from scratch. This has worked wonderfully for me on many projects for over a year now, and is not as audacious as it seems.

My vision for the project moving forward is more of a CSS guide for each element. To achieve this, almost everything would be deleted but the readme, which would be structured with a heading and a bullet list of gotchas/code snippets for each element. This would be useful to every dev, whether they use stylesheets or CSS in JS.

I have to triage my time, and to be real, I have neglected Fix because it no longer solves a problem I have. Enhancing it from this point is altruistic as all the gotchas and code snippets are burned in my brain and the project is not meant to be an installable dependency.

I hesitate to do both options at once, build out the stylesheet and maintain an element CSS guide in the readme. In my experience mentoring developers is as much sharing what to do, as it is enforcing what not to do.

[garrettw]

While we're discussing vision and usage, I might as well mention that I've created my own reset/normalize thing called Vitals which is partially taken from Fix (among other sources).
The biggest difference is, I haven't really defined a vision for my project; I just made it to suit my own needs, and it will evolve as my needs evolve. Or maybe I'll figure out a vision for it eventually -- who knows.

[ghost]

@jaydenseric Thanks :)

[LiTiang]

Hi, @jaydenseric, i feel confuse about u respond above

I have come to the conclusion that all global styles are undesirable; each component should style itself from scratch.

and also this one

to be real, I have neglected Fix because it no longer solves a problem I have.

I want to ask:
If u need to use font-awesome,
or SASS var file (a .scss file that include many var declaration)

for such dev situation i just stated,
u still think u dont need global styles ?

And what the situation that u can neglect the Fix usage ?

NOTE: i find out there is a discussion about using component with global css

[jaydenseric]

@LiTiang Font Awesome is not so awesome for a bunch of reasons. The best way to manage icons these days is with polyfilled SVG with external references. A component's icons live as symbols in a single .svg file within the component's folder: Example. The component styles the icons from scratch, no need for global anything.

Sass is dead. Everyone needs to run their stylesheets through PostCSS to get Autoprefixer to work. you can configure PostCSS to do everything Sass can but in one parse, skipping the Sass compiler. Features such as variables now have a spec and are available natively in browsers. Until browser support is universal, start getting used to the new syntax and use CSSNext. This is in line with the Babel JS transpilation approach, as language features start to work natively you can start to run source code directly in browsers without refactoring.

In my experience creating tangled relationships between components by attempting to centralize config or mixins is not necessary. Each component can have its own variables; avoid sharing. A common example of what not to do is creating variables such as $darkBlue for color values. Just use values directly.

Take a look at this site I built, the entire stylesheet is 5kb down the wire. You can see the source CSS with variables and all for each component by inspecting the styles in Chrome and clicking the little links that look like index.css:50.

Edit May 2017: The link above now redirects to a new website, my example has gone to code heaven.

[garrettw]

@jaydenseric very informative, thank you. I didn't know Sass was on the way out.

[LiTiang]

@jaydenseric, awesome info !
it's a best info for me in 2017 !

So u mean that u will not use such $darkBlue variable in a component file ?
that's, u will use color: blue instead color: $darkBlue, right ?

And u dont use fix.css right now ?
if u dont, how do u solve the problem which the fix.css solved ?

[ymhsu2017]

@jaydenseric
At now, i know the benefit of component usage in frontend
i have experience on Angular, Vue, and i also use Autoprefixer,
reset.css (or normalize.css) in my project
BUT, u said :

I have neglected Fix because it no longer solves a problem I have.

I also confuse as @LiTiang that how can u neglect Fix in your project ?
How can u dev with component without using Fix.css ?

[jaydenseric]

Before

1. Add a global stylesheet like Fix, reset, or normalize.
2. Style components.

After

1. Style components.

[LiTiang]

ok, @jaydenseric,

i think i understand about what u said . . .

---

u JUST DONT USE Fix when u dev with components such pattern

although component is just nothing,
these guys will be compiled to pure javascript

e.g.

In Vue,
we coding with component file such like : header.vue
and of course it will be compiled to just javascript

In Angular,
the file become header.ts,
also, it will be compiled to javascript as well

---

so i still dont know if u dont use such global css,
how can u reduce browser inconsistencies ?
(remember the component is just a pattern)

so confuse for me . . .

[equinusocio]

The future is CSS in JS. Stylesheets are already dead for many of us.

The future is not CSS-in-JS. Is just a temporary non-standard trick made by javascript developers (not css developers). The future is the standard shadow dom with native incapsulated CSS. Now supported by all webkit browsers and chrome-blink. The future is CSS custom-properties, style-hooks and CSS native mixins. The future is made by standards, not libraries. Libraries like babel, polymer etc, just allow us to use futuristic features right now.

A part of this, i'm with you @jaydenseric.

@LiTiang If you need to fix a component, just put the fix, and only the fix he needs, inside his scoped code. You don't need a global fix that fix a component that may not exist in the page. The component fix itself when exist.

[jaydenseric]

@equinusocio Some good CSS-in-JS solutions use vanilla CSS and JS; perfectly valid and in line with web standards. Foolproof web components with scoped CSS and SSR are a while off or may never arrive. Either way, global styles are dead. In both approaches styles apply to individual components.

At this time, every developer should be a "JavaScript developer". Lots of standard web features like the canvas and history APIs can only be used via JS.

To jump right into the new-school, checkout Next.js. It's very good. The bundled CSS-in-JS solution, styled-jsx, works a lot like the deprecated <style scoped>. This approach however can never work on certain single-element components (such as img), because the style tag must adjacent to the HTML it is styling, within a container. I think glamorous might be a winner, it is a more efficient approach to the immensly popular styled-components API.

[equinusocio]

Web components are here. With Polymer 2, HyperHTML, vdom, etc..there is no difference, you can use WC right now with your favourite library and just polyfill some browser (youtube is built on Polymer and use style-hooks to customise components). But, yes, global CSS is now a thing to avoid in 2017.

What i don't like of CSS-in-JS is that you don't write CSS at all. You write a pseudo css-like javascript object and you cut off a lot of CSS potentiality, like css custom properties, custom media queries (if you use postcss cssnext) and many other things. I just think that CSS is a great markup language if you know it and how to use it (think like scoped css, BEM, ECSS, SMACSS, ITCSS etc) and you should keep write CSS, not a js object. For that reason, i like css-modules that allow you to write real CSS, and i don't like to hear "CSS-in-JS" when you don't write CSS. Call it "style-in-js" maybe.

I agree with you that now CSS should be inside his component whatever library you use. But i like standards, because now i can pick my postcss code and put it everywhere. You can't do the same with a CSS-like javascript object.

[jaydenseric]

Polymer apps can't be server side rendered (see #3955), React apps can.

You could put CSS variable support in CSS in JS solutions, and maybe you already can, but there is no reason to. Since the CSS starts in JS, you can skip that whole process and just generate the styles you want from the start directly from JS variables. A large appeal of the CSS variables API is that it can be interacted with via JS.

[equinusocio]

Ah sure, but as you said, you generate CSS from JS, you don't write CSS in JS. The point why generate CSS from JS if you can write directly a better and encapsulated css? By the way polymer is just a library that extends web components API by adding some "cool" helpers, Polymer != web components. You can use web components and shadow DOM with HyperHTML, viperHTML (for server rendering), SkateJS (that will support SSR), JSX or any virtual DOM library.

PS: We are off topic? 😂

[jaydenseric]

@equinusocio To avoid an essay response to those questions (which will probably lead to more), I think you might find this article helpful.

With CSS in JS you are in fact writing CSS. Most of the current solutions don't use inline styles anymore like Radium did, they generate a stylesheet in the <head> with exactly the styles needed to render the components on the page. If you prefer writing CSS as a template string instead of via objects (at the expense of a bigger bundle) you can choose to use something like styled-components. You can even use stylelint on your styles.

With styled-components you are guaranteed not to have a single unused CSS selector on any given page, which a huge architectural improvement over traditional stylesheets which commonly result in up to 90% unused styles, and a lot of cascading overrides.

[equinusocio]

@jaydenseric But why i see only stupid example like:

const Title = styled.h1`
  font-family: Comic Sans MS;
  color: blue;
`

and never something like:

const Card = styled.div`
  font-family: Comic Sans MS;
  display: flex; /* <- This should be autoprefixed, but how? */
  flex-flow: column nowrap;
  user-select: none; /* <- This should be autoprefixed, but how? */
  background: linear-gradient(
    to right,
    rgba(248,80,50,1) 0%,
    rgba(241,111,92,1) 50%,
    rgba(246,41,12,1) 51%,
    rgba(240,47,23,1) 71%,
    rgba(231,56,39,1) 100%);
`

Where i should put a @keyframes animation and how i can autoprefix properties?

[jaydenseric]

@equinusocio These questions are answered in the relevant project readmes. All the popular CSS in JS solutions automatically vendor prefix, so just write standard rules. @keyframes depends on the library. For me, as I use styled-jsx a component would look like this:

const Banner = ({heading, text}) => (
  <aside>
    <h1>{heading}</h1>
    <p>{text}</p>
    <style jsx>{`
      @keyframes enter {
        0% {
          opacity: 0;
          transform: scale(0.95);
        }
        80% {
          transform: scale(1.01);
        }
      }
      aside {
        animation: enter 0.25s;
      }
      h1 {
        color: red;
      }
      p {
        color: blue;
      }
    `}</style>
  </aside>
)

In my editor, the styles are nicely syntax highlighted. The enter animation name is automatically namespaced so that those keyframes, like the selectors, only apply to the scope of the component.

[equinusocio]

This is a nice solution. Here i have a real and scoped CSS and i can accept that. This is the nicest solution. One question, what do you use to highlight a css inside a template string? My VSC editor handle that as a string so is monocolor.

EDIT: With vscode-styled-jsx i cand o the trick. This is awesome, if i will work inside this context styled-jsx will be the key.

[jaydenseric]

@equinusocio I use Atom with language-babel, configuring JavaScript Tagged Template Literal Grammar Extensions to "(?<=<style jsx>{)|(?<=<style jsx global>{)":source.css.styled. It looks like this:

[equinusocio]

You can also import css as external? Web components needs style and js in the same place of template. ATM we build the component by combining style.postcss, index.js and view.tmpl.html in one view.html file. You can integrate postcss?

[jaydenseric]

See vercel/styled-jsx#83. To save everyone's inbox, lets keep further conversation focused on the original issue.

[equinusocio]

The future of fix.css? :)