Replies: 4 comments
-
Questions / clarifications:
Now is
I am actually against minification: with gzip and HTTP/2+ employed by CDN, the size/performance difference is very minimal, but it makes it harder to debug on production and harder to learn from it for other people. DHH said it well |
Beta Was this translation helpful? Give feedback.
-
Hi guys,
I shall express my thoughts once i find some time to read thru your
conversations. Assuming the weekend after new year. Speaking of a new year:
Wish you a happy one.
BR, Jakub
Dne čt 31. 12. 2020 17:00 uživatel jimmeak <notifications@github.com>
napsal:
… Basically I'd like to propose next. In the folder static we are tend to
keep our css files with one file that is non-changing with different skins,
and then we have in separate directories css files for each skin.
First, I propose to have a special directory css and special directory js
if need for javascript in the future.
Second, there is a possibility to have scss/less files (I think I prefer
scss, but only because I did not use less before). Locally we can have
automatized translation of scss into css files for each skin, so all
together we would have structure static/css/.css and this one file can
contain everything needed for the specific skin.
Advantages that I see in this approach are
- We can have multiple scss files with good structure, so for frontend
developers it would be nicer than having two css files and having to search
for everything in those.
- There is only one local css file that can be minimized.
- Easier input from developer.
Basically it could be also good for some future development. The time to
redoing the structure in this case is 30 minutes work top, I believe. We
could eve do it with Wynn in our crusade to learn HTML & CSS. Not
necessarily now, but let's say in three months when the exam time will be
over.
What you guys think? @Almad <https://github.com/Almad> @ArpixTalker
<https://github.com/ArpixTalker> @Lumine220 <https://github.com/Lumine220>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#138>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANGSZVRPKVGPRZXK6LN36WDSXSNYDANCNFSM4VPQ7FVQ>
.
|
Beta Was this translation helpful? Give feedback.
-
I am not sure how to write it correctly, so I created this schema:
It's not final, that's just and idea, but basically this is the idea for all frameworks that exist and are successful. The projects are bigger than this website, but with this type of structure it should be really easy to edit later and easier for new developers to start with. My main idea is to make it more pleasant for the developer.
I do not have any special opinion to doing min. I just like how it looks. I am actually not sure why to debug css with this structure, it is just a file for the browser and the developer's tool can work with it well. Working with files you wouldn't need ever to open the css file.
Basically we can use many tools for this. But there is Django-sass-processor [1] that runs automatically and it is able to work with node_modules, vendor (I am not sure if we will use those, maybe for some jquery or sth like that, that's really not something I can say, but it's good to know that there is this possibility). [1] https://github.com/jrief/django-sass-processor : I am not sure about the Django version compatibility. |
Beta Was this translation helpful? Give feedback.
-
IMHO it's way overblown given the amount of CSS on the site, but sure, go ahead.
Sure, I am just trying to not add more tools just because since there's already quite a bit of learning curve, but I am not principally against if it helps. The django-sass-processor looks good, works for me 👍 |
Beta Was this translation helpful? Give feedback.
-
Basically I'd like to propose next. In the folder static we are tend to keep our css files with one file that is non-changing with different skins, and then we have in separate directories css files for each skin.
First, I propose to have a special directory css and special directory js if need for javascript in the future.
Second, there is a possibility to have scss/less files (I think I prefer scss, but only because I did not use less before). Locally we can have automatized translation of scss into css files for each skin, so all together we would have structure static/css/.css and this one file can contain everything needed for the specific skin.
Advantages that I see in this approach are
Basically it could be also good for some future development. The time to redoing the structure in this case is 30 minutes work top, I believe. We could eve do it with Wynn in our crusade to learn HTML & CSS. Not necessarily now, but let's say in three months when the exam time will be over.
What you guys think? @Almad @ArpixTalker @Lumine220
Beta Was this translation helpful? Give feedback.
All reactions