1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

How can I control table format?

Discussion in 'HTML & Website Design' started by SoftLink, Apr 10, 2018.

  1. #1
    Hi:
    I'm not a noob. I've been writing html for 20 years.

    I'm trying to create a table dynamically and cannot get it to format correctly.

    The first row should be a specific height.
    The second row should be a different specific height.
    All remaining rows should be of equal heights to fill up the table.

    The same is for the columns.

    As soon as I fill it with data the table format is completely trashed.
    I've set tr & td max-width, max-height; I've set width & height properties on the td outside of css; I've set overflow:hidden.

    CSS, seemingly randomly, ignores everything I tell it.
    As soon as it sees data (via javascript) it blows the td sizes way out.

    Is there any way to control a table's layout without using table-layout: fixed ??
    I'd even use that except that I need the first & second column widths to be different than the rest.
    I thought about using grid but it can't collapse or change.
    The 'grid' has to stay exactly the same size regardless of what goes into it.
     
    SoftLink, Apr 10, 2018 IP
  2. sarahk

    sarahk iTamer Staff

    Messages:
    28,494
    Likes Received:
    4,457
    Best Answers:
    123
    Trophy Points:
    665
    #2
    can you set up a jsfiddle, it seems like it should be relatively easy especially with css letting us specify child(n) to work with.
     
    sarahk, Apr 10, 2018 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #3
    Generally tables are meant for dynamic layout of content, not things like 'fixed heights' -- their priority is showing the data, NOT specific layout which is why it is NOT a layout tool, it's a semantic container. It says "this is tabular data" where the rows and columns have a semantic relationship.

    As such given what you are asking about tables, it begs the question "Is this even tabular data?"

    If it IS tabular data, are you leveraging the full and proper semantics of a table with CAPTION, THEAD, TBODY, TH, and SCOPE?

    In general though "has to stay exactly the same size regardless of what is put in it" is the ANTITHESIS of good web design, a concept you shouldn't even be considering in the first place -- BUT there are always exceptions. To that end, without seeing the data it's hard to say one way or the other how your sizing should be handled or even if it should be a table in the first place.

    I mean, if you're thinking in terms of some sort of grids and it's NOT actually tabular data with semantic relationships, you might consider something like the CSS3 Grid Layout module. It's relatively new, doesn't exist in IE9/earlier and needs prefixes in 10, 11, and early versions of edge -- but all modern browsers have added full support over the past year; even edge added the current spec back in October.

    NOT that 'grids' are good web design either, which is why even when I use 'grids' I typically still have at least one column fluid and the others elastic.
     
    deathshadow, Apr 10, 2018 IP
    kk5st likes this.
  4. SoftLink

    SoftLink Active Member

    Messages:
    103
    Likes Received:
    5
    Best Answers:
    0
    Trophy Points:
    60
    #4
    Deathshadow Thanks for the response.
    I should say, in general I have respect for your obvious expertise and your dedication to helping people here.

    Frankly, I couldn't care less what 'good design' is.
    I need a grid that will stay the size that I make it to be before the data is put into it.
    It needs to simply truncate (overflow:hidden) anything that doesn't fit.

    We could argue for days about what 'good design' is but in short, I vehemently disagree with you.
    An html table should NOT restrict my usage of it. I don't know on what grounds you're making your claim.
    My attitude is tabular schmabular. I want what I want.
    If I insisted on a 500px width total and 6 columns, each having a 100px width, that would be a logical problem.
    That is not the case.
    I need a table that will NOT grow. It's for an application that uses a projector.
    It must truncate data if needed. It cannot grow. NO scrollbars!

    I've created a codepen.io that we can use to test.
    https://codepen.io/SLSCoder/pen/aYMxXo?editors=0100
    I can't get the borders to work. The browser is ignoring the css, like it often does.
    I want no border in the top, left corner blank cells but a solid border to clearly display the grid's outer edges and each data cell.

    When I load the data, it destroys the grid. It should truncate the data.

    Any help would be greatly appreciated.
     
    SoftLink, Apr 11, 2018 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #5
    Tables don't do that because they are not design elements, they are SEMANTIC elements that have MEANINGS. That's a good part of what you are missing here.

    Your 'usage' doesn't sound like what either HTML or CSS were even created to do.

    Then you are not grasping the point of HTML. Saying what things ARE, and NOT what you want them to look like. Almost sounds more like you want to make a static image, not a page of data built with web technologies.

    Except that you shouldn't be using pixels in the first place for things like widths, particularly if your fonts aren't declared in pixels. You have an illogical/nonsensical statement there.

    Though your CSS clearly suffers from that. You're mixing metrics all over the place with vh here and vw there and pt (points are for print, not screen) over there... and not a single sign of the metric the WCAG tells us to use, EM. How exactly are you expecting PT fonts -- a dynamic non-static value that has no fixed relationship to pixels -- to obey a pixel height declaration on the container?

    Which is the detail you left out -- and why HTML and CSS may in fact be unsuited to the job you are trying to do. Whilst making applets with full stack web technologies are hot and trendy, HTML and CSS first and foremost are about accessible delivery of content to users, NOT pixel perfect design nonsense that perfectly fits exactly. That's print mentality, not screen media mentality and to that end you may simply be trying to use the wrong tool for the job!

    THAT or you need to NOT use a table and throw semantics and accessibility out the window, using other non-table elements to build the page. Tells users with accessibility needs to go F*** themselves, but if your only task is to build a crapplet to he shown on a projector that is probably no longer a concern. Float a bunch of DIV, set them to overflow:hidden, and be done with it. If you don't care about the reason HTML tags have meanings (such as this is tabular data with semantic relationships) for this usage scenario, don't use the tags that actually mean something OTHER than "show this as rows and colums"!

    Remember, the base meaning of HTML tags is for ALL users -- even the blind. Saying what things ARE so that the user-agent (a browser is a UA but a UA isn't always a browser) can best convey that meaning within the needs and capabilities of the hardware AND the user. If you choose ANY of your HTML based on what you want things to look like, you're choosing all the wrong tags for all the wrong reasons!

    ... and your markup reflects that nobody ever told you any of the above, or even explained to you that there are MORE tags that go into a table than just TR and TD. You're missing half the semantics and relationships that using a HTML table PROPERLY involves, then throwing classes at everything for no good reason.

    It also makes me wonder just what your problem would be with table-layout:fixed given it sounds like that's what you actually want...

    The PROPER HTML for a table containing data in that type of organization is:
    
    <table id="tblGrid">
    	<thead>
    		<tr>
    			<td></td>
    			<td></td>
    			<th scope="col">Bob</th>
    			<th scope="col">Jerry</th>
    			<th scope="col">Angie</th>
    			<th scope="col">Sue</th>
    		</tr><tr>
    			<td></td>
    			<td></td>
    			<th scope="col">A</th>
    			<th scope="col">B</th>
    			<th scope="col">C</th>
    			<th scope="col">D</th>
    		</tr>
    	</thead><tbody>
    		<tr>
    			<th scope="row">Events</th>
    			<th scope="row">1</th>
    			<td></td>
    			<td></td>
    			<td></td>
    			<td></td>
    		</tr><tr>
    			<th scope="row">Programs</th>
    			<th scope="row">2</th>
    			<td></td>
    			<td></td>
    			<td></td>
    			<td></td>
    		</tr><tr>
    			<th scope="row">Facilities</th>
    			<th scope="row">3</th>
    			<td></td>
    			<td></td>
    			<td></td>
    			<td></td>
    		</tr><tr>
    			<th scope="row">Equipment</th>
    			<th scope="row">4</th>
    			<td></td>
    			<td></td>
    			<td></td>
    			<td></td>
    		</tr><tr>
    			<th scope="row">Notes</th>
    			<th scope="row">5</th>
    			<td></td>
    			<td></td>
    			<td></td>
    			<td></td>
    		</tr>
    	</tbody>
    </table>
    
    Code (markup):
    It helps to actually know ALL the tags that go into a table and how to use a table properly BEFORE you start throwing 'classes for nothing' at it much less trying to style it. That's not on you -- 90%+ of the people out there writing tutorials and books seem unaware of this! Every time you see something like:

    <td colspan="5"><strong>Table Title</strong></td>

    or

    <td><strong>Column title</strong></td>

    You can GUARANTEE that the author hasn't learned enough HTML to be telling others how to do it. That's CAPTION and a TH with SCOPE inside a THEAD's job respectively!

    Oh and on the border issue, I'm unclear what borders you are trying to set, but border-collapse:collapse; might help, as would box-sizing:border-box; Without the latter border is added to your heights IF heights are obeyed. By default in tables heights are NOT supposed to be obeyed so... I'd also suggest only setting the border on ONE side, not all-around.

    Styling it to force the overflow though, well that is problematic but not impossible. Actually, thinking on it... an extra DIV inside the TD you want cut-off may be the answer, you just absolute position the DIV inside the dynamically sized TD with it set to overflow:hidden. That would give you the desired cutoff. Absolute positioned elements are removed from flow, so they do not report their height to their parent. If you just let the table auto-size the TD they will evenly distribute the remaining width... set the TD to position:relative so the DIV are absolute to it, and you're good to go!

    
    /*
    	Elements who's parents don't have height other than HTML will not
    	obey percentage heights!
    */
    
    html, body {
    	height:100%;
    }
    
    body {
    	font:normal 100%/150% arial,helvetica,sans-serif;
    }
    
    #tblGrid {
    	border-collapse:collapse;
    	table-layout:fixed;
    	width:100%;
    	height:100%;
    }
    
    #tblGrid thead th,
    #tblGrid thead td {
    	height:1.5em;
    }
    
    #tblGrid thead td {
    	width:7em;
    }
    
    #tblGrid thead td + td {
    	width:2em;
    }
    
    #tblGrid thead td,
    #tblGrid th {
    	background:#35A;
    	color:#FFF;
    }
    
    #tblGrid thead tr + tr td + td,
    #tblGrid thead tr + tr th,
    #tblGrid tbody th + th {
    	background:#000;
    }
    
    #tblGrid tbody th:first-child {
    	text-align:right;
    	padding-right:0.5em;
    }
    
    #tblGrid tbody td {
    	position:relative;
    	border:1px solid;
    	border-width:0 1px 1px 0;
    }
    
    #tblGrid tbody td div {
    	position:absolute;
    	top:0;
    	left:0;
    	overflow:hidden;
    	width:100%;
    	height:100%;
    }
    Code (markup):
    Just add that extra DIV and it should work. I also decreased the width of the first TH row to show you where/how that's set. Just let everything else auto-adjust to fill evenly. That's where a LOT of people working with layouts will screw up is thinking they have to declare widths on everything, instead of declaring on just one part and letting the rest do what they do naturally.

    I tossed this together in a little demo with some lorem-ipsum plugged into the data fields to test on my server:
    http://www.cutcodedown.com/for_others/softLink/template.html

    As with all my examples the directory:
    http://www.cutcodedown.com/for_others/softLink/

    Is wide open for easy access to the gooey bits and pieces.

    Hope that helps. What you're trying to do isn't really what HTML is meant to do, so there will be some issues. Even with these fixes if the window is too short to actually fit at LEAST the TH contents it will give you a vertical scrollbar -- and I'd leave it that way. In terms of your data though, this should be all you need.

    Just be warned this is coded for modern browsers, this will not work in ANY version of the mentally enfeebled train wreck that is IE... but since you said "application" I would think that's a non-issue as that implies you have actual control over which browser engine is in use. (typically either blink or edgeHTML). For some reason if you absolute position elements inside a TD in IE, you cannot extract the parent tag's width and height. I suspect this is the 'parent doesn't have a height' part of the specification being obeyed in a place it should be ignored as TD are not block-level, they're special case.

    But if all you care about is blink, quantum, or edgeHTML this should get the job done. I think legacy Gecko also goes bits-up face-down on this, but don't quote me on that. Given the number of bugzilla issues that are now of legal drinking age, I'm pretty sure I've seen this before. If you need legacy IE support... well, then you'd probably have to override display:table, table-row, and table-cell and force them into display:block and either float, flex, or css-grid behavior.

    The joke being that IE9/earlier doesn't actually have the latter two of those.

    Oh and sorry I didn't do it in codepen, but I find its uselessly illegible colour syntax highlighting (never been a fan of that asshattery) and even more uselessly tiny editor boxes to be complete trash. Not a fan.
     
    deathshadow, Apr 11, 2018 IP
  6. sarahk

    sarahk iTamer Staff

    Messages:
    28,494
    Likes Received:
    4,457
    Best Answers:
    123
    Trophy Points:
    665
    #6
    that's all true

    but the short answer might just be

        word-break: break-all;
    Code (markup):
     
    sarahk, Apr 11, 2018 IP
  7. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #7
    Unless I completely missed what he was asking -- for NO scrollbars EITHER direction (up or down) -- that would be completely unrelated. The table is still going to grow vertically. Also assumes all his content is text and that might not be the case either...

    BUT you COULD be right since we were never shown the data. DATA dictates markup, DATA + markup + device capabilities dictates layout, NOT the other way around!
     
    deathshadow, Apr 11, 2018 IP
  8. sarahk

    sarahk iTamer Staff

    Messages:
    28,494
    Likes Received:
    4,457
    Best Answers:
    123
    Trophy Points:
    665
    #8
    He knows how he can control all of that already, his primary problem appears to be long strings that blow out the dimensions.
     
    sarahk, Apr 11, 2018 IP
  9. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #9
    I do not see that said anywhere in anything he has posted in this thread. At all.

    In particular this:

    >It must truncate data if needed. It cannot grow. NO scrollbars!

    Pretty much says it. NEITHER dimension should grow, it should be cutting off data HEIGHT-WISE as well. Word-wrapping and break-word have NOTHING to do with that. He's trying to make a full screen fixed layout with NO scrollbars -- so the table ITSELF remains the full height of the screen.

    At least, that's what it sounds like. Would be consistent if this is being put up on a projector where things like scrolling EITHER direction are difficult/impossible or just a pain in the arse.

    If that's not the case, why is he trying to declare this?

    
    . tdDataCell {
      height:75px;
      max-height:75px;
    
    Code (markup):
    He doesn't want the HEIGHTS of the data cells growing either! As such break-word has dick-all to do with it.
     
    Last edited: Apr 11, 2018
    deathshadow, Apr 11, 2018 IP
  10. SoftLink

    SoftLink Active Member

    Messages:
    103
    Likes Received:
    5
    Best Answers:
    0
    Trophy Points:
    60
    #10
    Thanks.
    "NEITHER dimension should grow" that's correct.
    "He doesn't want the HEIGHTS of the data cells growing either!" Correct.
    "this is being put up on a projector where things like scrolling EITHER direction are difficult/impossible or just a pain in the arse." YES!

    I appreciate your comments but completely disagree with you.
    I don't think the W3C has the right to dictate what I will do with the technology.
    It's technology, not a philosophy.

    Is there a way to do what I'm trying to do?
    If not, I'll just use layers and truncate the data programmatically in Javascript.
     
    SoftLink, Apr 12, 2018 IP
  11. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #11
    Does my example:
    http://www.cutcodedown.com/for_others/softLink/

    That I provided in the Fifth post of this thread not do what you are asking? Did I miss some essential detail?

    It's not "just a technology" it is a TOOL that was designed for a specific purpose with RULES. That's why everything isn't a DIV and why you can't just make up your own tags any-old-way like you can in XML. Those RULES exist for a REASON -- that reason being accessibility design and content delivery.

    What you are trying to do is NOT what HTML or CSS were designed to do. At all. Perfect screen size fixed height containers are the ANTITHESIS of accessible web design. You are using web design technologies, but are trying to do something that is the OPPOSITE of what it was created to do.

    Think of it this way, you're trying to drive a screw with a hammer. It is the WRONG technology for what you are trying to do. What you are trying to do sounds almost more like a job for Powerpoint or a proper native development language, and not HTML or CSS.

    Markup and stylesheets were simply NOT created to do what you are asking to do. At all. NOT what they are FOR.
     
    deathshadow, Apr 13, 2018 IP
  12. SoftLink

    SoftLink Active Member

    Messages:
    103
    Likes Received:
    5
    Best Answers:
    0
    Trophy Points:
    60
    #12
    You did solve it and I missed it. Sorry about that and thanks.
    Your css is really great code. I've always hated css.
    I had to abandon my first site using css because the browsers couldn't do css yet.
    This will make me study it a little more.

    When I posted that I might use a div in a layer I realized I didn't need the layer and the div would probably solve it.
    Your example is great code - simple and effective.
    After all that ranting I have to admit I'm surprised. You really are good at this.

    I don't really expect the users to be able to see the notes in the grid.
    The app will be used in a conference room in a group meeting.
    Participants add notes to the grid from another interface on their cell phones.
    The facilitator will click a cell and it'll blow up into the center of the screen so they can read it easily.
    It works great except that the notes kept trashing the grid.

    By your rules I'd probably have to put 3/4 of what I do into an applet.
    It's all cloud based, so yea, software using php/html/css/javascript.
    It's easier than making applets and more reliable to deploy.
    I've been using php/html/css/javascript (actually classic ASP & VB script back when) to build apps for a real long time.
    Larry Ellison (Oracle) suggested it a long time ago. I was doing it then.

    I've never heard anybody talk about html rules like you do.
    Is that in the W3C docs? Where did you get that?
     
    SoftLink, Apr 13, 2018 IP
  13. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #13
    So... you've never encountered the concept of "semantic markup"? Separation of presentation from content? Progressive enhancement? Graceful degradation? Accessible design?

    Surely you've at least HEARD of semantic markup, right? The sick euphemism for "using HTML properly" that came into being so as not to offend the mouth-breathers who spent a decade and a half vomiting up the disastrous HTML 3.2 style methodology whilst slapping the 4 tranny doctype atop it, and who today slap the HTML 5 doctype atop the same outdated outmoded ignorant techniques but slap each-other on the back over how 'modern' they are whilst ignoring the entire reason HTML was even CREATED?

    When Tim Berners-Lee created HTML it was to address a very unique problem. Text and other data coming from multiple sources and multiple hardware platforms, that over DARPANet really needed a single unified file format that would allow professionally written documents to be conveyed to users regardless of the device's capabilities. Scientific papers, legal documents, publications -- all needed a format that EVERYONE could use. In professional writing presentational effects -- bold, italic, line-breaks, bullets, headings -- are done for grammatical and strucural reasons. The issue with this is that not all devices could output bold, or italic. They lacked a uniform screen size. Not all of them were even graphics capable and operated in text only video modes. MANY of them didn't even use screens and used a printer.

    The entire purpose of HTML was to say WHAT and WHY things were for those grammatical and structural reasons, so that the user-agent (a browser is a UA but a UA isn't always a browser) could try to the best of its capabilites to convey that MEANING. From old-fashioned phone TTL, to teletype terminals, from 21x22 VIC=20 text to 132x56 high end terminals, from 256x192 Sinclair Speculum to the 1152x836 graphics of the NeXT workstation he was sitting at, DIDN'T MATTER. They ALL should have been able to have some means to convey that MEANING.

    Nothing at ALL like today where all these devices are the same screen size, same resolution, same ppi, running the same OS with the same font rendering capabilities. That's called sarcasm.

    The concept holds up today since HTML is still for MORE than just screen media. Screen readers (software that reads the page aloud), braille readers, and search engines are all non-visual UA's that well written HTML exists to deliver content to.

    That's why <b> and <i> do NOT mean "show this text as bold and italic", it MEANS "this text would be bold or italic in a professionally written document" -- such as proper names (bold), parties in a legal document (bold), book titles (italic) when not being <cite>d or being <em>phasized! Hence why the turds claiming that <b> and <i> are, were, or will soon be deprecated are flapping their arse-cheeks in the wind. SOMEHOW they magically turned "use EM and STRONG when their semantic meaning is more appropriate" into "never use B and I" -- that's NOT what was being said! NO shock on that misunderstanding though, see all the halfwits, morons, and fools who turned "don't use tables for layout" into "Never use tables" -- tables exist to convey tabular data with the full semantic meaning!

    JUST as H1..H6 do NOT mean "fonts in different weights and sizes" nor does <hr> mean "draw a line across the screen"!!! An H1 (unless you're using HTML 5's idiotically redundant <section> tag) is THE heading (singular) that everything on every page of a website is a subsection of. That's why the site title / company name is the best candidate for it. JUST like how even though it's bigger on the cover or front page, the title of a book or newspaper appears at the top of every sub-page or fold-pair.

    An H2 indicates the start of a major subsection of the current page, the first H2 (or HR) should therefor be the start of the main content. An H3 indicates the start of a subsection of the H2 preceding it. An H4 indicates the start of a subsection of the H3 preceding it. Care to guess what H5 and H6 mean? It creates a tree-like navigable structure for non-visual users, or as an aid for things like keyboard and alternative navigation. Even HR doesn't mean "draw a line across the screen" it means "a change in section or topic where heading text is unwanted or unwarranted".

    Which is why there are site structure tools that show this relationship. It's why skipping over heading levels, pairing headings for header and tagline, and a host of other techniques you see people do with HTML are nothing more than incompetent mentally enfeebled ignorant bullshit.

    Of course if those tags let you divide the page into sections, what purpose does HTML 5's <section> serve other than to piss on the use of heading orders? If you use it you're 'reset' to H1 depth, which is why if you ever see the first heading inside a <section> tag be anything other than a H1, the developer doesn't know enough about HTML to be using it.

    JUST like how <p> is for a grammatical paragraph -- NOT single images, not a label and input pair, not for two or three loose words that aren't part of the content flow, and sure as shine-ola NOT because "I want a double-break after this". How <li> is for short bullet points (in the grammatical sense) or selections, and NOT "hurr durs eye wantz a bullut shewed befur it". If it's big enough to span multiple paragraphs or have a heading, it's probably NOT a "list item". Redundant semantics can be worse than none!

    Tables are for tabular data and have tags -- like CAPTION, TH, THEAD, TFOOT, TBODY -- and attributes -- like SCOPE and HEADINGS -- that exist to create the semantic relationship between your data (TD) and what describes them!

    If you aren't doing any of that, you aren't using HTML properly. Hence why if you see trash like this:

    <table id="test">
    	<tr>
    		<td colspan="3" class="tableTitle">Shopping Cart</td>
    	</tr><tr>
    		<td class="columnHeading"><strong>Product Name</strong></td>
    		<td class="columnHeading"><strong>Amount</strong></td>
    		<td class="columnHeading"><strong>Cost</td>
    	</tr><tr>
    		<td class="rowHeading"><strong>Widget</strong></td>
    		<td>4</td>
    		<td>20</td>
    	</tr><tr>
    		<td class="rowHeading"><strong>Doodad</strong></td>
    		<td>1</td>
    		<td>5</td>
    	</tr>
    </table>
    
    Code (markup):
    The person writing that HTML doesn't know enough about the topic to be doing so. Pointless classes, table DATA cells being used for headings, colspan being used for the CAPTION... there is NO reason other than ignorance and incompetence for that to not be written as:

    
    <table id="test">
    	<caption>Shopping Cart</caption>
    	<thead>
    		<tr>
    		<th scope="col">Product Name</th>
    		<th scope="col">Amount</th>
    		<th scope="col">Cost</td>
    	</tr><tr>
    		<th scope="row">Widget</th>
    		<td>4</td>
    		<td>20</td>
    	</tr><tr>
    		<th scope="row">Doodad</th>
    		<td>1</td>
    		<td>5</td>
    	</tr>
    </table>
    
    Code (markup):
    HTML tags exist for a REASON, they have MEANINGS that have dick-all to do with their appearance. As such if you are choosing your HTML tags based on what you want things to look like, you're choosing all the wrong tags for all the wrong reasons!

    We did get away from that during the browser wars, where Microshaft and Nutscrape kept trying to out-do each-other with presentational crap in the markup, leading to the abortive train wreck that was HTML 3.2 with it's mentally enfeebled FONT, CENTER, ALIGN, BGCOLOR and the rest of the crap that was deprecated in HTML 4 Strict. Naturally though a great number of mouth-breathers kept using 4 tranny not realizing that "transitional" literally meant "in transition from 1997 to 1998 development practices" -- the reason so many call HTML 4 Strict "the real HTML". Many of whom, myself included are none-to-thrilled with the new allegedly structural tags in HTML 5 that are nothing more than re-introducing old redundancies and creating whole new ones!

    This semantics combined with CSS allows you to maintain "separation of presentation from content" -- so that one markup can be used for many different appearances, and deliver to devices where even the TERM "appearance" doesn't even apply. The LINK tag even has a MEDIA attribute on it to say WHICH media devices your specific style and appearance instructions are for -- screen, projection, print, aural, etc. In fact, omitting a media attribute or using "all" as the value is ALSO incompetent trash. 99%+ of the time you see a <link rel="stylesheet"> that lacks a media="" on it, the person writing it AGAIN doesn't know enough HTML to be using the language in the first place.

    This separation also allows for multiple skins off a single unified markup even for the same media target. In theory under ideal circumstances it lets you completel redesign an entire site WITHOUT even having to significantly touch the markup. THAT'S THE POINT!

    Said separation helping make things easier to maintain, better leveraging caching models, etc, etc is just icing on the cake. THOUGH that too is why the use of <style> at ALL is equally stupid and style="" should be avoided in all cases except where the style helps convey MEANING. (tag clouds, bar graphs, that's about it). Seriously, the <style> tag should be stricken from HTML entirely, there is ZERO legitimate reason to even use it apart from -- again -- ignorance and incompetence.

    This is also why using classes to say what things look like is inept haflwitted trash. The appearance for any one media target may not apply to others. Your classes and ID's should ALSO be saying what things ARE, and NOT what you want them to look like. Hence classes like "w3-red" and "text-center" are 100% grade A bullshit used by people who have ZERO business writing a single blasted line of HTML. Laughably that's EXACTLY how HTML/CSS frameworks function which is why universally HTML/CSS frameworks are -- again -- ignorant incompetent half-witted mentally enfeebled mouth-breathingly idiotic BULLSHIT that pisses on usability, accessibility, functionality, good practices, and every single possible aspect of sane and rational development!

    That they then have the unmitigated gall to call their bullshit "easier" or "makes you more productive" is outright insulting, particularly when the result is often two to twenty times the HTML needed to do the job by the time you have a finished product. Tell me again how writing 60k of markup to do 10k's job is "easier".

    ALL of this can be gleaned from the HTML 2, 4 Strict, and 5 specifications, the Web Content Accessibility Guidelines, and most of the 'meaningful' tools for evaluation website code quality and accessibility -- particularly if you understand the professional writing norms on which HTML was based. Writing norms that I learned in the fourth grade in the 1970's, and that today seems to be second year of college for English majors. GO educational progress! No wonder we're churning out generations of TLDR mouth-breathing half-tweets.

    ADMITTEDLY, you're working with an application -- so a LOT of the above can be semi-ignored -- but if you're working with HTML for websites where accessibility, search, and bandwidth restrictions are job 1, ignore the RULES of using HTML at your own peril!


    ... and if you aren't hearing people talk about HTML in these terms, you're talking to the wrong people! Likely the types of halfwits and dumbasses who think bootcrap and turdpress are the bee's knees.
     
    Last edited: Apr 14, 2018
    deathshadow, Apr 14, 2018 IP
  14. SoftLink

    SoftLink Active Member

    Messages:
    103
    Likes Received:
    5
    Best Answers:
    0
    Trophy Points:
    60
    #14
    WOW! Thanks. I've never heard anybody describe html/css like this.
    "never encountered the concept of ;semantic markup'?" never.
    For me, "Separation of presentation from content" meant keep the programming separate from the display.
    It meant keep the html separate from the VB, Java, C#, php, SQL, XML (and usually Javascript).

    You've got me interested. I like the idea of keeping the html markup separate from the way it looks.
    I think you're right. That can make things a lot easier, real quick.
    I've ignored a lot of what I've read because it looked like nonsense. I see here, you quite agree.
    The problem of course is to determine what's important and what's not.
    I'll have to go back & study the HTML5 spec thoroughly (because with programming, graphic design, copywriting & marketing strategy - - not to mention lead guitar - I don't have enough to stay up on).
    Then again, I'm pretty convinced that a lot of what is in the HTML5 spec is nonsense.
    If something doesn't have a practical application then I couldn't care less about it.
    I've never had much respect for css. It's never worked very well for me. Shouldn't max-width mean the element is NEVER wider?
    What about vertical-align? I could probably stand to study css more too (again because I don't have too much to learn).
    I'll have to take into account that html is NOT design which is something I never really thought of (programming is not design).

    With all your ranting I thought - he's probably a pretty good web designer but way too steeped in rules & regulations to be very practical. After you convinced me to actually look at your code I had to rethink that.
    Your code was clean, concise and effective. I'm not used to seeing that with html & css.
    Once in a blue moon I run into somebody who really can think, really can do things well.
    I'm thinking you're one of them (much to my surprise).
    I'll have to keep an eye on you, maybe start reading your blog (cuz I don't have enough to read).
    Thanks again for your detailed explanation. You've got me thinking about html & css a bit differently.
     
    SoftLink, Apr 15, 2018 IP