I would like to take this opportunity to confess that I was baffled by the use of the term float in CSS since inception. I vaguely thought it must have something to do with layers and you would float an image to the top layer.
It only occurred to me recently that float actually meant float from a 2d point of view. As in a side view of an aquarium, you attach float to an object, and it goes to the top of the tank, displacing water along the way. You can float it left, and right, etc... goes to the left and right of the top of the aquarium. Things line up at the top if you float multiples, etc.
I don't know if that is an appropriate analogy or not, but it seems to fit for me.
> A floating block in writing and publishing is any graphic, text, table, or other representation that is unaligned from the main flow of text. Use of floating blocks to present pictures and tables is a typical feature of academic writing and technical writing, including scientific articles and books. Floating blocks are normally labeled with a caption or title that describes its contents and a number that is used to refer to the figure from the main text.
> […]
> Floating blocks are said to be floating because they are not fixed in position on the page at the place, but rather drift to the side of the page. By placing pictures or other large items on the sides of pages rather than embedding them in the middle of the main flow of text, typesetting is more flexible and interruption to the flow of the narrative is avoided.
I always thought that was its original purpose. And it is its effect in its purest form --- when you set the float property and nothing else. (Using it to lay out a page in columns, as the article mentions, usually takes juggling other properties, like margin, width, etc.)
CSS is probably the language that I’ve been using for a long time without exactly knowing how these things like float exactly work. Instead, I’ve often used a copy and paste or test and browse approach to get layouts I wanted.
I'm quite sure that English is the language that I've been using for the longest time without exactly knowing how it exactly works!
Or metaphorically I don't know exactly how English works when it decomposes so gracefully as it is capable of doing.
Is there any kind of equivalence in programming languages like this? I mean theoretically is it possible to design or possibly write code such that it is capable of imprecision and yet compiling to equivalent instructions?
(I realize I may simply lack the formal language to describe what I mean, but if by virtue of any fortuitous inherent redundancy in my question, a passing expert may recognise their field and be willing to guide me, I shall be most grateful.)
Thanks for the honest admission! Totally agree. I really feel the fragile mystery of floats and they way they operated is what drove so much adoption for CSS frameworks. It's true today that you can do more complex layout without any type of framework. But understand that for a period it was so much easier to use tested approaches than to battle the edge cases.
Rightly or wrongly, I always thought of it as being the (since deprecated) IMG align=left|right attributes' behaviour promoted for use by other elements.
It has his meaning in tiling window managers (where a floating window is in another layer, usually above the others), and probably in window managers in general. I'm curious if there are other examples.
Excellent! This is from the same author as "Modern JavaScript Explained For Dinosaurs"[1], that article got me much more closer to understanding the insane world of modern frontend development, I would recommend it to any other "dinosaurs" like me.
I'm very excited about modern CSS, I grew up in the crazy world of floats and the transition to responsive, new concepts like flexbox and grid are much more sensible approaches to layout design.
I doubt it's ever coming but to really separate layout from content requires the layout tree and the content to be separate trees. Right now there's effectively only 1 tree, the DOM and CSS for the most part is just meta data on that tree.
GRID requires things to actually fit a grid. If your grid isn't easily divided you add nested grids. But once you nest grids you can no longer seperate layout from content since the nested grid tree (layout) and the DOM tree (content) are tied together.
I wrote an article[1] about this. It's aimed towards intermediate CSS peeps trying to understand how to organize CSS. It focuses on BEM mostly but still offers a decent look into managing CSS
Thanks for the link, good and useful article indeed. What I miss from it though is an explanation of how to debug bundled or transpiled code. I am aware of the existence of source maps, but I've never used them. Until I am able to debug my code efficiently with source maps I cannot adopt bundling nor transcompilation for my projects. Does anyone have a good quality article or video that explains this?
I never used them myself but i thought the point of source maps was that the major browsers understand them; you load them in the browser on command, and can then debug from there, as you would normally with unbundled code
I grew up with floats and clearfixes, and while flexbox does a few things I couldn't do before I still find myself pulling up the flexbox cheat-sheet to get the correct syntax every single time.
It delves deep into the underlying concepts for CSS layout as described by the spec. I think layout is the hardest part of CSS, as changes can potentially affect the whole page, so it's worth studying the fundamentals.
It was written before grid was a thing, but it does cover flexbox.
I do wish CSS layout was easier to understand. Perhaps CSS grid will change this as it becomes widely adopted.
So much of CSS seems like a square peg trying to fit into a round hole.
That's because it pretty much is. CSS standardization and implementation has been significantly lagging what people want to do with it, so people have had to resort to hacks for a long time.
For instance, early versions of CSS were only really designed for formatting a single column of text, with possible floating images and tables. There was nothing in CSS designed for global layout; but people eventually found that you could use floats for that purpose, which was hacky but worked.
The first tool actually designed for global page layout is CSS grid, which has only recently been implemented by the latest versions of all of the major browsers. In the intervening time, you have also been able to use layout: table and flex-box, both of which give you some of the things you want but aren't quite designed for it, so the peg shape has been getting a little closer but not quite there until grid was implemented.
So for 20 years or so, people have been using tools not really designed for their jobs; there's been a lot of work at hammering those square pegs into those round holes.
Of course, now people aren't just looking to lay out static sites; rich, desktop-style web apps are a thing. flex-box is a tool for doing traditional GUI style layouts, but there's still nothing available for CSS modularization allowing rich controls to be built without being affected by other global page styles. There is a work in progress; web components and shadow DOM, but as of now that's only available in Chrome and in development in Firefox.
Anyhow, it's getting better, but it is still lagging behind what people are actually doing substantially. I think that with CSS grid, plus all of the other functionality that now exists, it would be a lot easier nowadays to have design tools which could generate fairly reasonable CSS, but I don't know of tools that take advantage of this yet.
You've still got to deal with the fact that some browsers support some aspects of CSS Grid, some you have to fall back to Flexbox which doesn't work in the same way and you'll still use some grid system based around floats or display:table to capture everyone. More choice of ways to do the same thing, some very useful media queries, but most of the rest of it could have been done equally hackily in the late 90s.
If IE6 was bad, the fact that we're on the third or fourth generation of different implementations of CSS layout aiming to reproduce common layout styles achieved with HTML tables in the 90s and still need javascript polyfills to use them on non-autoupdating browsers still in widespread use is ridiculous
I'm intentionally not learning CSS Grid until it has good browser support. That way I only need to keep one thing in my head at a time, and I don't need to write a bunch of fallbacks. I did the same thing with Flexbox.
> My complaint is that when I am doing regular desktop development, I can wear all 3 hats only consulting designer ocassionally.
Yes but that's only because you have experience doing desktop apps. As someone who does web for a living, you have no choice but to learn and master front-end.
I can wear the three hats while doing Web but couldn't doing desktop because I have no experience doing that.
> For one there is no software tool that can let someone visually move elements around and still produce reasonable CSS.
Indeed. CSS was never designed to be worked with in a visual design tool. There are so many intricacies in its rules that the only way to create a sensible interface is to paper over the majority of the potential of CSS and make everything absolutely positioned, for example. This of course results in crappy bloated sites we love to hate.
In almost every case, I find that people who struggle so with CSS are those who do not have a proper understanding of either CSS or HTML. They do not know or understand the "box model". They will even state they are unaware of validating (error checking) either and some even openly state they see no purpose in it.
This kind of tech writing — the historical/anthropological - especially wrt web tech is far more helpful to me than the technical & how-to docs etc.
Just knowing why things are creates a much better context for me to place the knowledge, understanding and appropriate use for each property/feature etc.
I completely agree. I went down the rabbit hole a few months ago and started reading some of Dennis Ritchie's papers on his home page. I particularly liked the C history linked below. I found it interesting around how the limits of the memory drove creation of things like the ++ an -- operators. Limitation being the mother of invention it's amazing, at least to me, how far we have come in such a relatively short period of time.
As someone coming to web development from iOS development, CSS is the only thing I've really been struggling with. I just have such a hard time working with a model where changes aggregate around so much, so changes intended for one place end up messing something up elsewhere. Maybe I'm just not using it right? To me it just seems much saner that components (and the styling thereoff) are by default completely isolated from each other and their parents and children, and styling is only shared where you explicitly request it. Maybe this is due to the historical roots, where CSS is intended to style documents rather than apps? Maybe it's in the same category as JavaScript in that it's easy to hack something together that sorta works, but it takes a lot more overview and discipline to create something sane and maintainable? And where there are a ton of online resources that are outdated or will teach you bad habits?
> changes intended for one place end up messing something up elsewhere. Maybe I'm just not using it right?
CSS selectors allow you a really wide latitude in the applied scope of the styles you specify -- you can literally pick everything (with the asterisk selector), or you can pick only one thing (with an id selector). With an almost arbitrarily fine-grained set of possibilities in between.
A project could take a component centered approach, with unique id and/or class names for every component and only using selectors that begin rooted with those id/class names (the unique names thing can be harder with a large team than it should be -- I've sometimes thought that rather than a CSS preprocessor, I could use a smart linter that can take some comment hints and manage problems like this better).
Or you could moderate that a bit with a reasonable core set of global styles addressing typography and baseline margins/padding and a few layout concepts, and go component from there.
And then follow two heuristics: when you find you're playing whack-a-mole, you probably do have too many overlapping broadly scoped styles. If you're repeating yourself over and over again (or even relying heavily on a preprocessor to repeat yourself), you might be better served by a more broadly scoped selector.
If this doesn't describe your approach, maybe you are indeed just not using it right. :) (And welcome to the club, happens to all of us at some point). If this does describe your approach and it still hurts more than a bit, well, maybe it is indeed the fault of CSS.
> I just have such a hard time working with a model where changes aggregate around so much, so changes intended for one place end up messing something up elsewhere.
You're better off with functional/atomic css then, because the styles aren't cascading like css is typically used, which, while powerful, doesn't scale. As such, the classes defined in an atomic css framework are consistent and reusable everywhere. See for example, http://tachyons.io/
It maps much better to the programmer mindset, where we're typically generating dynamic content, and so generating the sets of style classes needed entails just using our usual code reuse techniques.
Excellent article -- this kind of concise history is something beginners need now more than ever. Also, I think it's ridiculous that CSS could be considered the hardest language to learn but I can forgive the hyperbole.
One nitpick: I wish the article had started with a html file that used style properties to influence DOM nodes though -- the <link> tag is basically glossed over, could be a stumbling block.
And then visit http://www.csszengarden.com/ (also metioned in the article) and take that article with a huge grain of salt.
Especially with advent of CSS Grid some thing that were difficult do achieve because source ordering still had a play are much easier now.
To me it looks like people still don't take HTML and CSS seriously. By this I mean they do not think that it is worth understanding neither HTML nor CSS and "whatever Boostrap does" is good enough.
Looking at that "Atomic CSS" abdomination: maybe let's just bring back <font> and friends and be done with it.
There's nothing abominable in the Atomic CSS. In order to achieve Zen Garden with Zen Garden approach you need a PHD in brain-bending. It's enough to open any of the CSS files in Zen Garden to see the amount of tedious repetitive manual work, where every single small element has to be manually tweaked and adjusted.
> Or people just forgot what web was for…
The web was for simple text documents. News flash: the world has changed, and the web has changed, too.
Huh. As a mostly-backend dev reading this, it seems like both this and react.js are driving toward a philosophy where you consider the existing html elements to be a box of legos with certain default behaviour and then you can also use CSS and Javascript to manufacture other components that have different behaviour. Then, after building up the components you need, you snap together your layout from those components.
This needs a part 2 on the history of the philosophy of CSS code. It should go through 4 eras:
Table and Frames - how layouting dominated the CSS school of thought
Grids and Frameworks - the mighty grid frameworks that gave you lots of stuff for free at the cost of the language itself (and your freedom)
CSS Themes - how SASS, naming conventions, and framework customization created the era of CSS theming
CSS Components - how we realized everything we did in the past was wrong, fixed up the language itself, and made styles servants to modular components, the way it should have been all along (spoiler alert: Javascript helped).
> CSS Components - how we realized everything we did in the past was wrong
Not really. This was born out of necessity - deeply nesting components within other components doesn’t work so well when styling with broadly defined CSS selectors. So, we generate class names (or inline styles) directly in our application.
It comes with its own trade offs. I don’t know that adding a build step and tightly coupling your styling with your DOM counts as “fixing” css, but I suppose it all depends on your perspective.
It’s more like we kind of threw away one of the main principles of CSS and forced a completely new philosophy upon it.
This is the fundamental issue with most of the web technologies, though: we’ve taken a platform intended to essentially display documents with a tiny bit of interactivity and turned it into an operating system.
> It comes with its own trade offs. I don’t know that adding a build step and tightly coupling your styling with your DOM counts as “fixing” css, but I suppose it all depends on your perspective.
It is a fix. While creatively combining CSS rules to accomplish layouting is a tenant of past CSS history, it was terrible for coding in the language itself. Using tables for layouting or vertical centering hacks is the same kind of pain as using single letter characters for all your variables.
In the same way, using flexible selectors to select any grouping globally was historically a positive feature of CSS, but we've done it enough to know that it creates extremely painful bugs related to improper scope and needless amounts of copy paste code fixes. The real fix is properly scoping css, which is what BEM is about, but what modular components does better.
Sometimes I feel flexbox was created in order to get back some cool features of table-based layouts without using tables. Technology tends to run in circles.
But table layouts just happened to be very similar to grid layouts, which was what web developers wanted in the first place but CSS as a language didn't explicitly support.
Flexbox was built for dynamic grid layouts, and is a huge step above display:table, creating rules that are explicitly meant to do what you could somewhat hack with table rules.
CSS has this strange acceptance of hacks being a part of the language when it shouldn't be. The fact that you vertically center things with pos: absolute, top: -50%, and it is considered normal is abnormal for a language. Good language design is not to find hacks that allow you to accomplish your goal (robust layouting) - its to fix the language to give you a proper toolkit to accomplish your goal.
I tried to do the same thing while keeping the same appearance between browsers. Tried to use some graceful degradation on some parts, but this articles really made think differently about the way I write css.
I built my first website in 2003 on freewebs.com, and a couple more from 2004-2006. [0] [1] I remember “slicing” layouts in Macromedia Fireworks and Photoshop. You would draw rulers over the main components, and the program would generate a monstrosity of <table> tags to convert the layout to HTML. It was an improvement over Microsoft frontpage. At that time CSS was largely used for fonts and colors. I even had a feature on one of those websites where you could “switch layouts” by using a different css file with new colors.
Then developers started decrying the use of tables for layout, and sites like AListApart (referenced in this article) really pushed for more reliance on CSS. It seemed like we were then stuck in an uncanny valley from 2006-2015 when, even though some browsers supported modern flexbox/CSS3 features, you couldn’t really use them if you wanted feature parity between browsers because so many users were stuck on older browsers due to enterprise upgrade rules.
What really improved css, and the web in general, is automatic browser updates. Chrome was the first to implement it and now its commonplace. Not only that, but the security community spent a decade shaming enterprises for rules against upgrading software. Now, finally, it seems like enterprises are realizing the insecure thing to do is not upgrade.
It’s an interesting interplay of pressure between chrome/Firefox browser devs and security community that got us to a place where a huge percent of browsers are the latest version. It really can’t be understated how much this trend has helped frontend developer productivity the past few years.
[0] http://web.archive.org/web/20040610011616/http://www.mainelo... This beauty got me 2nd place in the "maine student web design awards" for middle schoolers! You can see the layout switch if you choose "aqua" or "mid morning breeze". I think I actually implemented it with two different slicing layout. All the images are dead now, but you can see from where they were positioned what slicing used to look like.
[1] Ok, so probably nobody cares about this, but I'm enjoying the blast from the past... here was my second site the next year. This one didn't win the competition, which I think was due to my trash talking on the competition forums lol. http://web.archive.org/web/20070104015744/http://www.splitat...
> What really improved css, and the web in general, is automatic browser updates. Chrome was the first to implement it and now its commonplace. Not only that, but the security community spent a decade shaming enterprises for rules against upgrading software. Now, finally, it seems like enterprises are realizing the insecure thing to do is not upgrade.
I wish, in some enterprises Chrome is forbidden by IT security exactly because of them not being able to control when updates take place.
"I remember “slicing” layouts in Macromedia Fireworks"
I share this history, and while Fireworks would export complete HTML, "responsible" web builders never allowed that. We would use the "slice" feature of Fireworks to manually export elements of our designs, and then using HTML/CSS we would create the layout code. Raw exports from Fireworks were horrendous, our hand-build layouts were lean, and worked great.
> I share this history, and while Fireworks would export complete HTML, "responsible" web builders never allowed that.
I guess I wasn't responsible - I confess that I left DreamWeaver's output intact: those sweet, shiny rollover buttons where easier handled by mm_preloadImages() :-D.
> It really can’t be understated how much this trend has helped frontend developer productivity the past few years.
Nor can it be understated how much this trend has hurt the user experience. Merging bug fixes and new features into a single stream, then forcing them upon users via software gavage, was a user-hostile crime committed by lazy developers.
It can actually help everyone to write CSS more quickly and in a scalable and structured way. Not saying that everyone should and needs to get on the CSS-in-JS train, but I'd certainly recommend any team of any size to investigate it.
Also, it doesn't have any association with inline-css and -styling. What all new CSS-in-JS libraries do is generate actual stylesheets in a performant and sensible manner.
Yes, but grid/css is _designed_ for layout. Tables was a bastardization of markup designed for data display. (ie, a table of data, like in a spreadsheet)
Unless you have truly dug into how awesome grid is, you can't really understand what it's done for the future of web design.
I will look up a short tutorial I ran into that really showed me the power/value of grid. (fyi, I use CSS daily in my work)
Edit: Here's one example. You could use tables, but this is incredibly flexible and with media queries you can completely manipulate the layout and position of the design based on the screen size. And the markup is incredibly light, it's fabulous for those of us who want more control and less work to do, _and_ less debugging of browser quirks.
Of course, the argument can also take it that HTML was designed to markup textual documents. Such that getting HTML to do what an SVG could easily have accomplished is a touch excessive. :)
I suspect there is a middle ground here. But I can't shake the feeling that as soon as you had to add all of the elements of the chart with javascript, the options were already high that you could have used another method just as easily.
As an example, this would not have been difficult with absolute positioning. See a crummy Rubik's cube I built using absolute positioning in [1]. I could have generated more of the styles using a loop construct in a programming language, so there is room for help, but we already had javascript for that.
That's a neat example there. But with the grid example, it was more a technology demonstration to show the power of a css tool so new most people don't even know what it's capable of. (at least I didn't fully know)
So it inspires me to study more into grid. I avoid hacks like the plague, and it's saved me tons of effort, time and money, and even emotional stress. Grid is not a hack, but a full fledged solution to layout. It's how it should have been done to begin with, if we could have condensed 20 years of global css/html experience into an instant. :P
HTML is just a markup language, not a display language. Even an H1 element has styles set by the browser, without that, it wouldn't look any different than an H2.
Pretty solidly in the float schema / era. At least up to version 3. I started using CSS grid and haven’t looked back except for the occasional polyfill.
And this is just CSS. As a full time frontend dev (started it back in the days of table-based designs) sometimes I look into the mirror and honestly think that I'm a hero :D From mm_mouseover and Netscape Navigator to PWAs, electron apps, responsive layouts, REST apis, webpack, babel and object spread, the web today is getting dangerously close to rocket science.
Since 1996 I've been doing frontend work. First it was HTML with table layout, all the way up to modern js frameworks (although I prefer laravel). I've recently taken on doing a lot of backend work for the first time, and it finally clicked for me why people have had a hard time with CSS. It's a totally different mode of thinking.
I learned about it a few years ago, but whenever I saw blog posts they mostly mentioned OOCSS and BEM. Meanwhile, I was more focused on SMACSS and was wondering if it became obsolete or what happend, but I coulnd't spot why OOCSS or BEM should be any better.
I am quite happy with SMACSS, but as that probably doesn't mean much, as those rule sets become crucial when you are working on a long term code base with a large team. So I would argue that SMACSS is probably a little harder to learn and produces a little higher quality. But while large code bases should always aim for maximum quality, using something which requires a few extra steps to learn ins't the best thing to be introduced to a large team.
Nitpick: You don't need to. There is `sassc`, a Sass/SCSS compiler written in C (which is great for someone like me who hates Ruby with a burning passion). (The article surprisingly hints at this by mentioning libsass later on.)
This is a recent development however, the first few years of using SASS was with Ruby and more often than not Compass as well. In the context of what he’s talking about he is not wrong.
I'm no expert, but isn't sassc just a C wrapper around libsass? If so, there are wrappers of libsass in most mainstream languages - PHP, Scala, Go, JavaScript, Python, etc.
> CSS style sheets are short. They are not much bigger than one editor window. Very few people (only professional designers, it seems) write style sheets longer than a hundred lines.
I'm pretty skeptical of that quote: HN's CSS is pretty minimal and comes in at 174 lines: https://news.ycombinator.com/news.css It seems to be based on the W3C website where apparently 90% of style sheets are <163 lines, but I'd like to see that distribution over the internet as a whole.
It doesn't matter whether the quote is accurate now or even whether it was accurate in 2008 when it was originally written. What matters was that this formed the rationale for keeping variables out of CSS.
Just because it's not a programming language doesn't mean it "shouldn't" have variables.
It just makes sense to be able to, for example, declare all the colors you're going to use multiple times in your document ahead of time so you can say "highlighted-area" instead of "#ADD8E6," same as saying "black" instead of #000, it's just "black" is built into CSS itself. It just gives things a semantic and reusable meaning.
For a non-text example, it's similar to how you can create a theme in MS Office and it shows you "theme colors" first in the color selection tool.
Good read! This article is specially interesting for "dinosaurs" who have been coding html and css since the 1990's. It has been complicated to implement layout on web pages. Slowly it is getting better though.
Very nice writeup! I like the fact that he explained both Flexbox and Grid, as they can both be misunderstood since in some cases they can be interchangeable, although they work quite differently.
What I've anyways wanted was a mixin-only Sass library so I can start with nice building blocks and still end up with bloat-free semantic CSS.
Today I found Kickstart (http://getkickstart.com), which seems to be an option if only it was more obviously maintained! Any others liked it out there?
Surprisingly, Bootstrap v4 may fit your bill. If you into the source, it's all scss and mixins, so you can freely pick and choose. Besides, it covers any possible corner case out there thanks to its massive adoption.
I really liked this summary, and I recall having gone through some of these stages myself. Discovering BEM and ITCSS made my life a lot better. Even when building React apps now using CSS in JS I still try to maintain BEM style class names. It just feels right.
I quite like BEM (and SUIT, and OOCSS), but every single naming scheme is hard to enforce when it's just a 'process you must follow' type of system. There's nothing about BEM that stops me adding a .homepage__contactform-name style to a list item on the news page (apart from my colleagues rejecting the pull request or something). Consequently it's far too easy to use BEM very poorly especially when you're working under pressure.
Stylelint and PostCSS have postcss-bem-linter, but that just checks the name is in a BEM style rather than testing that the style is being applied to the right element. Linting style names is definitely better than nothing, but really I want some way to tie class names to elements that's both easy to use when I'm writing code, and straightforward to ensure my class names actually match what ends up in the browser.
You can do this with CSS Modules using BEM Classnames and a function to generate BEM classnames given a Component Name and State/Props.
The function can then pick the generated classes out of the CSS Module's JSON import. If the classname doesn't exist, it can warn to the console.
It's farely straight forward in React. You just need to make sure you always use the function to provide values to the className prop instead of manual strings.
I wonder if there are other languages that like CSS work by exception.
You add "cases" (switches based on the classes, ids, tags) to portions of CSS not by adding lines (like traditional functions) to them but by extending them with a distant block.
In a world where things like this[0] have legitimate reason to exist, an article where phrases like "barbarianism", "dumpster fire" or "you have got to be fucking kidding me" aren't central to the thesis hasn't really explained modern CSS.
If you understand CSS those things do not have reason to exist. You may have similar sites for the various concepts in various languages— e.g. pointers in C, block syntax in Objective-C.
Yes, there were omissions in CSS which made centering vertically and only in some cases difficult, but far cry from "dumpster fire".
If you're writing an OS or a driver for the machines we have, whether it's C or Rust, pointers are unavoidable.
The entire web platform is insane. Even basic things--like versioning--or error reporting--were completely ignored. Semantic markup has been mostly abandoned. Accessibility has declined rather than improved. Something as basic as column layout shouldn't require an article that long, but it does.
The web is not insane. Trying to make application platform out of the document platform—that's insane.
But I agree 100% about accessibility. In the race to win the stupid war against the native apps all the good was thrown out of the window. Somehow this point is conveniently forgotten by those touting the superiority of the web tech for the apps.
edit: PS, not downvoting anyone here. Just curious as to how other people square html5+es5/6+css2/3 as anything more than an engineering failure and a major waste of human effort.
Having to put a considerable amount of reading, googling, continuing ed--or in some cases even a college degree--just to technically layout a page (technically--not getting into aesthetics, readability, flow, taste, etc.) is insane if you ask me.
Because in theory, you can build an application that will work on nearly every device in the world? Think phones, desktop computers, tablets, watches, tvs. With every conceivable operating system going back many years. And you don't have to install or update any software, worry about data loss, accessing the same data from multiple devices anywhere in the world.
Seems like there's a lot of good non-crazy reasons for the web to have taken this turn. Is it perfect? Nope, but it's pretty damn cool that I can login to a computer anywhere, put a point on a map, and have it show up on my phone, and I am privacy nut. :P
If we're getting into application development, we have a sandboxed VM that a) requires megabytes of npm/webpack/jquery/bootstrap mystery meat to paper over all of the cross-platform and form-factor potholes, and b) allows everyone and his brother to track your behavior in real time.
Go to practically any major content website and poke around in the developer console. Check the cookies, the constant ajax requests, the payloads, the file sizes, etc. It would be one thing if this were all for the sake of compensating creators and good user experience, but I don't see that. I see a dystopia where Google/Facebook/Amazon gets the sandwich, SV gets the crust, and everyone else gets the shaft.
There have been many browser forks where some heroic soul tries to strip a few of the more obvious f-yous out of Chromium or Firefox. They all eventually give up. When even the #3 company is blasting through half a billion dollars a year to put mr robot bullshit in their browser, any one-man effort in that direction will be drinking from the fire hose.
> "Gotcha" means "I understand you", its not an accusation or a condemnation.
It can also mean, roughly, «j’accuse»—or perhaps, “I have just proven the accusation against you”—so it can be ambiguous when context doesn’t make the intent clear.
So stating that modern web technologies were very badly done is moralizing?
This isn't physics or chemistry. We're talking about webshit here. Perhaps HTML/CSS back in the CERN days could be counted as technology. The rest of it--from the curly braces in JavaScript down to the --webkit/--moz prefixes in CSS--is pure politics!
Politically speaking, strict top-down control is typically not so great. With the IPv4+NAT+Client/Server model that we have, along with the browser standards and software being dominated by Google and Apple, strict top-down control is what we have.
Are you upset the technology isn't better? I am speaking from the end user perspective as well a developer. Maybe this is all second language context confusion.
Vue scopes components through data attributes. I'm not entirely confident we really need shadow dom support in browsers, as we have good strategies now of creating components without it.
It only occurred to me recently that float actually meant float from a 2d point of view. As in a side view of an aquarium, you attach float to an object, and it goes to the top of the tank, displacing water along the way. You can float it left, and right, etc... goes to the left and right of the top of the aquarium. Things line up at the top if you float multiples, etc.
I don't know if that is an appropriate analogy or not, but it seems to fit for me.