 CSS advantage over deprecated in-line tags ? |
  |
| Holmwood |
 Dec 5 2023, 03:32 PM
Post
#1
|
|
Group: Members Posts: 1 Joined: 5-December 23 Member No.: 29,095  |
First post here and just a general point as much as a query. I have a couple of small hobby websites and have not used CSS, but have been looking into it. Not sure I really see the point except that O'Reilly's HTML The Definitive Guide warns that numerous simple old-style tags are likely to be discontinued some time soon (and my edition is 20 years old*), like u for underline and even font.
I can see the point of CSS for Megacorps websites where they want a common corporate style and provide a common .css file for everyone to use. That's fine, but is there a good reason to deprecate and maybe discontinue the older simpler method? The Guide has an undertone that they wish deliberately to make it more tiresome to change font and colour etc, to discourage people from making their websites look like ransom notes. But is that a big problem these days? For example I want to make a single character in a text a different colour. Every example I found on the web of using CSS to change colour involved an entire block of text that already had some tag, such as a paragraph, division, heading, or the whole document. I did eventually discover the SPAN tag, so in my application I could do either with the old deprecated font tag :- CODE <BODY> The dial has black numbers for the shutter speeds, but the flash sync speed is shown with a red <font color=red>X</font>, which is 1/60th of a second. [etc etc] </BODY> Or I could use the significantly longer CSS approach, first defining the style attribute in the document head :- CODE <HEAD> <style type="text/css"> <!-- SPAN.redfont {color: red} --> </style> [etc etc] </HEAD> <BODY> The dial has black numbers for the shutter speeds, but the flash sync speed is shown with a red <span class=redfont>X</span>, which is 1/60th of a second. [etc etc] </BODY> I have abbreviated this code of course. Am I missing something? * 3rd edition, not the latest. This post has been edited by Holmwood: Dec 5 2023, 03:36 PM |
  |
 
