They said stop trying to fix CSS with JavaScript. CSS isn't broken. Then, how to you tell that CSS can do jobs like highlight or put effect on selected text or page blackout on image click. I'm not good at front-end thing though, I can't see how to do these without fix it with JavaScript. I intend to ask that how do you tell that this thing must be attempt with CSS first. Any suggestions, Thanks
Uhm... Not entirely sure what you mean by highlight, but if it's what I think it is, have a look at :target-pseudo-selector. Effect on selected text (if you mean that you mark some text on the page) is not possible with CSS alone Page blackout (are you thinking an overlay?) is completely possible using CSS only.
The key is to remember that nothing on the client can be trusted or depended upon. The page must be fully functional with bare naked html. CSS and javascript are embellishments that (hopefully) enhance the user experience. CSS will do most of what you need. For what little it won't, a little bit of js is alright. A jQuery library is not. I pretty much doubt that more than 1 kloc would ever be needed for a sane web page. A tenth of that is a more likely value. gary
hi guys, Thanks for the inputs. I've also asked for general work. For the next time I encountered challenges, I'm tempted to use JavaScript since I think I'm more master of it than HTML. [I really don't like the front-end since I mostly never produce any results that I've in mind. Most of the time I throw it to other people. But in some cases, there's a mandate.] @PoPSiCLe I'll try what you suggested.
So the question is how do you know when something can be done with pure CSS? Id say it comes with experience. After a while you'll run into pretty much every property and get a feel for what's capable with pure CSS. If you're unsure on how to do something, a quick google search usually comes up with some good solutions. CSS3 is pretty powerful and opened up a lot of doors, just pay attention to browser support.
Don't forget that other googlers are just as confused by terminology as you are, so there will very likely be using the same or similar search terms as you. You may have to mine the responses a bit to discover the optimal keyword(s). cheers, gary
Whilst I'm having great difficulty deciphering the broken "Engrish moist goodry" in your post, I think it boils down to two simple things you said: First: Then take the time to learn HTML and CSS. You really have no business using JavaScript until you know the first two; same for PHP. People jump the gun on their learning cycles -- I'm often shocked at how the people writing things like JS or PHP don't know enough about HTML, CSS or the DOM to be using two languages who's ENTIRE REASON FOR EXISTING is to create or manipulate those two things! Second: Then you might be thinking wrong or overthinking your solutions. There are a LOT of things that people think they can do on a website, particularly in terms of artsy nonsense that adds nothing of value to the result, that DOES take JavaScript to implement but to be frank, has no damned business on a website in the first place. It's why most people calling themselves "Designers" aren't qualified to be designing jack ****, they're artists; nothing more, nothing less. I think of web design in the same way I do electrical design or mechanical design: It's engineering not art! In electrical design you have voltage tolerances, heat tolerances -- in mechanical design you have load tolerances, materials engineering, cost factors -- and they all combine to create practical limitations in what can be done. Accessibility, bandwidth, usability, sustainability, and functionality all combine to create those same types of limitations on what SHOULD be done. Failing to pay attention to these things by understanding what HTML is -- much less why it even exists in the first place -- results in websites that from an engineering standpoint run the gamut of "how not to do things" from the Vasa (a top heavy sailing ship that sank when launched in 1628) to halfwit artsy design like the various buildings around the world designed to cook people in the streets. (Which are now quite literally known as "Architectural death-rays") Basically what happens when you hire an artist instead of an architect. There are GUIDELINES like the WCAG, there are endless good articles and sources on usability like those provided by NNGroup, the very purpose of of HTML is to be a device independent fallback so that the page is at least usable WITHOUT scripting OR CSS. The page should be usable without a mouse, without touch... or even usable with touch or mouse but without a keyboard as it should support ALL devices. That's what semantic markup is about, that's what separation of presentation from content is about, and that's why sites properly written should be built with progressive enhancement so that they gracefully degrade when the fancy bits are unavailable, inapplicable, or flat out blocked by users they piss off. Hence that pesky "unwritten rule of JavaScript" I'm always bringing up: "If you can't make the page work without scripting FIRST, you likely have no damned business adding JavaScript to it!" -- Good scripting should enhance an already working page, NOT be the only means of providing said functionality. Just as CSS should apply appearance to the page, but not supplant functionality. Which creates those pesky "limits" to what can be done. If the developer or the client cannot accept the limitations of the medium, then neither probably have any blasted business creating or running websites!!! Learn HTML, learn CSS, learn about accessibility and useability, STOP with the artsy fartsy BS that adds nothing of value to websites, accept the limitations of the medium created by the entire reason HTML even exists, and you wont have these problems. That or you'll cry over a beer and go flip burgers for a living... Which honestly is what I think most people calling themselves "designers" should probably go do. Just look at 99.99% of the ineptly developed crap at TemplateMonster, ThemeForest, or or even the "graphics and multimedia" section of these forums -- NONE of which has ANY damned business EVER becoming a website... Artsy fartsy crap where the people making it knew jack **** about HTML, CSS, Accessibility, Usability or even bandwidth constraints which is again why most such "designers" are only qualified to design two things; and Jack left town. "Design", they keep on using that word...
Thanks for your comment. This may be the reason. I've done the last two first. Sound like my story... It was back there... When I was to decide which programming language I have to learn in order to be able to enter the IT job market. I choose to learn top scripting languages first like most of the kids in town. No one learn HTML and CSS. One day, I got bore of coding back-end and decided that I want to show my skills to the wold. And then I enrolled for an HTML course. They taught us how to build a website for a restaurant using Dreamweaver. Maybe that makes me find it's challenge every time I want to integrate scripting languages into HTML. I find that JavaScript makes things easier as it can solve all the integration problems. When I showed my masterpiece of work first time here some times ago I was told to throw it to a trash by a bunch of people. One of them I can recall as @deathshadow. HOW DARE YOU! After I've learned more from those people, I realized that I have to learn proper HTML and CSS. That's why I keep asking people anything I'm intrigued. About taking time to learn, I don't think I will have time for that as I jump from one project to another and have time to sleep barely 3-4 hours a day. // edited: the real reason behind my enter into the front-end thing is an article about the potential of HTML5 and the increasing usage of mobile devices
It's what I do... It does indeed sound like you learned it backwards -- again though that's increasingly not so uncommon, but it is so nonsensical that I'm surprised how far people can get into it before they find that out. It's a little SCARY how deep into it you can get before learning that. JavaScript EXISTS to manipulate HTML, PHP exists to output HTML or glue HTML to information from other sources... so how can you learn to use JS or PHP properly before you know what they were created to output or manipulate? If you do learn those first without that, you probably also learned to do it wrong... Hence the comments that upset you... Well in terms of HTML, it's a LOT simpler than people make it. That might sound a bit strange, but the only reason HTML seems complex is people don't think about it properly -- and properly means saying what things ARE, or would be in a professionally written document. Of course, if you have no experience in professional documents like legal papers, scientific papers, term papers, product documentation, etc, etc many of the concepts of "logical document structure" like heading levels, emphasis vs. isolation, even just what qualifies as a paragraph and what doesn't can seem quite alien. In many ways I got lucky, I spent three years writing technical documentation for barcode scanners in the mid 1990's and learned most of these things before I even touched HTML. Most people nowadays even when writing things like term papers don't actually learn the proper formatting or why they are applying the visuals they are from a structural point of view. Laughably, HTML 5 has little if anything to do with the latter; but that's because a LOT of the things people are calling HTML 5, well... Isn't. A whole slew of things have been thrown under HTML 5's banner that have jack **** to do with being a markup language! This is made worse by them organizing the "specification" so that these things that should have jack to do with the MARKUP specification are now one massive slow loading impossible to follow mess -- hence why I now put "specification" in quotes when talking HTML 5. I know a few engineers who'd introduce their carpal bones to certain folks maxilla with significant force for even CALLING the current mess a specification -- a lot of that being that it's now documentative instead of authoritative -- the exact opposite of everything a specification is supposed to be. Take CANVAS replacing flash -- that's JavaScript, not HTML, there's no reason for that to even HAVE a HTML tag. Take the stupid pointless redundant AUDIO and VIDEO, they convey non markup content -- that's OBJECT's job and the specification has no business putting either a pointless meaning on them or saying anything about formats; there's nothing there that couldn't have been done with ONE interface on the existing tag. Then there's all the cool CSS3 stuff including of course responsive layout -- the very thing you were looking for on mobile. That too has not one Hey Zeus H mammary plowing Christmas thing to do with the markup specification. But it's become hot and trendy to lump them all under that same name willy nilly by the same halfwit mouth-breathing article writers who a few years ago were abusing the term "Web 2.0" without actually understanding what it meant.... which plays to most of HTML 5's true audience which is the people who were sleazing out HTML 3.2 and the proprietary crap that followed, then slapped 4 tranny on it. Which is why I advise learning to use HTML 4.01 STRICT first, then use the handful of useful time saving things 5 introduces and handful of things being shoved down our throats (like audio and video) while avoiding the nonsensical pointless redundancies that serve no legitimate purpose like SECTION, ARTICLE, NAV, FOOTER, HEADER, aria roles, etc, etc... Most of which only seem to exist to make "data scrapers" job easier. "Data Scraper" being a polite way of saying "Content Thief". They sure as shine-ola have dick all to do with accessibility, logical document structure or semantics. You'll find a LOT of people in the know saying much the same thing: "Code as 4 Strict, deploy as 5" is becoming more and more commonplace as advice.