The future of Fix

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.

@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.