Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,513
    Thanks
    4
    Thanked 506 Times in 494 Posts

    (split) Is the new CSS stuff treading on separation of concerns.

    Rather than go full threadjack answering a question in another thread, I thought I'd start a new thread.

    Quote Originally Posted by durangod View Post
    Which brings to me a thought here. Just as its no longer JS's job to handle styling do you feel that CSS is in some ways intruding on the purpose other languages as well? It just seems that the lines are getting more blurry the more powerful languages become.
    That is an EXCELLENT question worthy of its own thread. If anything I'd say the lines are becoming more well defined. The separation of concerns "client-side / front-end" is supposed to be content, presentation, and behavior -- HTML, CSS, and JS directly. Presentation is supposed to be device specific, hence the MEDIA attribute That we're supposed to have been using on stylesheet LINK and <style> tags since 1998 and why if you don't see media="screen" on a screen stylesheet the person writing it hasn't learned enough HTML to be styling a page. It's why 90% of the time you see style="" and 100% of the time you see <style> you're likely looking at incompetence, ignorance, and/or ineptitude; Since presentation in the majority of cases has no business in the markup... AND you're missing caching opportunities.

    Basically though it becomes a question of "what is behavior". It's easy to think that anything that changes in realtime based on the user is behavior, but that's presentation. Take the scenario of this thread, the JavaScript would assign those values directly on the DOM to style paying no heed to the media type. Style that is a presentational affectation that SHOULD have zero impact on screen readers, braille readers, print, search, etc... but you know what happens if you assign that type of thing via scripting? It applies to everyone.

    In this case it's not harmful, the height/overflow doesn't actually change the content, but thanks to things like scam artist black-hat SEO dirtbags abusing display:none for content cloaking 15-20 years ago, if that had been used or anything similar to it those non-screen media environments -- even ones where it makes no sense -- will obey it. This is why the CSS trick of aPo and left:-999em; are so common in dropdown menus.

    What is being done is manipulating the appearance, as such that's CSS' job even if using JavaScript. If it weren't, the script wouldn't -- and shouldn't be manipulating Element.style. As I said before, unless the value has to be calculated on the fly there is no real reason for any of that to be in the scripting -- at MOST what should be done if scripting were to be used any time over the past 20 years is a class swap.

    Hence something like this:

    Code:
        document.getElementById(elemid).style.height = '40px';
        document.getElementById(elemid).style.overflow = 'hidden';
    Would make more sense as this if you were to use JS.

    Code:
      document.getElementById(elemid).classList.add('hide');
    and then set the values in the stylesheet. This lets you have the MEDIA attribute add the presentation only where and as needed, have multiple different stylesheets that even have different appearance without changing the script. Say you change the font-size and want the height to match that. Do you want to dick around with your script, or do both right there on the same element in the stylesheet? The height is presentation, and presentation doesn't belong in your JS.

    Behavior, the thing a "real" programming language might be needed for, should be reserved for calculations, sending/receiving new data, etc. The reason we used it for presentation was that in a lot of cases it was the only option, or developers THOUGHT it was the only option because they didn't know CSS could do that.

    Look at dropdown menus. We've not "needed" JavaScript for that in anything other than IE6/earlier since, well... around 2003. It continued to be done because most people didn't understand .htc files to polyfill the missing bits in IE, got upset about having to add a new filetype to apache to support .htc properly, or just plain failing to update their techniques.

    Presentational animations are the same way. For easy dynamic slideshows based on the content, we do need JavaScript to handle the behavior side of what to show, but just as with what we're doing here there is no reason for how it is shown -- animations, etc -- to be any of JavaScript's business. That's why if I had a slideshow thus:

    Code:
    <div class="slideshow">
    	<img src="https://www.codingforums.com/images/image1.png" alt="placeholder image">
    	<img src="https://www.codingforums.com/images/image2.png" alt="placeholder image">
    	<img src="https://www.codingforums.com/images/image3.png" alt="placeholder image">
    	<img src="https://www.codingforums.com/images/image4.png" alt="placeholder image">
    	<img src="https://www.codingforums.com/images/image5.png" alt="placeholder image">
    	<img src="https://www.codingforums.com/images/image6.png" alt="placeholder image">
    </div>
    ... and yes, for an IMG only slideshow that likely should be the ONLY markup needed

    The scripting has no real reason to be any more complex than:

    Code:
    (function() {
    
    	var
    		speed = 1000,
    		slideshows = document.getElementsByClassName('slideshow');
    	
    	for (var i = 0, show; show = slideshows[i]; i++) {
    		show.data_current = show.firstElementChild;
    		show.classList.add('jsActive');
    		show.data_current.classList.add('current');
    	}
    	
    	function update() {
    		for (var i = 0, show; show = slideshows[i]; i++) {
    			show.data_current.classList.remove('current');
    			if (!(show.data_current = show.data_current.nextElementSibling)) {
    				show.data_current = show.firstElementChild;
    			}
    			show.data_current.classList.add('current');
    		}
    		setTimeout(speed, update);
    	}
    	
    	window.addEventListener('load', function() {
    		setTimeout(speed, update);
    	}, false);
    	
    })();
    Unless you wanted to do something like pass the speed via a data attribute, add controls, etc, etc. EVERYTHING else -- the presentation -- belonging in the stylesheet. You don't go derping around with element.style for that. ... and yes, I'm abusing the object model with my made up data_ attributes. I do that the same as the data- on the tags for storage, it's faster/simpler that way and has no real cause for issues.

    ... and even if the script runs, without the matching CSS it's just wasting CPU without doing anything which is not the perfect behavior, but a desired one.

    Though these days so long as I don't need selectable slides or other such extra navigation, and the number of images is to remain static, this too could be done with CSS. But as a simple example, look at the majority of scripts out there for slideshows. JUST for the above functionality, how convoluted are those scripts?

    It's so easy to "just dive for the JavaScript" as the answer for everything. It's why at its worst some decade ago when someone asked "how do I make a link turn red when the mouse is over it" you'd ALWAYS have some halfwit chime in with their mindless "use jQuery" and post 20 lines of JS for nothing to do the job of CSS' :hover.

    :target, :checked, and their ilk from CSS3 are doing the same thing, making a lot of things people dived for JS for not even be JS' job, because they really never should have involved scripting in the first place. We just used JS for it because there was no other way, or continue to do so out of ignorance.

    Basically we're not having CSS step on JS' toes, so much as lightening its burdens. We're not having CSS violate the separation of concerns, it's reinforcing them! I think any resistance or complaints in that regard can be dismissed as people who are upset that their favorite go-to toys -- like jQuery -- are losing relevance, or worse being pointed out for the absolute garbage they have been all along. Even JavaScript itself can fall into that trap.

    Again, in this particular case I don't mean ignorance as an insult. It just means you don't know any better. There is no shame or stigma attached to not knowing unless it's willful ignorance. SMART people ask questions when they don't know. SMARTER people ask questions when presented with new information that contradicts the old and then form an informed opinion. An opinion that can be changed when new facts arrive.

    ... and when it comes to web development, new technologies, new methodologies, and better ways are always arriving. The trick is developing the skills to recognize when something is a genuine improvement, and when some dirtbag snake oil peddler is taking you for a ride. Sadly, we have a LOT of sleazy dirtbag predators out there; W3Schools, jQuery, React, Vue, Bootstrap, Mootools, SCSS, LESS, SASS, etc, etc, etc. They're all either built out of ignorance and/or incompetence, or worse amount to nothing more than blatant outright nube predation.

    Hence those running websites like W3Fools or the forums/websites that do nothing but create cult-like echo-chambers stamping out dissent when it comes to their favorite tools have more in common with the predator priests diddling the altar boys than they do people interested in doing a good and proper job. Toxic positivity at its finest.

    JS for nothing and your scripts for free.
    That ain't workin', that's not how you do it.
    Lemme tell ya, these guys ARE dumb.
    Maybe get some scripting on your little server,
    Maybe add some CSS for fun.

    We got to install some heavy code now,
    Custom CMS, delivereyeyeyaaaaah.
    We got to move this database now.
    We got to trash this jQueereeeeeeeeeey.
    JS that is...

    I want my, I want my, I want my PHP.
    Last edited by deathshadow; May 25th, 2019 at 01:36 PM.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  2. #2
    Senior Coder durangod's Avatar
    Join Date
    Nov 2010
    Location
    East Texas USA
    Posts
    2,187
    Thanks
    368
    Thanked 58 Times in 56 Posts
    Sorry for the delay in reply, im busy working on my new land as well so coding takes a back seat... I have had a chance to read this but i need to form my thoughts so it might take a few days, right now i am trying to get my new fence built.

    Thanks for the reply and i will replay asap , nice reply by the way
    If a php file only has php code within it you do not need to use the closing php tag
    A good way to remember objects from arrays is you shoot objects with arrows Example: $name->id; then Arrays are $name['id'];
    durangod is short for durango dave

  3. #3
    Senior Coder durangod's Avatar
    Join Date
    Nov 2010
    Location
    East Texas USA
    Posts
    2,187
    Thanks
    368
    Thanked 58 Times in 56 Posts
    Quote Originally Posted by deathshadow View Post
    Since presentation in the majority of cases has no business in the markup
    So what situations would call for presentation(css) in the markup? Seeing as there is no rule book as to what is acceptable and what is not, as long as it works and functions as it should then people will continue to put as much css in markup as they need to in order to be lazy i suppose. Seems until markup bans css in the file people wont stop doing it. You say there are exceptions, i am curious about when would you put css in markup? What is the decision process and justification SOP?


    Quote Originally Posted by deathshadow View Post
    but thanks to things like scam artist black-hat SEO dirtbags abusing display:none for content cloaking
    Do you believe display:none should be regulated more or even deprecated for that reason?


    Quote Originally Posted by deathshadow View Post
    unless the value has to be calculated on the fly there is no real reason for any of that to be in the scripting
    I am curious what you consider "on the fly", wouldn't that be a personal decision, as every programmer is unique in their approach?

    Quote Originally Posted by deathshadow View Post


    Code:
        document.getElementById(elemid).style.height = '40px';
        document.getElementById(elemid).style.overflow = 'hidden';
    Would make more sense as this if you were to use JS.

    Code:
      document.getElementById(elemid).classList.add('hide');
    and then set the values in the stylesheet. This lets you have the MEDIA attribute add the presentation only where and as needed, have multiple different stylesheets that even have different appearance without changing the script. Say you change the font-size and want the height to match that. Do you want to dick around with your script, or do both right there on the same element in the stylesheet? The height is presentation, and presentation doesn't belong in your JS.
    I believe one major reason alot of people use JS for presentation is because:
    1. its easy to understand what it does just by looking at it, and style.height and the like are most common on the net as solutions to questions. Where as classList.add may be correct but its not presented as a solution most times and many dont even know it exists, thats just my opinion though.
    2. Wouldn't something like ClassList.add be level 2 js ?

    Quote Originally Posted by deathshadow View Post

    Behavior, the thing a "real" programming language might be needed for, should be reserved for calculations, sending/receiving new data, etc. The reason we used it for presentation was that in a lot of cases it was the only option, or developers THOUGHT it was the only option because they didn't know CSS could do that.
    I 100% agree, for someone new they see it as "hey its working it must be correct" and if they never have an issue where they need to divulge their code to other eyes then they never know there is a better way until someone corrects them.

    Quote Originally Posted by deathshadow View Post
    Look at dropdown menus. We've not "needed" JavaScript for that in anything other than IE6/earlier since, well... around 2003. It continued to be done because most people didn't understand .htc files to polyfill the missing bits in IE, got upset about having to add a new filetype to apache to support .htc properly, or just plain failing to update their techniques.
    Yes but the language and browsers developers hold some of that blame as well. Even now people will continue to use "what works" until it is deprecated or the browser stops supporting it and they are forced to find another way. So since developers have such power to force people into better habbits, shouldn't they also share the weight of those with bad habbits. All the devs need to do is tighten the belt alittle and push people down the right path. And not take 6 years to make the change after its announced, that is another reason.

    At what point do we stop allowing for creativity and tell Da Vinci "dont hold the brush like that, its not proper".


    More later... its meal time...
    Last edited by durangod; Jun 11th, 2019 at 04:39 PM.
    If a php file only has php code within it you do not need to use the closing php tag
    A good way to remember objects from arrays is you shoot objects with arrows Example: $name->id; then Arrays are $name['id'];
    durangod is short for durango dave

  4. #4
    Administrator VIPStephan's Avatar
    Join Date
    Jan 2006
    Location
    Halle (Saale), Germany
    Posts
    11,319
    Thanks
    7
    Thanked 1,361 Times in 1,330 Posts
    Quote Originally Posted by durangod View Post
    At what point do we stop allowing for creativity and tell Da Vinci "dont hold the brush like that, its not proper".
    At the point where programming isn’t painting and computer programs are only as capable of handling input as they are programmed, and efficiency is half the battle (with regards to maintenance and further development later on). Besides being considered “not proper”, mixing the behavior layer with the content layer can have negative impact on accessibility, for example.

  5. #5
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,513
    Thanks
    4
    Thanked 506 Times in 494 Posts
    Quote Originally Posted by durangod View Post
    So what situations would call for presentation(css) in the markup?
    When that style="" assists in the understanding of a value and/or helps add meaning to the content. The trick is to use it in a way or on elements where by default said style does nothing anyways.

    An example of this would be bar graphs built with HTML/CSS, where width or height are conveying -- or helping to convey -- the values. To that end I would even consider the use of a second class to indicate desired direction acceptable so long as the design itself remains dynamic and fluid.

    so...

    Code:
    <ul class="graph">
    	<li>10%<span style="width:20%"></span></li>
    	<li>50%<span style="width:100%"></span></li>
    	<li>25%<span style="width:50%"></span></li>
    	<li>20%<span style="width:20%"></span></li>	
    	<li>10%<span style="width:10%"></span></li>
    </ul>
    Code:
    .graph {
    	list-style:none;
    	overflow:hidden; /* wrap margins */
    	padding:1em 1em 0 4em;
    	border:0.25em solid #08F;
    }
    .graph li {
    	position:relative;
    	padding:0.5em 0;
    	margin:0 0 1em;
    	text-indent:-3em;
    }
    
    .graph span {
    	position:absolute;
    	left:0;
    	top:0;
    	height:100%;
    	background:#08F;
    }
    The width is the value, and width / height on SPAN -- being a inline-level element -- is ignored by default. you also have that width/height is ignored on elements if the parent element is position:static and/or has no width or height declaration of its own. It does not interfere with how the information is presented with style disabled, yet enhances the meaning visually when style is present. I would take that over a scripted or image based graph any day of the week. You want to add more colours, leverage nth-child instead of saying the colours in the markup.

    Quote Originally Posted by durangod View Post
    Seeing as there is no rule book
    TECHNICALLY there are THREE.. The HTML specification, the CSS specification, and the WCAG. It's just few people working with this stuff have bothered to read them, have trouble comprehending them if they tried, and worst of all they are not sufficiently enforced.

    Quote Originally Posted by durangod View Post
    in order to be lazy i suppose.
    The thing is, are they really being "lazy" when they are in fact creating MORE work for themselves, and making results that cause accessibility woes? A little learning could make things so much simpler/easier, but because garbage like frameworks, outdated -- and often predatory -- references like W3fools, and many so-called experts refuse to pull their skull out of 1997's rump, people will continue to work harder under the DELUSION that their bad practices are somehow magically "easier". Again see halfwitted rubbish like HTML/CSS frameworks. Must not use those two words... must... not.... There is such a reek of ignorance and incompetence (argh, couldn't do it) amongst those who CREATED things like jQuery, bootstrap, w3.css, etc, etc, that I cannot fathom why people use these by choice, apart from having been suckered into using them before they even knew enough on the topic to know if how they work was even proper, much less "easier".

    There's a rather insulting aspect to HTML/CSS frameworks and most of these bad practices, and it's a bit like 12 step programs in this regard. They start off basically saying that you are powerless to help yourself. That normal people aren't "smart enough" to write HTML or CSS. Think about that, think about the REAL message that is being delivered. They are telling us all that we're too stupid to do this "properly".

    That's why I'm so vocal -- and often equally insulting -- about this, as I truly believe that this is NOT rocket science, and that anyone who has made it past
    the fifth grade - or at least the fifth grade I went to -- should be able to handle this as the concepts simply are not that complex.

    "Sending a man to the moon isn't rocket science. Bringing him back alive is." -- Werner Von Braun.


    Quote Originally Posted by durangod View Post
    Do you believe display:none should be regulated more or even deprecated for that reason?
    No, there are legitimate usage cases for it, you just have to be careful it is NOT your default when the page loads if there is actual content inside it.

    Quote Originally Posted by durangod View Post
    I am curious what you consider "on the fly"
    Any changes to the page that are NOT the default with scripting or CSS disabled is an "on the fly" change. Be it using scripting to add DOM elements or change appearance, or using CSS "states" (:target, :hover, :checked, etc) to change aspects of the appearance.

    It all comes back to the big question: Is this content or presentation? Presentation has no business in the HTML as that was NEVER what HTML was created for, and the mere notion of doing it that way came about before CSS and HTML 4 Strict were a thing, and that separation of presentation from content is the very thing 4 Strict and CSS were created to restore. Seriously, go look at the HTML 2 specification, what was added in the abortive train wrecks of bad practices that were 3.2 or worse 4 tranny, then look at what was removed in 4 Strict. It becomes pretty obvious what's going on and that's why the people who spent 1998 to around 2010 letting 4 tranny top their pages, and now slap 5's lip-service doctype around their pages are all stuck in 1997's horrifically bad presentational mindset.

    I actually used this example on another forums a couple days ago. Remember when we used to have to write HTML like this, or did you avoid that chapter of our history?

    Code:
    <center>
    	<table border="0" cellspacing="0" cellpadding="8">
    		<tr>
    			<td width="33.33%" align="center">
    				<font color="green">Small column</font>
    			</td>
    			<td width="66.67%" align="center">
    				<font color="red">Large Column</font>
    			</td>
    		</tr>
    	</table>
    </center>
    Since again, we had no CSS? Consider what idiocy like w3.css (the framework from W3Fools that has dick-all to do with the W3C)

    Code:
    <div class="w3-row w3-display-middle">
      <div class="w3-col m4 l3  w3-green w3-center">
        <p>Small Column</p>
      </div>
      <div class="w3-col m8 l9 w3-red w3-center">
        <p>Large Column</p>
      </div>
    </div>
    They are using classes to say in the markup what things should look like, in a manner nearly identical to the old "tables for layout" approach. They have made ZERO improvements in methodology and are doing nothing more than dragging development practices back to the worst of the browser wars. Hell, with the smaller column -- likely a page sidebar on large resolution screen media -- first, they don't even have logical document structure. A pretty bad mess for what would done "properly" be:

    Code:
    <div id="content">
      <p>Large Column</p>
    </div>
    <div id="extras">
      <p>Small Column</p>
    </div>
    On most pages. Saying what things are and/or are for, and NOT what they actually look like. (it may or may not need the outer div, depends on what else is going on and how you make those columns.


    Quote Originally Posted by durangod View Post
    wouldn't that be a personal decision, as every programmer is unique in their approach?
    It really shouldn't be for common techniques and results we all aim for. It wouldn't be if the W3C wasn't so dottering and toothless, vomiting up a documentative "specification" (those are air quotes implying sarcasm) instead of an authoritative one, and worse said "specification" not even having been written for the people using the languages to create websites.

    REAL specifications are authoritative. They tell you how to do things cleanly, and more importantly safely/correctly. That idea and attitude is utterly and completely missing from HTML 5 just as it was in the train wreck of stupidity that was 4 tranny. Anyone with an engineering background should take one look at HTML 5 and recoil in horror as if that's a specification, I'm the Queen Mum.

    ... and again it's not even written for people who write websites. The "specification" defining the language used to write websites, isn't written for people who write websites! It's written for people who write browsers. How stupid is that? It's documentative and implementative, but not authoritative for those who actually use it on a day to day basis. Well there's your problem..

    You mix in the obtuse legalese and simple fact that for English language native speakers, it reads as if it were written in Finnish by a Englishman, translated to Japanese by a Russian, then Google translated back to English? Well, I never doubted myself for a minute for I knew that my monkey-strong bowels were girded with strength, like the loins of a dragon ribboned with fat and the opulence of buffalo dung.

    See something as simple as the word empty, and how when the specifications talk about empty tags, <div></div> is not even close to what they mean. They don't mean it doesn't have content, they mean it cannot wrap content. When such a simple word ends up so utterly jacked-up in definition, is it any wonder we're in the boat we are today of endless bad third party references people dive for rather than try to slog their way through the actual spec?

    Quote Originally Posted by durangod View Post
    I believe one major reason alot of people use JS for presentation is because:
    1. its easy to understand what it does just by looking at it, and style.height and the like are most common on the net as solutions to questions. Where as classList.add may be correct but its not presented as a solution most times and many dont even know it exists, thats just my opinion though.
    But is it really? The biggest problem is that what you do from the JS applies whether the rest of your style is present or not. There's no media targets in JS so you might be changing values that are complete gibberish for print, speech, tty, handheld, etc, etc. This is made worse by the same failing many people working with CSS do of going full Gungan by using the PX measurement.



    Quote Originally Posted by durangod View Post
    2. Wouldn't something like ClassList.add be level 2 js ?
    Not sure what that even means, if you are referring to the fact it is relatively new, it's a decade old now and we can tell IE8/earlier to sod off on scripting. That's my current practice at least of detecting IE8/earlier and just flat out not loading my scripting at all... since again GOOD scripting should enhance an already working website, and not supplant or be the only means of providing functionality.

    A concept a lot of scripting junkies mainlining JS like heroin seem to completely miss -- and make their lives harder by doing so.

    Quote Originally Posted by durangod View Post
    I 100% agree, for someone new they see it as "hey its working it must be correct" and if they never have an issue where they need to divulge their code to other eyes then they never know there is a better way until someone corrects them.
    The problem is in most cases, it isn't working for EVERYONE, and HTML is supposed to be inclusive, not exclusive. So much of the 'working' scripting people use result in pages that tell large swaths of potential users to go f*** themselves, and that is no plan for success. Be it from being broken due to browser bugs, not working because the user has scripting disabled/blocked/unavailable (see all the workplaces that hard disable JS for security reasons), or simply having what it blindly assumes can be done having nothing to do with what the media target is even capable of.

    Mind you, I'm talking websites here. Full stack web crapplets operate under different rules, but in those cases since node.js is the go-to under the hood you can guarantee that ALL the latest techniques work making things even easier!

    Quote Originally Posted by durangod View Post
    At what point do we stop allowing for creativity and tell Da Vinci "dont hold the brush like that, its not proper".
    When he decides the brush is a suppository for the audience, and starts trying to shove it up people's rump without even asking.

    Which is what non-semantic markup, a lack of separation of concerns, and failing to provide graceful degradation effectively do to a website's visitors... through accessibility failings, slow load times, and broken navigation/usability.

    Made all the worse when it also makes the back-end coder's life harder. Another example I used on another forum just recently... if you're working in PHP with a template that insists on throwing endless pointless classes at everything, mixed with the willy-nilly idiotic endless opening/closing of PHP, which of these is simpler to work with and induces less stress on the server when you have thousands if not millions of requests?

    Code:
    <?php
    
    $menuItemIndex = 0;
    ?>
    
    <?php
    function tmi($u, $t) {
    	global $menuItemIndex;
    	$menuItemIndex++;
    ?>
    		<li class="menuItem menuItem_<?php echo $menuItemIndex; ?>" id="menuItem_<?php echo $menuItemIndex; ?>">
    			<a href="<?php echo $u; ?>" class="menuLink"><?php echo $t; ?></a>
    		</li>
    <?php } ?>
    Or

    Code:
    <?php
    function template_menuItem($uri, $text) {
    	echo '
    		<li><a href="', $uri, '">', $text, '</a></li>';
    }
    Which would you rather maintain in a CMS? This is literally taken straight out of a system I rewrote for a client just a month and a half ago.. Which one do you think is going to hog the server more?

    That's how stupid this stuff is getting when in 99.99% of cases the two can be functionally identical to the end user. Crappy poorly thought out markup basically heaps manure on every poor sod trying to work on a site; front-end or back-end. To the point sooner or later the whole mess smells as bad as Biff Tannen's '48 Ford Super De Luxe.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  6. #6
    Senior Coder durangod's Avatar
    Join Date
    Nov 2010
    Location
    East Texas USA
    Posts
    2,187
    Thanks
    368
    Thanked 58 Times in 56 Posts
    DS thanks for the clarification, yes now i get where you are comming from on the matter.

    And yes i do remember doing tables this way when i first started html it was how we did it.

    Code:
    <center>
    	<table border="0" cellspacing="0" cellpadding="8">
    		<tr>
    			<td width="33.33%" align="center">
    				<font color="green">Small column</font>
    			</td>
    			<td width="66.67%" align="center">
    				<font color="red">Large Column</font>
    			</td>
    		</tr>
    	</table>
    </center>
    
    //except our table line was typically more like 
    
    <table width="100%" border="0" cellspacing="0" cellpadding="8" bgcolor="#ffffff">


    I dont quite remember if css was just not all the way there or it had not become SOP yet but i thought it was a grand idea because instead of having to change style in 20+ different files (total pain in the _ss) i could now just change one value in a css file. What a great idea i thought! Also back then i used to validate my files using the W3C validator lol.... I could not wait to be able to put that W3C logo on the bottom of my website lol..

    I dont believe we have seen the end of drastic changes either as we did in the old days. I think eventually mobile will take over everything and coding for desktops will be a thing of the past. I also believe that one day something new will come along to totally replace html and css and they also will be a thing of the past. HTML has not changed much since its birth (if you compare it to other improvements in the business) and one day someone will create something that puts it to bed forever, just like most things. Change will happen and we will either change with it or get left behind to watch others.

    At any rate i hope i am still around in 2038 to see if everything goes zonkers lol
    Last edited by durangod; Jun 16th, 2019 at 01:07 AM.
    If a php file only has php code within it you do not need to use the closing php tag
    A good way to remember objects from arrays is you shoot objects with arrows Example: $name->id; then Arrays are $name['id'];
    durangod is short for durango dave


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •