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.

HTML 5 Semantic mark-up

Discussion in 'HTML & Website Design' started by Web_Dev_Chris, Jun 18, 2019.

  1. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    Which should mean making them have to output LESS of it and to stop screwing around with things that's none of the markup's difference. You get the presentation out of the HTML, there's less HTML and less for them to have to sit there trying to make sense out of.

    Which is the oppsosite of my view on it. The problem with DTD's is they tell visual browsers how to treat the element, what's valid inside / around it, but are utterly incapable of telling the browser what things ARE. Semantically, grammatically. Cannot do it. Screen readers, braille readers, etc only really learn if it's block level, phrase level,... It's like learning the grammar of a language whilst pissing on the dictionary. Meso branda et walaka terem ed mo wu teh sturp.

    Being able to just randomly make up your own tags and attributes means is the OPPOSITE of semantic markup, completely misses the point, and why we use HTML and not just plain SGML. That was my problem with XML in general is the lack of clear definintions and roles since you can just randomly make shit up that the UA will have NO clue about.

    See your example:

        [<!ELEMENT booktitle ANY>
         <!ELEMENT author ANY>
         <!ELEMENT publisher ANY>]>
    Code (markup):
    Elements that can go ANYWHERE. Nothing to actually say WHAT they are to the UA so the UA can convey that MEANING. At which point congratulation, you've made a document full of SPAN. How useful. NOT!

    It's the problem I have every time some XML fanboy claims it's a "machine readable format". As an old school assembly guy I hear that and think "are the integers stored in binary? The strings stored as RLL or null terminated? Are the instructions of what's what binary? No? you have to write a full lexical analyzer just to process it? THEN IT'S NOT MACHINE READABLE JACKASS. It's HUMAN readable!" -- part of why XML and SGML are so grossly inefficient from a bandwidth and computing power standpoint.

    So great, you defined that they ARE elements and where they can / cannot go, but how the F*** does that help a browser or other user-agent convey the MEANING to USERS? It doens't!

    My own list of things I'd like to see in a HTML spec that are currently lacking.
    1) Authoritative. Tell web developers WHAT to do and HOW to do it. This is supposed to be a specification, not documentation.

    2) Semantics with a focus on the professional writing norms on which HTML was originally based. To that end the documentation should CLEARLY in plain language explain what the tags MEAN.

    3) Further continue HTML 4 Strict's path of removing pointless redundancies and elements/attrs that introduce accessibility failings. This includes those created by HTML 5. As such AUDIO, VIDEO, CANVAS, IMG, EMBED, ARTICLE, NAV, SECTION, HEADER, FOOTER, ASIDE, MAIN, FIGURE, FIGCAPTION, WBR, DIALOG, STYLE and TARGET would all be removed.

    4) recycle the FOR attribute to replace the LIST and AXIS attributes. There is no reason for all these differing syntax doing the same bloody thing. Could even borrow the leading underscrore for "_row" or "_col" to replace SCOPE. Fewer attributes to remember == good.

    5) default SCOPE to "col" in THEAD, and "row" in TBODY. / TFOOT

    6) remove BIG and replace SMALL with <dem> -- de-emphasis.

    7) Put versions back into the doctype and/or HTML tag. I still think it makes more sense as the old VERSION attribute on the HTML tag.

    8) add a POLYFILL attribute. If the versions stated in this attribute is greater or equal to the HTML VERSION="" then neither the element nor its contents are loaded or even added to the DOM.

    Example, if <script src="fixLegacy.js" polyfill="html 7"> and we have <html version="html 7.2"> then the script will be loaded, but if we have <html version="html 8" > then it will not. The tag and its contents should be treated as if it doesn't exist.

    The inspiration for this came from the "hidden" attribute.

    *NOTE* this is what the VERSION="" attribute on body and language="" attribute on SCRIPT were originally supposed to provide but browser makers dragged their heels on implementing. Never understood why that was thrown in the trash. Kind of stupid in hindsight.

    9) emphasize that the CSS specification NEEDS to say what the default appearance and behavior of tags/elements and behaviors should be for each media type, whilst it is NONE of the HTML specifications business.

    10) No extensibility. Yes, I know that "neuters" SVG, but really if you have a flipping image it has zero damned business in the markup except as an OBJECT. Bang the brakes on these re-re's pissing static images into their markup completely bypassing any chance of caching. Letting tags and attributes from outside the specification be slopped in willy-nilly any-old way has dick-all to do with what semantic markup means or even is for. Anyone who tells you that creating your own element with a word that's meaningful to humans but without writing a way to make the UA understand it, well... they're talking out their arse.

    11) Emphasize time and time again that putting presentation in the markup using classes, tags, or attributes is in the vast majority of cases an utter cock-up. Hence tags, classes, and ID's should not be chosen just for appearance sake. Hence the <style> tag should be removed from HTML entirely (particularly with most dev's being too stupid to even handle that it's actually invalid inside BODY), and the STYLE="" attribute will have its role -- when style helps convey meaning, such as width/height on a bar graph element or font-size on a tag-cloud -- CLEARLY defined.

    That's my view on where it SHOULD be going. Reduce the number of tags and attributes, clearly define their roles, emphasize separation of presentation from content, and provide not just versioning, but a means to leverage that version within the document.
    Last edited: Jul 2, 2019
    deathshadow, Jul 2, 2019 IP