Make as many mistakes as possible and learn from each one of them. And forgive CSS for being so complicated. Maybe you just have one idea to build a site but search for online projects and practice. If you find a platform or challenges on the web and you can start there to do these there will be people that have been there for. And yes CSS might not be the easiest one to master but… You did not master the language you speak after two weeks, two months… You really can do this!
Hi Kai! I would like to inform you that, recently I realized that motivation is unreliable. Therefore, since I had the realization that I need the grit in me to get what I want, then I shall jump into learning CSS and continue to do it till I get comfortable with it.
I encourage you to do the same. Finding something tough? Not comfortable? Then do it more till you get comfortable. Even though you will not enjoy it for some time, when you attain fluency, you will start feeling more comfortable with CSS. It is the tool used to implement the design and there are loads of other layout tools out there that don't have CSS's infuriating quirks.
On the flip side, they usually have steep learning curves because they are strict. For a long time, until less than a decade ago, designers knew nothing about CSS. They'd do a design in pictures and their design would be implemented by a programmer.
That was my entry into programming many years ago. But I wouldn't call it unlucky - early web devs like me we didn't really call ourselves programmers back then had front-row seats at the beginning of a revolution, and it certainly was entertaining to watch and be part of. It has everything to do with graphic design. All the web designers I knew back in the early days knew some HTML and CSS and we'd often discuss possibilities and limitations of browsers and standards, and how to work around issues.
They didn't just lob PSDs over the partition to the devs - there was an active dialogue and they knew their stuff. Falkon on Jan 29, root parent next [—]. Their solutions were along the line of "Force the browser to be XxY resolution and limit the number of words that can be entered in this area.
Later that became a thing, yes - but all the design that was already there at that point circa CSS 2 remained, as did the overall approach with cascading styles.
A styling language designed for HTML5 today from scratch, accommodating modern use cases, would likely look a lot different. That was when "design" lost. But now with grid and transitions, there's a "new" CSS - one that is oriented around UX for "web apps". But apps evolved from documents, mind - not from windowing toolkits like smalltalk morphs or Java swing etc.
Fwiw I really liked the idea of regions for laying out rich documents - like what you might want for epub. I must admit I'm not that concerned about "web apps" - everyone seems to end up doing their o we n abstraction anyway, and the CSS that "falls out" isn't really sane anyway. I just wish we decoupled apps and sites, instead of forcing it all together in a large and incoherent design. This is especially painful now that it's spilling over into the desktop world because of all the Electron apps.
I remember playing with it when it came out and thinking it was very cool. Pity it never went anywhere. If we were going to start from scratch though, we wouldn't do HTML5, we'd use some other format. JSON maybe? Extremely doubtful, given that many of the modern ones have been written in XML e. No-one went pure code because it's a massive PITA. Display PostScript?
Only kidding, maybe. I find this false. PSD-to-code was very common back then. Not disputing the 'PSD-to-code'. Did it myself many, many times. I was disputing the idea that designers knew nothing about CSS. The good ones did. What a bizarre statement. That's like saying words have nothing to do with stories, or paint has nothing to do with art. I remember slicing designs in Photoshop into sections, to be dropped into pages NeedMoreTea on Jan 29, root parent next [—].
Oh wow. I'd always just assumed it was a US idiom along the lines of yada yada or something. Buffalo buffalo Nearest English silliness I can remember hearing is: police police police police. Don't tell me you can't verb a noun in English English? FWIW I'm an ESL speaker from a non-English speaking country and despite having had endless exposure to mostly American and British English since a young age, I've never encountered the verb form of "buffalo" outside that one sentence.
It's an informal North American idiom and by international standards apparently a fairly obscure one. Policing OTOH seems to be a fairly widespread verb form with a clearly understood meaning i. Unless you have close experience with buffalo, you probably can't infer buffaloing means "intimidating". EDIT: Also as mentioned elsewhere, not everyone outside the US knows there are places actually called Buffalo or makes that leap when hearing the word "buffalo". So "Buffalo buffalo" is more likely to be read as "buffalo n buffalo v " which already sounds weird if you don't already know what "to buffalo sb" means which breaks down as soon as you add more buffalo to the sentence.
Most Americans probably know of it these days because it still hosts an American football team. NeedMoreTea on Jan 29, root parent prev next [—]. Of course nouns have been made verbs in English. You'll find no British English dictionary listing where buffalo is, unless noting US usage, where it is both. Police police police police is grammatically correct, but of little meaning : the police police v police of police ie overseers of the police.
I read it as: police police Internal Affairs police v police. Yeah, I'd sum it up by saying CSS makes hard things barely possible and simple things hard. The example OP gave of centering divs illustrates this point, and there are unnecessary weaknesses in laying out a page when, for example, sizes aren't known in advance. Overall, there's a divide between intuitive expression and output, wherein the browser ends up saying things like, "I won't do this e.
In all, it's never been an efficient solution to the problem it seeks to solve. When the Great War on Table-based Layouts broke out, it was even less suitable, which made it even more painful that you were persona non grata for resisting.
So, rather than demand a better standard and uniform browser support, we just hacked and kludged and shimmed around it. So, the need to support the legacy has made it even more impractical to fix, hence the attempted do-over with flexbox. CSS has been the bane of front-end development for many a dev. Amazing that we largely just suffer through it, and its tyranny has reigned for so long.
IfOnlyYouKnew on Jan 29, parent prev next [—]. Everything you say rings true ca to Of course the cutting edge will temporarily see one rendering engine a few months behind another. I think there's edge cases, dialects, and straight-up absurd rules in JS too. I don't think CSS is any less logical The difference is that with JavaScript, you can install a linter and happily restrict yourself to the sane subset of the language.
It's very realistic to never have to deal with any of the uglier parts of JS, even as a full-time front-end developer. With CSS, you can't avoid hacks. If you try to design anything non-trivial, you will have to employ tricky non-semantic tricks, run into edge cases, and have to settle on ugly, non-optimal solutions. I don't think it's a declarative vs imperative thing. Nowadays our requirements encompass pretty much the full spectrum of 2D space design, yet we still use a language that builds on high level primitives designed for a narrow usecase.
They try to disguise it with multiple columns of guff, but it's still just text and images. Sometimes a video. Sure there are web 'apps' now too, but most websites are not apps thankfully.
The thing is, web apps are also just a more complex version of the same '1 dimensional flow of text and pictures,' just maybe with Canvas and a lot of javascript.
The dirty secret of the whole "the web used to be documents but now it's applications" meme is that the applications are still documents. BigJono on Jan 29, root parent prev next [—]. What does installing a linter have to do with using a subset of a language? It's not like you can "accidentally" use an ES6 class or something. You can know about for.. You can forget to enable strict mode. The list goes on. Static analysis is universally a good thing. Hithredin on Jan 29, root parent prev next [—].
I experience the same than the author. I don't think it is caused by this aspect of CSS. The problem could come from the fact that it mixes 2 purposes: style AND layout to apply it globally with rules that get harder to understand the bigger the project.
LandR on Jan 29, parent prev next [—]. No, it really isn't. Some languages are, JS definitely isn't. That isn't an argument, you're just expressing your disagreement. Even if it were an argument I'm not even sure it would be an argument worth having because it's likely entirely orthogonal given the context of the original statement i. Is there any material out there that made CSS "click" for you? If you're coming from an application development background, you will hate CSS layouting.
It's the most ass-backwards way of structuring a UI that you will ever encounter. A lot of web people who never used stuff like Qt, Swing, Winforms etc just don't realize this.
They think there's some sense in CSS. There isn't, it's a bunch of historical accidents. HTML wasn't designed to be dynamic, it was designed for documents. CSS wasn't originally meant to do layouting. The end result is an incredible amount of technical debt.
CSS performance is a complete disaster. It's unfixable. If you need to do a non-trivial amount of dynamic content, you need to use Canvas or even WebGL and re-implement a lot of stuff yourself, but then people will complain that it's not "semantic", that it's poor design and that it goes against what HTML is meant for.
It's a complete joke. The thing is, you don't have much of a choice. The web platform is what it is. If you want to work in the web frontend, you'll have to deal with it. Alternatively, don't work there. There's other opportunities. I'm glad to read I'm not the only one struggling with it. But any non-trivial layout always requires a lot of trial and error: does this need to float?
Does inline-block work better? Now there's flex layout on top of that. Do I need relative or absolute positioning for this thing? Do I need padding or margin here? And why does my margin not do anything? Every time I think I finally understand it, I run into a situation where it doesn't do what I expect. And then there's hacks with negative margins and that sort of stuff, where it feels like CSS needs to be wrangled into doing something it doesn't want.
The worst part for me is that it's one of the few places I end up having to hack my hacks because I find out that Firefox does something wildly different from Chrome so the fix I just made to Firefox made it better but broke something else. The other thing that frustrated me about CSS and continues to this day is the lack of permanence of a working layout.
That is one of the things that really separates the backend from the front end mindset for me, the back end can be done forever but the front end will have to change to fix something unknown in the future. Right on. The thing is, Winforms et al. It only runs on one platform, it does not handle scaling gracefully, it does not even attempt the solve the complex problems of text re-flow to accommodate different size viewports etc.
Swing is fine for cross-platform GUIs but can it render books in high-quality typography on various devices? The design of CSS makes a whole lot more sense when you understand what problem it is designed to solve. The first version 1.
DSSSL was an inspiration and supported layout. The complex problem of text re-flow is probably not that complex. It has been solved rather satisfactory in all word processors and desktop publishing systems.
Sure, but it is not solved by GUI toolkits like winforms, which is why they are not directly comparable. And A DTP system will not gracefully adapt the layout if you change the page dimensions or scale up the font.
My point is just that CSS is designed like it is because it tries to solve some particular problems. If you expect it to work like a GUI toolkit or DTP program you will be confused because they do not try to solve the same problem.
Could you give some examples of how specifically layouting is solved more elegantly in these systems? I'd recommend spending some dedicated time learning about layout, not leaning on a framework. CSS layout is largely about the relationship between elements.
Instead of looking at it as "I want this element on the right," try to see the relationships between elements. What's the group of elements, and what causes them to be where they are?
Generally, complex layouts are nothing more than nested groups of elements. Once you recognize the patterns, CSS layout becomes straightforward. Not easy, but straightforward. It becomes a matter of defining and expressing the relationship between elements, and the constraints that define their layout. Flexbox is really the thing to focus on here. Don't worry about the words if you mix them up -- justify vs align, etc. Just the idea of a spacial relationship between things with rules that define the constraints.
Often times, the relationship winds up being expressed as "I want this group to consist of items with space between them on the current row they wind up on opposite sides of viewport, and when they wrap, I want everything aligned to the left. To this end, using equal but opposite positive and negative margins negative on a container, positive on its children can provide space between elements and allow for arbitrary numbers of elements within a layout where you don't care which is first or last in a given row.
Let the elements flow into the layout. I think there's a pretty definitive set of exercises any developer could work through to learn about the different types of constraints we need to express, and from there, it's generally a matter of recognizing the pattern in a higher-fidelity format. That's really interesting. I'd concluded that the issue is precisely the lack of peer-to-peer relationship constructs. Everything seemed based on 2 constructs: 1. Flowing 1D content text into a 2D space 2.
Hierarchical relationships, i. I haven't looked deeply into flexbox or grid. My initial skim suggests they're both still fundamentally hierarchical.
I'll take another look now given your comments. I would say my initial forays were difficult and frustrating. CSS layout seems seemed? As a counterpoint: back in the midst of time, there was a cross-platform UI toolkit called Galaxy. It only had 2 layout constructs: springs and struts. It was remarkably simple to define layouts using just those two concepts. The web is clearly a more complicated space than conventional, thick client apps that only ran on the desktop.
Responsiveness is a much bigger challenge now. Nevetheless, it seems to me that the key construct lacking in CSS is the ability to specify peer to peer relationships among elements - without needing to create a whole cruft of container components. I remain healthily sceptical, but thanks for the prompt. I'd say grid is much more of a "new" concept for CSS than flexbox. And while I'd always understand learning the basics - to get stuff done most everyone landed on hard coded sort of grids before "CSS grids" came out.
This x. I was at a university that used Bootstrap in their Web Design class! And, predictably, it didn't work all that well. I spent some time tutoring one of the students and was amazed at the content they didn't cover. They thought why would you spend all this time on a non programming language? No one takes CSS seriously. For most, CSS comes as an after thought.
Build every part of the application then suddenly "Oh Right! Yes, CSS is not a programming language like others but it is just as complex. It requires studying, practice and long exposure to become versed in it.
Note: you can google your way into using a couple jquery functions, but you can't become a competent JavaScript developer like that. The same goes for CSS. It depends on the problem your trying to solve, if you just want something that looks decent because you're a programmer and you don't notice things like colors, alignment and spacing then something like bootstrap is a good go-to. CSS is almost a failure as technology. None of it's promises has been realized. The idea with CSS was that we would be able to separate content from presentation.
Remember CSS Zen garden? Yet that has never been the case and div tags were always needed to be able to display something simple. Another promise was that content would be displayed easily on different mediums, desktop, mobile even print.. For the first years of CSS it was always easier to get a decent layout with tables than with it.
Finally all the CSS preprocessor, like saas and compass show how incomplete the technology really is. It's only a failure when viewed through the lens of application development. The web platform wasn't initially designed for applications, it was designed for documents. If you're crafting a document, you can separate style from content pretty neatly with CSS. What if my style requires a triple outline around a header? If the goal was really to decouple presentation and content then CSS has failed spectacularly.
Having element selectors, attribute selectors, child and sibling selectors, very tightly couples the content with the layout. It also has the ability to affect content by inserting text nodes for example using the 'content' rule.
I'd say one big gotcha that trips up most people is not understanding when a style is valid or not. Certain styles are only valid for certain display types see the CSS spec. Also look at the non-normative references on W3C for the default style sheet to see what default rules get applied to elements To really fully keep content and presentation decoupled you have to stay away from those things and use something like css modules or similarly have a one-class-per-component rule.
My heretical view is that it's time to abandon CSS. You already generate your HTML with some program whether server-side or javascript that takes a canonical, normalized representation of your content and spits out repetitive HTML elements one pattern of elements for a button, another for a calendar, etc. Have that same program apply inline styles on elements that need styling.
The straightforward way to separate content from presentation is to have a step that transforms that content into a specific form: 2D screen based, 2D page-based, aural, etc.
But web community took a wrong turn here. CSS Media queries allow you to trivially handle different mediums screen size, pixel density, screen-vs-print etc. It really is very very easy. I dont agree that CSS preprocessors are evidence that the technology is incomplete. I would wager that most programmers wouldn't agree with that. CSS preprocessors are basically just a way of saving time and improving maintainability by "compiling" some syntactic sugar down to "raw" CSS. Same could be said with doing assembly programming vs e.
I agree though that in the very early days layout was hard with CSS, but then in the very early days we didn't even have devtools and XMLHttpRequests were still something mysterious and exotic. Times have changed and CSS has changed along with it.
I'd recommend you try revisiting modern CSS if you have not already done so - you may be pleasantly surprised at how easy it is these days. The fundamental problem, I think, is that alignment is a key concept in design which isn't reflected well in CSS. The concepts of normal flow and the box model are almost at odds with wanting to align lots of different parts of a page.
CSS Grid and Flexbox do help with this certainly but don't completely solve the problem. Even disregarding mobile and tablets, I think it's also sometimes surprisingly quite hard sometimes to specify how fundamentally you want a page to look in differently-sized browsers - how things like spacing and guttering and so on should work particularly when your content is dynamic. Plus, there is the fact that it is hard to shield parts of your page from being inadvertently affected by CSS that you don't want to affect it.
Again, there are ways to minimise this, but if you're not the only person working on your codebase, good luck! It is a quick and engaging read and will certainly make you start to appreciate things like the differences between fonts. I actually prefer coding CSS from scratch. Color schemes and making things look nice IS hard, for my previous and current projects I had to get feedback from friends, family, end users, graphic designers, etc. UX is hard, it's a different field than programming, but there is a method, research, and science behind it.
Band-aid after band-aid. I think keeping UI components tiny and coupling the stylesheets with the component is the best way I've seen not necessarily styled components, just styles in the same folder as the component. As the component is removed, its easy to nuke the stylesheet with surgically removing related styles and not breaking something else. I feel the same. Why not styled components?
I think it's just a matter of preference. Same here. I recommend to avoid bloated kitchen sink frameworks like Bootstrap and Foundation unless you don't plan to do any customizations at all and only include the parts you actually use.
Otherwise you'll realize that you're actually fighting the framework by trying to override it. I hate css, but one of my colleague who's really good at it told me once that people have problems with css because they don't study and take it seriously. I spend so much time reading on new languages and design architectures, but besides some articles here and there I don't study css or take it seriously at all.
So yeah, there you have it. I also think it's getting better. One major problem with css was getting it to work across all browsers, but now if you're lucky enough to only have to support modern versions it's so much easier than it used to be!
CSS is not as difficult as many people think. I remember the first project I worked on as a web developer was to update the styles of an existing web app with very complex UI. It was hard as hell. But I was lucky to have worked with a senior developer who was a CSS wizard. He taught me that CSS is not magic although it is magical.
If you don't give up, you can bring any designs to life. Not knowing any better, I spent months playing, tweaking, learning how to style different components from scratch. I mastered selectors and the cascade, block model and floats, display and position types, a few tricks like using negative margin, constructing triangles from borders. I never stopped honing my skills. Before long I started learning about responsive design, transitions, animations, performance, and design systems.
CSS became a playground for me to experiment. It opened up a whole new world to express my imaginations. My advice for anyone aspiring to master CSS is to find some design inspiration that you like and just build it.
You'll learn so much along the way if you don't give up. At some point, things will fall into place and you will realize just how wonderful CSS really is. No, as someone who's struggled, and seen other programmers struggle, with CSS way before bootstrap was released I can assure you this isn't true. The whole set of web technologies is a mess. The sad thing is that by the s we'd figured out how to do good UI design for desktops, but then we promptly forgot every single bit of that knowledge when the web came along.
But the web wasn't supposed to be a UI platform - it was supposed to be a medium for delivering text with some images and media occasionally interspersed. Hyper text markup language. Java applets could use Swing to get a normal-ish desktop UI and still be close to the web.
The standards are slowly mutating and eventually they may provide a good UI framework. Both provide a drag-n-drop interface to design applications using standard widgets such as lists and tabbed panes etc.
Because divs can't represent that naturally - I had to use weird css and put 3 divs inside the outer div. I have been doing UIs since the mid's, with Turbo Vision being my first framework. Naturally also Web based ones since early 's. Share the feeling, everything is so much easier in native toolkits. There is some hope though thanks to Web Components and Houdini.
But you're right, the web isn't a UI platform. It's designed for to produce things that are like Microsoft Word documents. Yeah, one can do it, but it's like cutting a steak with a spoon. You are somewhat correct. I just tested with the tiny HN logo upper left of this page , and a div with 3 imgs makes them appear side-by-side.
The issue I had previously was that the three images were quite wide, and while I wanted them to still go next to each other with a horizontal scrollbar in the browser , the browser moved images into a new row if they would overflow past the right edge. That gets onto a major tangent, namely the fact that the web took over as a UI due to the incredible pain and security nightmare bad isolation of shipping and updating native apps.
The web was a way to avoid the hell of installing a native app, so the web won. This is still a problem with OSes. Mobile improved the situation a bit but not really that much.
I am now reluctant to install mobile apps since virtually every mobile app is a potential vector for who knows who to spy on me. Mobile apps are isolated enough that they're unlikely to trash the device but they still have huge security isolation problems. Thinking about the apps I used in the s, we definitely had not figured out good UI design.
There were some good ones, but there were some terrible ones too. Remember Napster's interface? And now we've come full circle with reader modes that disable all that crap the designers add. I have a lot of time messing with css that could have been solved in minutes using tables instead I find it very unlikely that browser vendors will agree to have the same implementation across their own products, vested interests and all. The tipping point for me was memorizing "A complete guide to flexbox" from the site "CSS Tricks" by using flash cards Anki.
Inline blocks are excellent for inserting layout in the middle of text. Neither are ideal for creating a layout. Flex and grid has now fixed that however. What helps is to internalize the core concepts and to never "slap on another rule" when things just don't work. Start from scratch and update your mental model. And when CSS is localized, specificity becommes a none-issue. Check out styled-components for either React or Vue. That page was a godsend.
It's one of my most accessed bookmarks :. Multiple asterix are stripped it seems. It clicked a bit more for me understanding the box model better. I have no idea how design works, that seems a bit more art.
CSS is great, but its poorly taught. I've known so many developers of all skill levels who get stuck somewhere between "I can make it red but I have no idea how to apply all these random properties into the layout I want.
So I tried to write one. It's a little old now this was before widespread Flexbox support but it's specifically aimed at the sorts of problems you described.
I liked the no bootstrap section. People lack the foresight of shooting themselves in the leg. Currently working on a project where the front-end guys ended up using! I very much doubt that CSS is "too hard" for you. If you're not doing it all the time, it's easy to just brush it off to the side or google whatever you need to do.
No reason to be an expert in something you're only going to use once in a while. Actually, they are arguably even weirder than CSS. Skunkleton on Jan 28, prev next [—]. Yeah, with flexbox we can finally do the layouts we could do with tables since , and it's only a little harder. Flexbox solves a different problem - for example you can't have rows and column in a flex.
There is some overlap in functionality, but generally flex is more convenient to use. Another reason to avoid bootstrap if possible. I wouldn't touch that thing with a 10 foot div.
Each to their own, but it's better to make your own templates, unless your primary role is something other than frontend dev and you want the equivalent of store-bought pasta sauce instead of making your own pasta sauce. Arnt on Jan 29, prev next [—]. If you want to write good SQL you have to let go of assignments that happen-before other assignments. Instead there are sets, unions and other concepts from logic. Debugging SQL is fundamentally different. CSS is like that.
You might achieve Zen by reading one of Tschichold's books, and ignoring all of the syntax and tricks and howtos for a while. I held the same belief for a long time, but now I think that CSS isn't particularly in general, but can be very hard if a few core concepts are missing. Klonoar on Jan 28, prev next [—].
I have no idea which colors "go" with which ones, and pretty much all fonts look like the same for me. Yeah, you're not a designer. Note I'm not insulting you. If you're not used to that, it won't gel well. The warts more come down to differing implementations across browsers, which has become far less of an issue in recent years.
But when combined together, you have a very useful, very valuable set of skills. And now that I'm on the other side of the learning curve, I can handle all kinds of web-related tasks from small fixes and customizations, to building very large, very complex sites e-commerce websites, membership websites, and more.
In fact, because I've been building websites and running online businesses for so long, I actually know much, much more about web design than someone starting out today would really need to know.
Looking back, I think I totally overshot. For yourself, you don't need to know nearly this amount And that's what's so cool about CSS and web design -- it can be as big as you want it to be. Here's what I mean: To build modern websites, you can pair WordPress and Elementor together to easily construct web layouts very quickly without knowing any code.
With Elementor 's visual drag 'n drop interface, you can build beautiful, modern, responsive layouts and remain totally oblivious to what's going on in the background code. Because knowing even just the basics lets you handle fixes, problems, and customizations as they arise.
As amazing as modern web builders are, they're still limiting. By knowing some code, you can pull back the curtain and get into the background of your website and edit it directly. And if you know even the basics which is easy to learn you can be much more self-reliant. You can handle many problems and fixes yourself rather than having to rely on other people, like maybe co-workers or freelance web designers. Being dependent on someone else, on their schedule, and being billed on their hourly rate is no fun -- especially for things that are so easy and simple to fix.
You'd be self-sufficient, and able to work on your projects anytime you like. That could be a small personal project, an online business, or maybe helping out a friend with their website. Either way, learn these skills once, and you have 'em forever. As mentioned earlier, CSS is the most critical part of front-end web design. This means that it's the most important to fully learn and understand.
This is because CSS can cause the most headaches when it isn't used properly. If you've started learning CSS and are finding it frustrating, or if you're wondering why CSS can seem so complicated, there are a few important points to keep in mind.
First, CSS can be frustrating and seem complicated if you don't take the time early on to really nail down the fundamentals. Learn CSS right, up front, and you'll avoid a lot of headaches and frustrations. Anytime I run into problems with CSS, it's usually a result of the code not being used properly.
Misuse of rules, poorly written code, and jerry-rigged CSS is horrible to try to sort through. And tracking down problems in CSS can get pretty frustrating because often it's a matter of trial and error to locate the source of an issue. So if you're frustrated with CSS or thinking it's too complicated or if you're hearing people talk about how frustrating it is , it's usually because key, fundamental components of CSS have been skipped or not thoroughly understood.
So it isn't CSS that's causing the problem; it's often a lack of fully understanding it. A bad carpenter blames his tools. But it's not the tool's fault. These three fundamental concepts are critical fundamental components of CSS that you'll need to nail down. Gloss over these, and you're going to be in for some serious hair-pulling! Take the time to learn these fundamentals early on, and you'll find CSS a lot less frustrating -- and a lot more powerful -- than you might think it is.
But beyond these three key areas, there are other aspects of CSS that you might find frustrating. Let's discuss Beyond these fundamental aspects of CSS, building layouts can be tricky -- at least I used to and still sometimes do find them challenging. I think maybe this is because I have a background in visual arts and graphic design. Or maybe I just need more coffee! But CSS can get frustrating when you visually know where you want to put things, but you can't get the code to play nice.
I've been in countless situations where I could have drawn what I wanted to build on a scrap piece of paper or a white board. But translating that over into code was causing serious problems. But it always boiled back to me not fully understanding what the code was doing. These days, I can very rapidly build nice looking layouts all by hand It took a lot of mashing my face into my keyboard to get to this point. Building layouts can also get frustrating when you start getting into responsive design -- that is, layouts that are friendly and adapt to different mobile devices, like smartphones and tablets.
But once again, it dials back to having a solid grasp on the fundamentals. And truth be told, building page layouts does get into some of the more complex areas of CSS. Another very frustrating part of CSS is getting your work to look consistent across different web browsers. In fact, this has been a major, long-standing headache for anyone involved in web design.
In years past, each web browser would render CSS in slightly different ways. Each had their own unique way of interpreting CSS. And even different versions of each browser has their own quirks. As new browser versions would be released, they'd comply with some of the newest standards, but not always, not consistently, and not at the same time. As a result, web browsers had major inconsistencies between them. Your layout might look fantastic in one or two browsers, but fall apart in others.
Adding to the frustration, fixes you'd apply to get your layout working in browsers that weren't rendering it correctly might then break it in browsers where it was working! Throw mobile browsers and operating systems on top of this, with their endless varieties of screen sizes and resolutions, and it's been a real mess. Previously, to solve all this, you might have to wind up writing the same CSS three or four times, each tweaked slightly for different browsers, just to get your website behaving consistently.
Thankfully, in recent years browsers have been getting better and better at agreeing on how to render CSS. Cross-browser compatibility is certainly less of a headache now than it's been in years past. That's what's so frustrating. Poorly coded browsers are to blame, not CSS. Easily the browser that made web designers want to take a sledgehammer to their computers was Internet Explorer.
Thankfully, Microsoft dragged that mule behind the barn, introducing the much more modern Edge browser. But the mule that is Internet Explorer isn't dead yet. It's still causing problems for web designers. This is because it's still in use by a percentage of internet users. Let's call it Zombie Explorer! Yes, a percentage of internet users are still running old, outdated browsers. At last check, the percentage wasn't very high overall, but what if your organization or audience happens to fall into that group?
So with all these frustrations, is it worth it to learn CSS?
0コメント