CCS is worst language ever created
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
CSS the worst language? Surely not. There is BrainF*ck, or worse - VB & Javascript!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
It could have been much, much worse: The Languages Which Almost Became CSS - Eager Blog[^]
bjoernen wrote:
Why the decision to ... keep adding more bloat to it every year?
Because without that "bloat", we'd still be stuck using tables and spacer gifs for layouts, and fiddling around with transparent gifs for rounded corners or drop shadows. We wouldn't have tools like Grid Layout[^] or Flexbox[^]. We wouldn't have sticky positioning[^] or multi-column layout[^].
bjoernen wrote:
Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page?
So now you've turned your four hour project into a sixteen hour project, because you have to write the code twice, and test it in all the different versions of the browser implementations of your new system, as well as all the browsers that don't support it. (It's already bad enough if you still need to support browsers which don't support modern CSS layout, but thankfully those are vanishingly rare these days.) Plus every new browser needs to support both systems, since you can't reasonably expect every site on the internet to upgrade to your new system at all, let alone overnight. Which introduces more bloat, and more bugs, and more cross-browser inconsistencies. Or, more succinctly: xkcd: Standards[^] :)
-
It could have been much, much worse: The Languages Which Almost Became CSS - Eager Blog[^]
bjoernen wrote:
Why the decision to ... keep adding more bloat to it every year?
Because without that "bloat", we'd still be stuck using tables and spacer gifs for layouts, and fiddling around with transparent gifs for rounded corners or drop shadows. We wouldn't have tools like Grid Layout[^] or Flexbox[^]. We wouldn't have sticky positioning[^] or multi-column layout[^].
bjoernen wrote:
Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page?
So now you've turned your four hour project into a sixteen hour project, because you have to write the code twice, and test it in all the different versions of the browser implementations of your new system, as well as all the browsers that don't support it. (It's already bad enough if you still need to support browsers which don't support modern CSS layout, but thankfully those are vanishingly rare these days.) Plus every new browser needs to support both systems, since you can't reasonably expect every site on the internet to upgrade to your new system at all, let alone overnight. Which introduces more bloat, and more bugs, and more cross-browser inconsistencies. Or, more succinctly: xkcd: Standards[^] :)
Thanks for the link, interesting read. If PSL96 had been implemented instead, CSS would be a lot easier. You simply express sizes of things in terms of sizes of other things. It would have resulted in a much smaller language, that most people could grasp. And people would create libraries of handy expressions that accomplish the very same things that flex and grid does today. With the huge difference that you can look at the code and see what happens. Right now it is just a back box that almost no one understands. Browser support would be easier and more uniform, not harder, because there is a smaller feature set to implement. Do you know of any other language where there is so low predictability of outcome? You basically spend your time trying 100 different tweaks until it looks right.
Bjorn
-
Thanks for the link, interesting read. If PSL96 had been implemented instead, CSS would be a lot easier. You simply express sizes of things in terms of sizes of other things. It would have resulted in a much smaller language, that most people could grasp. And people would create libraries of handy expressions that accomplish the very same things that flex and grid does today. With the huge difference that you can look at the code and see what happens. Right now it is just a back box that almost no one understands. Browser support would be easier and more uniform, not harder, because there is a smaller feature set to implement. Do you know of any other language where there is so low predictability of outcome? You basically spend your time trying 100 different tweaks until it looks right.
Bjorn
-
Here's that BrainElephant one printing out it's own name:
++++[++++>---<]>-.---[----->+<]>-.+++[->+++<]>++.++++++++.+++++.--------.-[--->+<]>--.+[->+++<]>+.++++++++.
You can have that language & I'll keep my cascading style sheets thanks!
That looks like a snake game written by someone that hasn't figured 2D arrays yet...
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
bjoernen wrote:
simple math formulas into the CSS, that refer to the sizes of other elements.
The good news - since it requires some basic math skills we'd see a drop in the number of (so called) designers. The bad news - it's still potentially overly complicated and allows for possible feedback loops. My guess: if it worked as you wished you'd be making the same complaint.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
Agreed, it's a PITA and those that have mastered it are deep into the dark arts.
The less you need, the more you have. JaxCoder.com
-
bjoernen wrote:
For example "the width of this element should be equal to half the width of that element"
This kind of stuff is done using SASS (a CSS pre-compiler)[^].
I'm not talking about clever ways to generate complex CSS, I'm talking about expressing relationships between page elements that is not possible at all with current CSS. For example: "The height of element B is 1/10th of what ever the page height is at the moment. The width of element A should be equal to the height of element B, but only if B's height is less than 100px, in other case it should be half of the height of element B.". Here is how simple it could look in theory: B.height = PAGE.height / 10; A.width = B.height < 100px? B.height : B.height / 2;
Bjorn
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
bjoernen wrote:
by writing simple math formulas into the CSS
Like this[^], you mean? The
calc()functions in CSS are useful, potentially (though I've not used them myself) but they don't directly include the ability to refer to other elements. However you can refer to CSS custom variables which may give you the flexibility you want. But hey, all this is just adding more bloat, and making it harder to learn (and test for cross-browser compliance). The trouble is, the features you want are not the same as the features someone else wants - and pleasing everyone is what leads to bloat in the first place. :( -
I'm not talking about clever ways to generate complex CSS, I'm talking about expressing relationships between page elements that is not possible at all with current CSS. For example: "The height of element B is 1/10th of what ever the page height is at the moment. The width of element A should be equal to the height of element B, but only if B's height is less than 100px, in other case it should be half of the height of element B.". Here is how simple it could look in theory: B.height = PAGE.height / 10; A.width = B.height < 100px? B.height : B.height / 2;
Bjorn
-
I'm not talking about clever ways to generate complex CSS, I'm talking about expressing relationships between page elements that is not possible at all with current CSS. For example: "The height of element B is 1/10th of what ever the page height is at the moment. The width of element A should be equal to the height of element B, but only if B's height is less than 100px, in other case it should be half of the height of element B.". Here is how simple it could look in theory: B.height = PAGE.height / 10; A.width = B.height < 100px? B.height : B.height / 2;
Bjorn
The reason stuff like that isn't possible is because you will get endless recursion. Let's say you have:
The height of B is determined by the content of A, but if you are changing the width of A based on the height of B then the height of A will also change, which in turn forces the height of B to change, which would then require the width of A to change, which will once again change the height of B, and the loop continues until you get a StackOverflow exception. So perhaps you say: "Well, don't allow rules like that", but then you end up with even more of a headache trying to make sure your rules don't conflict with other rules. Put it this way, if it was possible to make it work well then it would for sure already exist. As the saying goes: if you have a good idea, it either already exists or it really isn't that good an idea.
-
No language has casued me more grief in my 30+ year career than CSS. It is almost like some form of black magic, where you can never be 100% sure what a page will look like. Even for the simplest designs you have to allocate 4 hours, just to make sure it looks the same in all browsers. Why the decision to write an enormously complex layout engine, and then keep adding more bloat to it every year? Why not let the page designer interact with the layout engine instead, as it is laying out the elements on the page? It could be done through JS calls, or even by writing simple math formulas into the CSS, that refer to the sizes of other elements. For example "the width of this element should be equal to half the width of that element". Then let the browser's layout engine simply be a multi variable equation solver. End of rant.
Bjorn
It's a language by committee. And a committee made up of teams that are actively competing with each other. Read this discussion on CSS4[^]. They actually, deliberately, don't want to increment the CSS version anymore. That's like macOS stopping at version 10 (...but instead is 10.1, 10.2 etc), and Windows 10 stopping at 10. Or 10 20H1, 20H2...) I think the hardest part of CSS is the "C" - the cascading, which relies on Specificity. It's super logical and very well defined. And an utter nightmare as soon as you step off the beaten track. Switch elements around, decide you need some special formatting, try and generalise it, and boom! Still - it does at least attempt to encourage a separation of layout and style. Except the CSS defines the layout :doh:
cheers Chris Maunder
-
The reason stuff like that isn't possible is because you will get endless recursion. Let's say you have:
The height of B is determined by the content of A, but if you are changing the width of A based on the height of B then the height of A will also change, which in turn forces the height of B to change, which would then require the width of A to change, which will once again change the height of B, and the loop continues until you get a StackOverflow exception. So perhaps you say: "Well, don't allow rules like that", but then you end up with even more of a headache trying to make sure your rules don't conflict with other rules. Put it this way, if it was possible to make it work well then it would for sure already exist. As the saying goes: if you have a good idea, it either already exists or it really isn't that good an idea.
musefan wrote:
As the saying goes: if you have a good idea, it either already exists or it really isn't that good an idea.
Luckily everyone doesn't think like that, otherwise all development would stagnate.
Wrong is evil and must be defeated. - Jeff Ello
-
musefan wrote:
As the saying goes: if you have a good idea, it either already exists or it really isn't that good an idea.
Luckily everyone doesn't think like that, otherwise all development would stagnate.
Wrong is evil and must be defeated. - Jeff Ello
A proper upvote for that!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
It's a language by committee. And a committee made up of teams that are actively competing with each other. Read this discussion on CSS4[^]. They actually, deliberately, don't want to increment the CSS version anymore. That's like macOS stopping at version 10 (...but instead is 10.1, 10.2 etc), and Windows 10 stopping at 10. Or 10 20H1, 20H2...) I think the hardest part of CSS is the "C" - the cascading, which relies on Specificity. It's super logical and very well defined. And an utter nightmare as soon as you step off the beaten track. Switch elements around, decide you need some special formatting, try and generalise it, and boom! Still - it does at least attempt to encourage a separation of layout and style. Except the CSS defines the layout :doh:
cheers Chris Maunder
Chris Maunder wrote:
that's like macOS stopping at version 10 (...but instead is 10.1, 10.2 etc), and Windows 10 stopping at 10. Or 10 20H1, 20H2...)
. . . . perchance to dream . . . .
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
musefan wrote:
As the saying goes: if you have a good idea, it either already exists or it really isn't that good an idea.
Luckily everyone doesn't think like that, otherwise all development would stagnate.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
Luckily everyone doesn't think like that
Indeed, most people don't even think at all... But I don't particularly agree that we only advance from unique ideas. I am sure a lot of people come up with the same ideas all the time, it's just who gets to market first, so to speak.
-
Jörgen Andersson wrote:
Luckily everyone doesn't think like that
Indeed, most people don't even think at all... But I don't particularly agree that we only advance from unique ideas. I am sure a lot of people come up with the same ideas all the time, it's just who gets to market first, so to speak.
musefan wrote:
who gets to market first
Word. Edison comes to mind.
Wrong is evil and must be defeated. - Jeff Ello
-
The reason stuff like that isn't possible is because you will get endless recursion. Let's say you have:
The height of B is determined by the content of A, but if you are changing the width of A based on the height of B then the height of A will also change, which in turn forces the height of B to change, which would then require the width of A to change, which will once again change the height of B, and the loop continues until you get a StackOverflow exception. So perhaps you say: "Well, don't allow rules like that", but then you end up with even more of a headache trying to make sure your rules don't conflict with other rules. Put it this way, if it was possible to make it work well then it would for sure already exist. As the saying goes: if you have a good idea, it either already exists or it really isn't that good an idea.
What you describe already happens in the layout engine of modern browsers. The rules that I outlined earlier already happen, but is invisible to us. There are hundreds of such rules that must be evaluated to produce the final layout, and some are in direct conflict with each other, so the engine is designed to make a compromise. These compromise heuristics is what avoids endless recursion. So imagine that tomorrow the Google Chrome team launches a new module called JSCSS, were they have moved out all those heuristics from inside the layout engine and written them in JS. From now on you point to a JSCSS file at the beginning of a HTML page, which defines all the CSS rules you intend to use. CSS still works exactly like before. But the HUGE difference is, now you can see how a flexbox actually figures out layout, AND you can extend CSS with your own definitions for things you think is better than the standard. AND you can omit CSS altogether, and write your layout directly in JSCSS of you want. This would be a huge relief for everyone, because browser makers only have to make sure the core layout engine works correctly, and every CSS definition is in external JS, exactly the same for every browser. And any developer can extend CSS with his own definitions.
Bjorn
