3 ms·

which is odd since a lot of css "frameworks" are now back to promoting inline css. https://acss.io/ https://acss.io/ I like this idea, but I wonder how long i

which is odd since a lot of css "frameworks" are now back to promoting inline css. https://acss.io/ https://acss.io/ I like this idea, but I wonder how long it would take my brain to think like this.

ehnto 10y ago
That is crazy. Why make it an entirely new syntax with an entirely new lexicon? Bgc () instead of background-colour? I feel like new people keep entering the web field and forgetting all the lessons learned from the (very very recent) past. The inline approach might work for a small site. But in that case, why use a pre-processor at all and why would you need config objects? CSS doesn't need to be rocket science. If you want atomic CSS then leverage CSS and style the base elements, it's actually pretty good at what it does. Edit: I may have misinterpreted it's use case, I am all for compenent based styles. I still think there is no need for a pre-processor of inline styles with a completely new lexicon. If you are already in the context of a component you already have the beauty of a scoped and simplified CSS workspace, why make that so much more complicated with a new build pipeline and completely new syntax and lexicon?
- gkya 10y ago
  I wonder how much of those entering The Web Field have any formal education on CS and CS history, and to what extent most of them know the tools at their hand (HTML, JS, CSS, Standards, HTTP(S), browsers, other programming tools, etc). It seems to me that most of the professionals in the sector are actually paid amateurs with shallow knowledge of their own fields. This leads to reinvention of tools for that are at most on par with the existing tool chain.
  - blauditore 10y ago
    I have a similar impression; and based on the people I've met, it's somewhat accurate. People with higher education in CS I know tend to go more towards full stack or back end work, while web front end devs often are career changers. The entry barrier for web technologies is just rather low. This is probably the main reason for Node's huge growth in the past years: It's just the path of least resistance to get into back end development.
  - jinglebells 10y ago
    "The Web Field" is a pretty big group but if you mean "Front end web" then people with a background in graphic design or content creation (writing/video) are probably not going to have much formal CS history. There _are_ people who are good at both visual design and computer science, but not as many as designers who learned enough to code what they needed to.
- bartread 10y ago
  Yeah, it feels like somebody's taken some sensible advice from the HTTP 1.1 era too far. (I realise we're still very much in the tail end of the HTTP 1.1 era.) Putting styles needed to render your above the fold content inside <head> is a sensible thing to do, assuming you've been able to restrain yourself by not animating the buggery out of everything, and have kept your stylesheet small. It saves a roundtrip to the server or CDN that will block your content from rendering. Putting all your styles inline? Sheer madness. Inventing your own syntax to do it? Even worse. The whole thing with CSS is, used well, it does actually reduce page weight vs. old skool HTML table and element based styling. You lose all that if you start bunging all your styles inline. Still, I suppose if your page is already 4 #@<£ing megabytes because of all the crap you've cargo-culted in, maybe it doesn't matter so much. </snark>
lmm 10y ago
I've been saying for years, once we stopped hand-writing HTML there was no reason to use CSS, at least in the "cascading" sense. Whatever generates your content should generate the styling - HTML is already a presentation form, and you already have a component that renders your semantic content into HTML for view.

which is odd since a lot of css "frameworks" are now back to promoting inline css. https://acss.io/ https://acss.io/ I like this idea, but I wonder how long it would take my brain to think like this.

ehnto 10y ago

That is crazy. Why make it an entirely new syntax with an entirely new lexicon? Bgc () instead of background-colour? I feel like new people keep entering the web field and forgetting all the lessons learned from the (very very recent) past. The inline approach might work for a small site. But in that case, why use a pre-processor at all and why would you need config objects? CSS doesn't need to be rocket science. If you want atomic CSS then leverage CSS and style the base elements, it's actually pretty good at what it does. Edit: I may have misinterpreted it's use case, I am all for compenent based styles. I still think there is no need for a pre-processor of inline styles with a completely new lexicon. If you are already in the context of a component you already have the beauty of a scoped and simplified CSS workspace, why make that so much more complicated with a new build pipeline and completely new syntax and lexicon?

gkya 10y ago
I wonder how much of those entering The Web Field have any formal education on CS and CS history, and to what extent most of them know the tools at their hand (HTML, JS, CSS, Standards, HTTP(S), browsers, other programming tools, etc). It seems to me that most of the professionals in the sector are actually paid amateurs with shallow knowledge of their own fields. This leads to reinvention of tools for that are at most on par with the existing tool chain.
- blauditore 10y ago
  I have a similar impression; and based on the people I've met, it's somewhat accurate. People with higher education in CS I know tend to go more towards full stack or back end work, while web front end devs often are career changers. The entry barrier for web technologies is just rather low. This is probably the main reason for Node's huge growth in the past years: It's just the path of least resistance to get into back end development.
- jinglebells 10y ago
  "The Web Field" is a pretty big group but if you mean "Front end web" then people with a background in graphic design or content creation (writing/video) are probably not going to have much formal CS history. There _are_ people who are good at both visual design and computer science, but not as many as designers who learned enough to code what they needed to.
bartread 10y ago
Yeah, it feels like somebody's taken some sensible advice from the HTTP 1.1 era too far. (I realise we're still very much in the tail end of the HTTP 1.1 era.) Putting styles needed to render your above the fold content inside <head> is a sensible thing to do, assuming you've been able to restrain yourself by not animating the buggery out of everything, and have kept your stylesheet small. It saves a roundtrip to the server or CDN that will block your content from rendering. Putting all your styles inline? Sheer madness. Inventing your own syntax to do it? Even worse. The whole thing with CSS is, used well, it does actually reduce page weight vs. old skool HTML table and element based styling. You lose all that if you start bunging all your styles inline. Still, I suppose if your page is already 4 #@<£ing megabytes because of all the crap you've cargo-culted in, maybe it doesn't matter so much. </snark>

lmm 10y ago

I've been saying for years, once we stopped hand-writing HTML there was no reason to use CSS, at least in the "cascading" sense. Whatever generates your content should generate the styling - HTML is already a presentation form, and you already have a component that renders your semantic content into HTML for view.