Herbert2001 wrote:
osgood_ wrote:
Herbert2001 wrote:
You must be aware of one major drawback when utilizing inline-block instead of floating elements: the way the code is formatted will have an impact on the gap width between each item. If the html code is minified, the distance between menu items will be reduced.
Not if you use margin. It also depends on what it is you want - a simple text color rollover works perfectly.
As you know l don't believe in Bootstrap for front end development or Less or Sass and l have no intention to corrupt code by minifying it.
It does not matter whether margin is used or not: a change to the code formatting may change the spacing between elements which are set to inline-block. Of course, whether this is acceptable or not depends on the layout and particular situation.
Of course, you 'pays your money' you take your choice. Choices are of course laced with opinionated reasoning and can lead to disagreements.
Herbert2001 wrote:
osgood_ wrote:
Herbert2001 wrote:
You must be aware of one major drawback when utilizing inline-block instead of floating elements: the way the code is formatted will have an impact on the gap width between each item. If the html code is minified, the distance between menu items will be reduced.
Not if you use margin. It also depends on what it is you want - a simple text color rollover works perfectly.
As you know l don't believe in Bootstrap for front end development or Less or Sass and l have no intention to corrupt code by minifying it.
It does not matter whether margin is used or not: a change to the code formatting may change the spacing between elements which are set to inline-block. Of course, whether this is acceptable or not depends on the layout and particular situation.
As for SASS and Less: for me the point of using these in projects is that I can write the same clean CSS in a much more efficient and maintainable way. For example: variables. I define my theme colours at the top of my SCSS file or in an include which I place at the top. Same for my base fonts. And other stylistic properties which are re-used throughout my layout. I then use the variables instead of the actual values. If I need to make a change to one or more of the stylistic properties of the layout, I merely have to change one or two variables, and the changes cascade automatically throughout the css file.
It is merely a more efficient method of writing the exact same clean CSS. Just having access to variables in your CSS means a more convenient workflow. I no longer need to search and replace colour values, or hunt down border settings throughout a css file. A simple variable change at the top of my code takes care of these changes.
Or when I create a grid: instead of having to copy 24 column classes, 23 push classes, and 23 pull classes, I use three simple for loops to generate that css for me. Just simpler, far more efficient, faster, and easier to manage as code.
And what about browser prefixes: SASS takes care of that for me, and it relieves me from the drudgery of having to check which properties require prefixes, for which browsers, and it keeps my code far cleaner, since I only need to add the generic property in my selectors.
In short, it made CSS fun again to code in for me.
I don't diagree with these 'observation', never have. In a controlled environment each and every observation you have made would be an advantage. What do you do in a situation where you have chosen this workflow and then the project gets moved on to another developer for a period of time (it happens to me on quite few ocassions) who changes the css file. When you get it back all your best laid workflow plans have disappeared. The issue I have with SASS and LESS is they complie to an 'independent' file. If browsers were ever able to read SASS or LESS like they can PHP then its not an issue for me. I'm thinking and planning for the long-term were some developers are only concerned with the next hour. There is going to be differences of opinion depending on how you conceive issues, that's clearly obvious. I'm happy for developers to have their FUN as you so succinctly put while I concern myself with the possibilities of the broader aspects of developement.
Herbert2001 wrote:
And as for the argument that you lose control with SASS: sure, may happen. We discussed this before. On the other hand, in my experience I have encountered the exact same problem with 'regular' CSS files: clean, nicely written easy to maintain CSS files were delivered to the client, and returned a year later to us after other developers had wreaked havoc in it - a complete mess.
Sure a css file can get messy in the wrong hands (I've just pointed that out in one post where a user has deployed a particulary ugly Bootstrap selector for no reason) but that can happen regardless of if you are using SASS or LESS. What I'm saying is a vanilla css file is a css file, it's not dependent on any other file which can quickly be rendered useless, then your prefrered workflow is impacted upon, greatly.
Herbert2001 wrote:
Sure, that is why I added the IE9 caveat. I agree that it may take one more year until we can use flexbox in production. Having said that, I already use it for mobile app development (I use Cordova to convert html/css/js app).
Floats are in truth a terribly limited and convoluted method for layout control and I cannot wait until we can finally remove them from my/our CSS - they were never meant to be used for page layouts. We have had to put up with those for far too long now. I await that moment in anticipation - as much as at the time when we could finally stop using tables for our layouts ;-P
We'll I'll certainly agree with all of the above.
Herbert2001 wrote:
As for Bootstrap: never really liked it myself, truth be told. I / we use it if and when the situation or client calls for it. Not against it, nor for it. It is merely a tool - a framework. The quality of any technology has never been a guarantee either for its success or its failure in any (human) industry. Fact is, it is one of the "standards" currently, and it has its use. Whether it is a poor solution, or not: often not very relevant in the discussion with a client, unfortunately (in my personal experience). Same holds true for all those PHP frameworks, and JS frameworks (angular, anyone?). If it works, it works - no matter whether the solution seems poorly implemented or terribly convoluted and over-complicated at heart.
That is how human civilization seems to work ;-) - not the best solution is generally chosen, but the 'good enough' (and more often than not the overly complex) one.
Anyway, nothing is black and white (but in the minds of many humans). CSS pre-processors have their use. So does Bootstrap. Personally, I feel it is a bit of a waste of energy and valuable life to be a-wasting on these type of "yes"<-->"no" discussions. Humans have a tendency to bi-polarize into 'camps'. All an illusion.
Just work with whatever tech suits you, your situation, and your workflow best. And appreciate the fact that others take a different approach, and respect them for it. And vice versa!
In any walk of life you have those that are 'craftsmen' and have the desire to take pride and produce solutions that are bespoke as opposed to those that are happy to use the quickest and cheapest methods available but are limited and lack quality.
Bootstrap was never intended for front end web developement so again its something being used as a hack in my opinion, much like tables were to construct websites. Then everyone suddenly accepted tables were a hack. Everyone eventually accepted that <div> soup was bad. Frameworks like Wordpress/Bootstrap etc generally create <dIv> soup and unnessary code but now that seems perfectly acceptable. I guess I can understand using frameworks in a situation that forces you into using them - maybe can't code, are working for a company whose only goal is to make money, have no real pride or interest in what you are producing, etc etc.