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.

Not using ID or class - good, bad?

Discussion in 'CSS' started by qwikad.com, Dec 23, 2013.

0
  1. #1
    css:

    red {color: #FF0000; }
    Code (markup):
    Then if I do this number: <red>Something here</red> - it shows as red.

    IE 6 doesn't support this, all other browsers do.
     
    Solved! View solution.
    qwikad.com, Dec 23, 2013 IP
  2. #2
    Other browsers support xhtml, thus anything marked as an element may be styled. IE does not. What you're illustrating is poor practice. Classes and IDs are contextual styling and scripting hooks. Not to use them is silly.

    cheers,

    gary
     
    kk5st, Dec 23, 2013 IP
    deathshadow and ryan_uk like this.
  3. qwikad.com

    qwikad.com Illustrious Member Affiliate Manager

    Messages:
    7,151
    Likes Received:
    1,656
    Best Answers:
    29
    Trophy Points:
    475
    #3
    Thanks Gary, that's why I asked. I wasn't sure if it was good practice.
     
    qwikad.com, Dec 23, 2013 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #4
    The thing is, the tags in HTML exist for a reason -- making up your own ignores the entire CONCEPT of semantic markup; but then so would an idiotic presentational tag like "red" -- to be fair though, so would an idiotic presentational class or ID like "red".

    Your HTML should say what things are, using the semantic tags (and no the new structural tags from the train wreck known as HTML 5 don't count) in the HTML specification... EVEN if using XHTML; even under XHTML that's invalid, even if the XML parsing rules allow it -- since XHTML is NOT true XML, it's HTML in a XML namespace with XML structural rules.

    Which is why <div /> should NEVER be valid; DIV isn't an empty element, EVER... even when it's <div></div>

    In that way, the browsers that do support completely made up fictional tags are WRONG... or just too lazy to add the handful of traps to say "what the **** are you doing?!?" -- of course with HTML 5's pissing on the structural rules from orbit and encouraging the sleazing out of code any old way, you'll probably see more and more people using such bad practices. Why not? Most people are still vomiting up HTML 3.2 and slapping 4 tranny on it or 5 lip-service around it -- with zero concept of semantics, proper/valid markup, separation of presentation from content, or any of the dozens of other improvements of the past decade and a half.

    Hell, that's what HTML 5 is, ignoring everything STRICT was about and the W3C shrugging it's shoulders to say "fine, crap it out any old way."
     
    deathshadow, Dec 24, 2013 IP
  5. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #5
    XHTML does allow the author to create new elements and attributes. To be correct, he must extend the DTD, even though the browser doesn't read the extension, nor does any validator that I know of. He should also create a stylesheet that sets the default presentation.

    Here is an example of a true, very simple XHTML document with its DTD extension, from 9 or 10 years ago.
    
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
   [<!ELEMENT booktitle ANY>
    <!ELEMENT author ANY>
    <!ELEMENT publisher ANY>]>

<html xml:lang="en"
          xmlns="http://www.w3.org/1999/xhtml"
          lang="en">
<head>

  <meta http-equiv="content-type"
             content="application/xhtml+xml; charset=utf-8" />

  <style rel="stylesheet"
            type="text/css">
/*<![CDATA[*/

booktitle {
   display: inline;
   font-weight: bold;
   font-style: italic;
   }

author {
   display: inline;
   }

publisher {
   display: inline;
   }

publisher:before {
   content: "(";
   }

publisher:after {
   content: ")";
   }

/*]]>*/
  </style>
</head>

<body>
  <h1>XHTML1.0 Document</h1>

  <p>A book that has been very helpful is <booktitle>Dynamic HTML</booktitle>, by <author>D. Goodman</author><publisher>O&rsquo;Reilly</publisher>.</p>

</body>
</html>
    Code (markup):
    cheers,

    gary
     
    kk5st, Dec 24, 2013 IP
  6. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #6
    Technically that's a compound document, meaning it's XHTML mixed with XML as it has two (or more) namespaces. Hence why under 7.6.4.1 you'll find this little gem:

    In other words, you can do it, but that doesn't make it right. XHTML 1.0 was never really meant to be true XML, and trying to treat it as such was one of the biggest misunderstandings and mistakes the people who believe "XML solves everything" made with it.
     
    Last edited: Dec 24, 2013
    deathshadow, Dec 24, 2013 IP
  7. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #7
    You're looking at compound documents. I was extending the xhtml DTD. See ยง6. Developing DTDs with defined and extended modules.

    I am not embedding xml in an xhtml document, rather I am defining new elements for the existing doc's DTD. It cannot be validated, obviously, but that does not imply it is invalid.
     
    kk5st, Dec 25, 2013 IP
  8. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #8
    Meaning it is a new DTD, and therein no longer XHTML.

    We don't call SMIL or MathML "XHTML", do we? We don't say HTML is SGML, or that XHTML is XML (or at least we shouldn't) because there are sufficient changes that, well... it's no longer valid in it's predecessor/parent.

    Of course that whole 'extending' it nonsense in either case was a bunch of rubbish just asking to /FAIL/ and defeating the entire point of STRICT, semantics, etc, etc. Likely why XHTML 1.1 and 2.0 were doomed to failure from the start; and why I'm a bit shocked at how people actually seem to think HTML 5 is a good idea.
     
    deathshadow, Dec 25, 2013 IP
  9. qwikad.com

    qwikad.com Illustrious Member Affiliate Manager

    Messages:
    7,151
    Likes Received:
    1,656
    Best Answers:
    29
    Trophy Points:
    475
    #9
    I have another question. Are there other tags similar to h1 h2 h3, etc.? I tried to Google it nothing came up.
     
    qwikad.com, Dec 25, 2013 IP
  10. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #10
    This is an older reference to HTML 4 -- I still consider it one of the best at explaining all the tags and what they are FOR... and since HTML 4 was released in 1998, who cares if it's an old reference?

    http://htmlhelp.com/reference/html40/

    The organizational reference in particular is very useful, and the site takes the rather complex legalese of the specification and turns it into normal English that a normal person MIGHT actually understand. (WOW!). Laugh is this USED to be the reference Netscape pointed at back in the day.

    Go here:
    http://htmlhelp.com/reference/html40/olist.html

    Click on "Hide non-strict elements", and you have the just the tags anyone writing websites the past fifteen years should have been using. If it's not on that list, you are probably doing something wrong!

    Though I'm not sure what you are asking about numbered headings.... there are six of them, H1...H6. By definition they mean "start of a subsection of the higher order/lower numbered heading before it". So a H1 is the topmost heading, EVERYTHING on the page is a subsection of the H1. H2's are subsections of the H1, H3's are subsections of the H2's, and so forth down the line. If you need to nest more than 6 sections deep, you are doing it all wrong. That is what is meant in the specification by "priority" -- something you learn in professional writing classes! It's also why people who mistake "priority" or "importance" meaning how important it is on the page instead of it's import on the structure are doing it all wrong! JUST as wrong as the people who use them just for the default presentation of them being bigger text.

    Since if you are choosing your tags based on their default appearance instead of their meaning, you're doing it all wrong.

    It's also why skipping over heading numbers (H2 with no H1 before it, H5 with no H4 before it) is inaccessible gibberish. Also since numbered headings mean the start of subsections, and a HR (horizontal rule) means a change of topic/section where a numbered heading is unwanted/unwarranted, it makes HTML 5's "SECTION" tag nothing more than pointless bloat and redundant semantics... and since you're SUPPOSED to be able to navigate headings in browsers (something everyone except Opera dragged their heels on implementing) it also makes NAV (which is supposed to mean "you can skip this area to get to the content") pointless, since you should just be skipping from the H1 (typically site title) to the first H2 (content title)... Which is why I call HTML 5's new structural rules pointless idiotic BS; going hand in hand with all the rest of it's pointless idiotic BS like loosening the structural rules so people can sleaze out code any old way, who cares if it makes any sense.

    Basically, every page should have one and only one H1, under which everything on the page is a subsection... it's like the title of a newspaper -- it might be presented bigger on the front page, but what's at the top of EVERY page of the paper? It being bigger on the front page is presentation, NOT structure. Under it you have H2's... the first H2 should probably be in your content, which is why content-first markup (and content-first CSS columns) are important to know how to do. You can have multiple H2 for multiple equal subsections... again to use the newspaper simile, the article headlines. While one headline might be bigger than the others, that's presentation, not structure -- it would still be a h2. Presentation is NOT structure, as you wouldn't be saying that "Woman raped on Emerald Street", "K-6 gets new school" or "Classified Index" are subsections of "MAYOR CAUGHT TAKING MILLION DOLLAR BRIBE" -- or at least you'd hope not as that would be one screwed up town. A great example of H3's would be the actual classified pages, where you'd have H1 as the paper title, H2 as "Classifieds" and the H3's being "Lost & Found", "Real Estate", "Properties for Rent" and so forth. You would then have horizontal rules between each of the articles in classfieds as they wouldn't have headings, but are separate items.

    Which is why HR (horizontal rule) does NOT mean "draw a line across the screen" -- no matter if that's it's default appearance. Just like how B and I do not mean "must be shown as bold or italic" and instead mean "Would be bold or italic in professional writing, convey that meaning as best as possible." Which is why neither is deprecated nor are they redundant to STRONG and EM, since those have a different meaning!

    Headings and rules exists to separate the page into sections and subsections. That's their job. ... and just another reason HTML 5 is ignorant pointless bloat.
     
    Last edited: Dec 25, 2013
    deathshadow, Dec 25, 2013 IP
  11. qwikad.com

    qwikad.com Illustrious Member Affiliate Manager

    Messages:
    7,151
    Likes Received:
    1,656
    Best Answers:
    29
    Trophy Points:
    475
    #11
    Thank you @deathshadow very informative.

    I have one more question. Do you think tags like b, i, u, big, strong will every be deprecated to the point no browser will read them anymore?
     
    qwikad.com, Dec 26, 2013 IP
  12. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #12
    No, it is not a new DTD; it is an extension of the xhtml DTD as in eXtensible HyperText Markup Language.

    Had MSFT not killed it by its non-support, xhtml could have done the job of those silly microformats and of your beloved html5. Would it have been abused? Of course, but at least it would have been well formed or suffer catastrophic failure.
     
    kk5st, Dec 26, 2013 IP
  13. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #13
    Well for starters, of those tags you just listed only ONE, 'u' is currently deprecated in any existing doctype; so browsers not supporting them is extremely unlikely... but really we need to clarify the terminology.

    "Deprecated" doesn't actually mean it's not supported -- quite the opposite. Deprecated simply means you are advised not to use it, NOT that it won't work. The specification has an entirely different word for that, "obsolete"... and even then it's unlikely that even the obsolete tags would stop working since in the twenty odd years since HTML 2 not one browser has dropped HTML 2 support.

    Generally speaking the use of the word deprecated seems to be a bit of legalese style misuse of an obscure word most people don't know; especially since in normal speech the only time you are likely to come across it is when referring to talking down to someone else in a condescending manner. (see how most adults talk to pre-teens, switching to that idiotic baby voice that makes even children just want to smack you). -- the more common word "depreciated" would actually have made more sense, since they are no longer "of value" and generally should not be used.

    In that way I disagree with the W3C validator on how it reports deprecated tags -- if they are going to use the word deprecated in the manner of saying "still supported but don't use them" they should probably throw warnings, not errors! Errors should be reserved for obsolete and mal-formed markup.

    Now that said, some people who should know better seem to have gotten it into their heads that some tags, like B and I should be deprecated and/or already are... and that's just 100% fiction and nonsense. Neither has EVER been deprecated nor are they ever likely to be. They mean "would be bold or italic in professional writing", not that they 'must' be shown that way or use that presentation. Usage scenarios would include proper names (when not being cited) or book/product titles. They are NOT redundant to EM and STRONG no matter what the ignorant halfwits will tell you, since those mean something entirely different; emphasis and 'more emphasis'.

    An example a friend of mine on another forums came up with shows clearly how/where/why each should be used.

    <i>GURPS</i>, <b>Steve Jackson Games'</b> flagship roleplaying game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows</i>. However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS,</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>

    Which I explained just about a year ago here:
    https://forums.digitalpoint.com/threads/bold-or-strong-tag-which-is-better.2622501/#post-18378109

    It really shows how/why each of those tags should be used and why they all exist -- and aren't going anywhere.

    Somethign that might help you and a lot of others is if we took the time to review what tags are deprecated or obsolete, in what document types, as well as WHY we have been told to stop using them.

    Deprecated tags in HTML 4 STRICT
    -----------------------
    APPLET -- redundant to object

    BASEFONT -- presentation / redundant to CSS

    CENTER -- presentation / redundant to CSS

    DIR -- redundant to UL

    IFRAME -- redundant to OBJECT

    ISINDEX -- redundant to INPUT

    FONT -- presentation / redundant to CSS

    MENU -- redundant to UL

    STRIKE and S -- redundant to DEL

    U -- removed because it's confusing to underline things that aren't anchors on a website, and for being redundant semantically to EM as the only reason in professional writing to underline something is to emphasize it.

    Deprecated attributes in HTML 4 STRICT

    Skipping attributes who's parent element is deprecated, like ALT on APPLET or FACE on FONT.

    ALIGN on all tags except COL, COLGROUP, TBODY, TD, TFOOT, TH, THEAD and TR -- redundant to CSS. On table elements they are still permitted to aid with graceful degradation when CSS is off and/or unavailable.

    ALINK, LINK, VLINK -- redundant to CSS

    ALT on INPUT -- redundant to LABEL tag

    BACKGROUND -- redundant to CSS

    BGCOLOR -- redundant to CSS

    BORDER -- redundant to CSS

    CLEAR -- redundant to CSS

    COLOR -- redundant to CSS

    COMPACT -- redundant to CSS

    HEIGHT on TD, TH -- redundant to CSS, rule generally ignored anyways.

    HSPACE -- redundant to CSS

    LANGUAGE on SCRIPT -- redundant to TYPE attribute

    NOSHADE -- redundant to CSS

    NOWRAP -- redundant to CSS

    SIZE on HR -- redundant to CSS

    START on OL -- I never actually understood why this was deprecated as it makes no sense to do so and has NO suitable replacement!

    TEXT on BODY -- redundant to CSS

    TYPE on LI, OL and UL -- redundant to CSS

    VALUE on LI -- redundant to CONTENT of the tag.

    VALUETYPE -- never seemed to serve a legitimate use, probably redundant to TYPE attribute.

    VERSION -- redundant to doctype

    VSPACE -- redundant to CSS

    WIDTH on HR, TD, TH and PRE -- redundant to CSS.

    Obsolete tags in HTML 4 STRICT
    -----------------------
    LISTING -- redundant to PRE

    PLAINTEXT -- redundant to PRE

    XMP -- redundant to PRE

    HTML 4 Summary
    ------------------------
    You'll notice one word mentioned a LOT in the above -- redundant. that's mostly what HTML 4 was about, removing redundancies for clearer more consistent code. Redundancies to CSS were removed to promote separation of presentation from content, while redundancies between existing tags (like MENU, DIR and UL) were removed so you weren't constantly questioning "Well which one do I use?"

    It should be noted that certain tags like APPLET and IFRAME were dropped for OBJECT - and if Microsoft hadn't dragged their heels on removing the damned border from around those elements (or at the very least let you turn if off from CSS) nobody would be using either of those. Likewise EMBED was not adopted into the specification for being redundant to it, and at the time we were told that IMG should also go the way of the DODO in the next iteration... the entire idea was a good one as OBJECT was supposed to mix built-in browser support for known formats with being able to use plug-ins for new formats -- meaning there was no vendor lock-in to any one proprietary data formats for audio, video, or images; basically anything that wasn't text. OBJECTS were ALSO supposed to be sandboxed, something that took over a decade to actually materialize when Google added it to Chrome.

    So let's look at HTML 5

    Deprecated tags in HTML 5
    ----------------------------
    ACRONYM -- allegedly 'redundant' to ABBR, which is bullshit since they mean two entirely different things. Mostly this is deprecated because most people are leaving high school with a fifth grade reading level and are too stupid to know the difference.

    BIG -- rendundnant to CSS. It's worth noting that SMALL is not deprecated, because it is often used to imply de-emphasis, a semantic meaning. BIG has no real semantic use. One of the few things in 5 I can agree with.

    Obsolete tags in HTML 5
    ----------------------------
    APPLET -- upgraded from it's deprecated status. The laugh is they call it redundant to EMBED instead of OBJECT, proving someone failed to grasp the point of OBJECT.

    MARQUEE -- shouldn't even be listed as obsolete since it was never part of the official HTML specification.

    FRAMESET, FRAME, etc -- anything frame related other than IFRAME is 'obsolete' and has zero support in HTML 5. This is laughably bad since they put IFRAME back in as supported removing it's deprecated status. Progress, yeah... right.

    HTML 5 conclusions
    --------------------------
    They really didn't deprecate anything meaningful in HTML 5, as noted mentioining elements that were never officially part of HTML in the first place, removing an element that still serves a semantic purpose... but that's inline with what HTML 5 is -- since it seems the entire purpose of HTML 5 is to undo everything HTML 4 STRICT was about by reintroducing redundancies and adding extra elements for no good reason.

    HTML 5 simply isn't about leaner smaller code and less tags -- it's about more tags, more code, more wrappers, redundant/pointless allegedly semantic tags, and more importantly vendor lock-in.

    See AUDIO and VIDEO as examples of this idiocy in action - redundant to OBJECT so undoing the point of 4 STRICT, vendor lock-in via only being able to use formats built into the browser. There is NO reason these couldn't have been put on OBJECT -- the only real reason one could think of is as said, vendor lock in by telling us what formats we can and cannot use, and making it so people without the resources or in-roads to the browser code cannot add their own data formats.

    Something that comes entirely thanks to the flosstards ranting and raving about Vorbis, and Apple pissing and moaning about how their users are too stupid to be allowed to make decisions for themselves -- the latter of which I suspect is more sour grapes over their having lost the last round of media format wars of WMP vs. RealPlayer vs. Quicktime -- the laugh being none of them won that war THANNKS to the OBJECT tag allowing a third party to enter the contest.

    Which of course is the point of VIDEO and AUDIO -- to prevent third parties from even TRYING to compete; laughably sold to the public as being 'for their own good' and to 'prevent all the evils of flash and/or silverlight'. In other words, you can't actually compete with them, so lock them out of the fight entirely. BRILLIANT!

    Though I love how both QT and OGG, the two players who restarted this pissing contest have once again lost the war to VP8, MP4, etc.

    An even bigger pissing on STRICT and returning to the worst of the 1990's is that EMBED is now in HTML 5; serious what the hell since you don't need EMBED anymore.

    Most try to explain this as HTML 5 is 'documentative' -- instead ot telling us what we SHOULD do it exists to document what is currently possible... at which point why even HAVE deprecated or obsolete elements?!? I'm sorry, I have an engineering background and the entire point of a specification is to tell you WHAT to do, not what CAN be done.

    Making HTML 5 the same thing as asking "Can I go to the bathroom?" -- I dunno, can you?

    The pointless redundancies abound even further, making HTML 5 little more than halfwit bloat and unnecessary garbage so far as actually writing markup -- NAV and SECTION for example are both redundant (as I've already said a few times) to numbered headings and horizontal rules. ASIDE is semantically gibberish and is at best just as presentational as CENTER, at worst about as useful as trying to use the ADDRESS tag properly.

    Though at least they FINALLY admitted HGROUP was idiotic bull that made no sense -- just as the halfwit dumbasses who use a h2 for a tagline after a h1 apparently seem to grasp what the word 'heading' means -- and since we have headings, what do we need headers for? Much less the pissing all over logical document structure by saying that every SECTION and ARTICLE resets the heading depth -- which seems to be done JUST because most people are too stupid to use numbered headings properly so instead, just make ALL of them H1... yeah, that's useful -- NOT!
     
    Last edited: Dec 27, 2013
    deathshadow, Dec 27, 2013 IP