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 don't understand. The first and simplest use of CSS float that I learned is to embed an image into the text flow, with the text wrapping around it, http://allwebco-templates.com/support/S_textwrap.htm
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.
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.)
Isn't it? If you float an image it does go to a top layer and blocks other non-float layer below it.
I'm thinking of float with block elements, which works in the way OP originally thought.
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.
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.
So much of CSS seems like a square peg trying to fit into a round hole.
I've had to occasionally delve into webdev since 1994 and despite progress CSS still seems clunky.
Currently I am going through Udemy's Jonas Advanced CSS course
I love the idea of grid layouts, SCSS rocks, BEM sort of makes sense.
Still I hate the fact that I can't quickly iterate layout/design with CSS unless I am really proficient with CSS.
I do not want to keep all the CSS quirks in my head!
Reading questions like this(oldie but still): https://stackoverflow.com/questions/396145/how-to-vertically... makes me recoil in horror.
For one there is no software tool that can let someone visually move elements around and still produce reasonable CSS.
On one end you have mockup(Mockplus for one) and beginner(shades of Frontpage) level tools which produce monstrous write only CSS.
On other end you have regular developer tools(VS Code, browser dev tools etc), which do not really help you with layout.
So it seems for making SPA you need 3 people:
1. Designer making mockups
2. CSS expert converting said mockups to usable HTML/CSS
3. Programmer actually working with DOM manipulation
With webdev it seems incredibly hard to go alone.
SVG seeems such a normal standard compared to CSS.
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.
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.
> I do not want to keep all the CSS quirks in my head!
Specific versions of them, not only the very latest.
At very least, not counting other special cases for browsers like smart TVs and such.
So yeah, having to learn browser specific CSS quirks wasn't gone away.
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.
That's all it boils to, experience.
Use something like http://tachyons.io/
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.
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.
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.
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.
I still hope one day WebComponents will finally get us the sane native model on the Web.
Until then I try to focus on native projects, when given the option.
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.
This helps you wrap your head around semantic-vs-layout CSS and Functional/Atomic CSS
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.
Or people just forgot what web was for…
> 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.
Mind you, the concept is simple, but it's not that easy to implement it in practice.
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
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.
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.
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.
3. I wrote a slight further step for minimal forms/bootstrap http://ianchanning.com/mofoforms/
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.
 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.
 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...
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 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 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.
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.
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.
Which web components will make obsolete. Therefore they are a temporary hack of sorts.
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.
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.
I tend to delegate a lot of this to 'whatever bootstrap does'.
Does anyone know if bootstrap fits neatly with any of these methodologies?
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.)
> 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.
Nested tables inside nested tables, with styles inlined.
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.
If you like step-by-step guides, you might enjoy this tiny tutorial I made last year: https://jgthms.com/web-design-in-4-minutes/
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?
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.
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.
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.
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.
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
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.
Technology is not a moral issue, how people use it is. You seem to be confusing the two.
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.
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.
Support for it only exists on Chrome at the moment (https://caniuse.com/#search=shadow%20dom), but things like Angular are already geared up to use it for encapsulating styles, but defaulting to an emulated mode that is essentially css-modules:
What?! Leave the semantics alone!