|
| Christian J |
Dec 5 2023, 05:34 PM
Post
#2
|
|
.  Group: WDG Moderators Posts: 9,661 Joined: 10-August 06 Member No.: 7 |
QUOTE(Holmwood @ Dec 5 2023, 09:32 PM)  is there a good reason to deprecate and maybe discontinue the older simpler method? CSS is generally the simpler method, it both reduces the amount of code and also makes future changes much easier. QUOTE The Guide has an undertone that they wish deliberately to make it more tiresome to change font and colour etc, to discourage people from making their websites look like ransom notes. But is that a big problem these days? Didn't understand any of that.  QUOTE For example I want to make a single character in a text a different colour. For what purpose? Does the character have any special semantic meaning, or is it just a random decoration? The basic idea is to use HTML for semantic meaning, and CSS for presentation. In your example, perhaps the MARK or B elements could be (slightly) more semantically meaningful than SPAN, but the added benefit seems small: https://html.spec.whatwg.org/multipage/text...he-mark-element https://html.spec.whatwg.org/multipage/text...l#the-b-element QUOTE I did eventually discover the SPAN tag, so in my application I could do either with the old deprecated font tag :- CODE <BODY> The dial has black numbers for the shutter speeds, but the flash sync speed is shown with a red <font color=red>X</font>, which is 1/60th of a second. [etc etc] </BODY> Or I could use the significantly longer CSS approach, first defining the style attribute in the document head :- CODE <HEAD> <style type="text/css"> <!-- SPAN.redfont {color: red} --> </style> [etc etc] </HEAD> <BODY> The dial has black numbers for the shutter speeds, but the flash sync speed is shown with a red <span class=redfont>X</span>, which is 1/60th of a second. [etc etc] </BODY> I have abbreviated this code of course. Am I missing something? The advantage with CSS is if you one day want to change the style of the element (color, background, font family, size, boldness etc), and only need to do it in one place. This assuming there are several occurences of the above CLASS on the website; if there's only a single occurence you might use the STYLE attribute instead, like: CODE The dial has black numbers for the shutter speeds, but the flash sync speed is shown with a red <span style="color: red; background: white;">X</span>, which is 1/60th of a second. ...but since most websites use CSS for many different elements it's usually more practical with a separate stylesheet instead of mixing parts of the CSS with the HTML. In theory you might also apply CSS to the FONT element; since FONT and SPAN both lack semantic meaning, but it might be considered bad coding habit to use old deprecated elements like FONT in new code. BTW, you don't need the <!-- --> comments in stylesheets anymore, also you can leave out the TYPE attribute if you write HTML5. |
|
|
|
| pandy |
Dec 6 2023, 02:50 AM
Post
#3
|
|
🌟Computer says no🌟 Group: WDG Moderators Posts: 20,733 Joined: 9-August 06 Member No.: 6 |
QUOTE(Holmwood @ Dec 5 2023, 09:32 PM) O'Reilly's HTML The Definitive Guide warns that numerous simple old-style tags are likely to be discontinued some time soon (and my edition is 20 years old*), like u for underline and even font. That has already happened. FONT was among the first to go, and rightly so. It was already deprecated 20 years ago when you bought that book. That doesn't mean they don't work. IIRC B was never deprecated though. As Christian says, CSS is really simpler. Your example of coloring a single letter is an exception from the rule. Think instead of the normal case. You have a page with a lot of paragraphs. With only HTML you need to do this. CODE <p> <font face="Arial" size="3">Blah blah blah...</font></p> <p> <font face="Arial" size="3">Blah blah blah...</font></p> <p> <font face="Arial" size="3">Blah blah blah...</font></p> <p> <font face="Arial" size="3">Blah blah blah...</font></p> ... And if you want to change anything you need to edit all those font tags on all pages. With CSS you only have this. CODE <p> Blah blah blah...</p> <p> Blah blah blah...</p> <p> Blah blah blah...</p> <p> Blah blah blah...</p> ... And a single line of CSS that is easy to change. CODE p { font: 100% Arial, sans-serif } If it's worth it to you to rework your sites, I don't know. If you are still working with them, adding new content and so on, I'd say yes, go for it. If you just keep them up but don't do much with them, maybe not. Unless you see it as an opportunity to learn. |
|
|
|
| Jason Knight |
Dec 8 2023, 12:10 AM
Post
#4
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
See, the HTML you're used to is what I like to call the "S*** how of 'screw the users' known as HTML 3.2". I call it this because the entire point of HTML when it was created was to say what things are structurally and grammatically, NOT WHAT THINGS LOOK LIKE!
This is so that the user-agent -- a browser is a UA but a UA isn't always a browser -- can best convey that MEANING to users of all devices and capabilities, not just the magically perfectly sighted on the perfect resolution desktop display. That's what HTML was SUPPOSED to be for from day one! And something HTML 3 and the "browser wars" pissed on from so on-high you'd think the almighty just got back from a kegger. It was never the right way of doing things; only existed because of Microshaft and Nyetscape screaming "mine's bigger" at each-other in the executive washroom; and for something that only was actually a way of doing things for not even four years, we've spent 25 years fighting the horrifically bad habits and ideas it shart on the chessboard with. HTML 4 Strict and by extension CSS were created to drag us back to that original point. Of caring about what things are so that sites are accessible to everyone and everything. Braille, speech/aural, print. That's why FONT and CENTER got the axe alongside properties like bgcolor, border, and align. It is also why <style> and <link rel="stylesheet" has the MEDIA attribute. So you can say media="screen" to not send your screen-only appearance to UA's that don't give a flying purple fish about your visuals. Or target media="print" to specifically style for just that target. Leveraging media targets and not confusing users of non-screen media with the artsy-fartsy crap is a major concern in regards to accessibility. And when you can now be sued or prosecuted in almost any type of business related website, you better start caring about accessibility! When big names like Domino's fights it all the way to the supreme court and gets the door slammed in their face, what chance do us normies have of fighting it? It is to this end that if you are choosing ANY of your HTML to say what you want things to look like -- instead of based on grammatical and structural norms you should have learned by the fourth grade -- you have completely, utterly, and totally failed to divine HTML's purpose. This "separation of concerns" between content / grammatical structure and meaning and appearance pays many many other benefits besides accessibility and non-visual users. DRY Look at HTML 3.2 / 4 Tranny idiocy like this: CODE <table cellpadding="0" cellspacing="0" border="0"> <tr> <td><a href="/"><font size="+1" color="#333"><b>Home</b></font></a> </td> <td><a href="/contact"><font size="+1" color="#333"><b>Contact</b></font></a> </td> <td><a href="/faq"><font size="+1" color="#333"><b>FAQ</b></font></a> </td> <td><a href="/forums"><font size="+1" color="#333"><b>Forums</b></font></a></td> </tr> </table> Entirely typical of the trash people were writing 25 years ago... but what the blazes makes a menu tabular data? That's a LIST. Of navigation choices. And it repeats itself over and over and over again for things that with CSS you can just say ONCE! Today that same menu would (or at least should) be written in the markup as: CODE <nav id="mainMenu"> <ul> <li><a href="/">Home</a></li> <li><a href="/contact">Contact</a></li> <li><a href="/faq">FAQ</a></li> <li><a href="/forums">Forums</a></li> </ul> </nav> With this CSS in an EXTERNAL stylesheet. CODE #mainMenu ul { list-style:none; display:flex; gap:1rem; } #mainMenu a { color:#333; font-size:1.2rem; font-weight:bold; } Let's say instead of four menu items you have ten... can you start to see the advantage? How much nicer is it to be able to edit the code in one place to change the colour, size, or font-weight on all of them? Much less having proper semantics for accessibility of marking it as both navigation and a list of choices! Instead of the GIBBERISH of it being a table when it clearly is not. That's why it was called 4 transitional -- as it literally means "in transition from 1997 to 1998 development practices." Also why I keep saying HTML/CSS framework fanbois should admit defeat and go back to writing the HTML 3.2 they all so clearly and dearly miss, since not one of those clowns with their asinine "utility classes" are qualified to write a single blasted line of HTML! Now you'll notice I placed "more emphasis" on EXTERNAL files. Why? Caching HTML is cached less frequently because content changes more than style. The next time someone visits that same page you can use less bandwidth because they may already have your external stylesheet cached. It also allows for pre-caching. By placing style that's shared across all pages in an external stylesheet, you can pre-load that same appearance on sub-pages wasting less time transmitting the markup. HTTP Parallelism HTTP can download multiple files simultaneously, but browsers can ONLY do this once the HTML has finished loading. This parallelism can exceed the speed client or server could accomplish with just one connection due to how files are sent broken into "packages" along different routes between the two points. It also "hides" the overhead called "handshaking" of the client and server going back and forth to see if a file exists, if it's been changed, and so forth. Server load / server side complexity The more you can move out of the markup, the less the server-side developer has to wade through to slice up the "design" into their code. The less the server has to spend time gluing together. The less the server and client has to spend time gzipping on unique requests. Moving as much as you can -- appearance, scripting, scripting only elements -- out of the markup can result in parallelism kicking in sooner, and better leveraging of caching models. All that should be in your markup is HTML tags saying what things ARE and how they are structured, not appearance, not scripting only elements (like button), not even classes or ID's to say what things look like! Which is why halfwitted idiotic gibberish frauds like bootstrap and tailwind are monuments to the ugliest of 1997 development practices, and any nincompoop singing their praises needs a quadruple helping of sierra tango foxtrot uniform! As I often say if you step in bootcrap you might want to find a stick to scrape it off with, before you go tracking it all over the web's carpets. ... Simply put, if you care in the slightest about accessibility, usability, bandwidth, speed, ease of creation, ease of maintenance, or any other meaningful metric of a quality website? You should not be using HTML to say what you want things to look like! ANYONE telling you otherwise is either a charlatan, or so ignorant of the basics of HTML they have not one lick of business flapping their yap on the topic. Which perfectly describes the majority of fraudsters like Otto, Thornton, and Wathan with their nose-breathing half-tweet "framework stupid!" We have a real problem in web development with ignorant poseurs trying to drag development practices back in time 25+ years whilst praising their malarkey as the latest hot wetness. What a crock. |
|
|
|
| Jason Knight |
Dec 8 2023, 12:18 AM
Post
#5
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
[quote name='Christian J' date='Dec 5 2023, 05:34 PM' post='146764']
For what purpose? Does the character have any special semantic meaning, or is it just a random decoration? This, THIS, A THOUSAND TIMES THIS!!! What structural, grammatical, or logical reason do you have for it to be red? What meaning would it being red have to users having it read aloud to them or running their finger over it in braille? What meaning would it have for search? Remember the old rule, search engines don't have eyeballs. They too don't give a flying purple fish about your layout, colouration, fonts, padding, margins, widths... unless it's to check that you're not trying to abuse such values to game the system with such black hat SEO trash as content cloaking. HTML is not, nor was it ever actually supposed to be for saying what things look like. That's why HTML 3.2 (and by extension 4 tranny) went the way of the dodo nearly as fast as it was introduced. And it's a shame garbage like O'Reilly's "definitive guide" ever even got published, much less anyone believed any of the tripe inside it. Much less the endless idiotic web-rot we're still fighting against 20+ years later with all the people who refuse to extract their cranium from 1997's rectum. And sorry if I'm a bit vocal on this, I've spent the past 12 years as an accessibility and efficiency consultant helping major firms in both criminal and civil cases for the types of failings all of this type of trash creates. It's at the point where I'm now advising clients to sue former employees and contractors for criminal negligence... on top of fighting existing staffers who scream "wah wah is not" and "we didn't do anything wrong" and doing anything they can, parroting any lies, and making up any excuse they can come up with to not admit wrongdoing. It's a bit frustrating. |
|
|
|
| Jason Knight |
Dec 8 2023, 12:25 AM
Post
#6
|
|
Advanced Member Group: Members Posts: 103 Joined: 25-December 22 Member No.: 28,719 |
And seropiously, given that book is at least three versions behind on both HTML and CSS, decades behind on best practices, and is teaching you an HTML nobody should even be using any time after 2003-ish?
Light it on fire. Go here: https://developer.mozilla.org/en-US/docs/Web/Tutorials I mean Christmas on a cracker it has you writing HTML in uppercase and probably without DOCTYPE or character set declarations. |
|
|
|
|
3 User(s) are reading this topic (3 Guests and 0 Anonymous Users)
0 Members:
|
Lo-Fi Version | Time is now: 27th April 2024 - 01:44 PM |
Invision Power Board
© 2024 IPS, Inc.
Licensed to: HTMLHelp.com, LLC