Loading ...
Sorry, an error occurred while loading the content.

vs. , vs. (Was: Re: [NH] Re: Using CSS to space lists & paragraphs)

Expand Messages
  • Scott Fordin
    ... It is true that there is a debate about when to use logical (or structural) markup and when to use physical markup. and are physical tags, whereas
    Message 1 of 44 , Mar 5, 2007
    • 0 Attachment
      Corl DeLuna wrote:
      > When first confronted with this issue I relized that:
      > <b> = <strong> = BOLD, and <i> = <em> = ITALIC. Different tags produced the
      > same results.
      >
      > It was said that there is no practicle reason to perfer one over the other,
      > but I perfered <b> and <i> because:

      It is true that there is a debate about when to use logical (or
      structural) markup and when to use physical markup. <i> and <b>
      are physical tags, whereas <em> and <strong> are logical tags.
      In most browsers used by sighted people on a common desktop or
      notebook computer, <em> and <i> are displayed identically to
      each other, as are <strong> and <b>.

      Physical markup is designed to convey formatting instructions
      to the rendering device or program, like a browser. <b> means
      display this text as bold, regardless of where you're looking
      at it. Logical markup conveys structural information to the
      rendering device, and that device can interpret how to deal
      with the structural information. For example, on a typical
      browser, <strong> means display that text in a bold typeface.
      However, if rendering the page through a screen reader, <bold>
      could cause that text to be spoken louder. Put another way,
      physical styles say "display this text this way, no matter what
      browser you're using." Logical styles are more flexible, saying
      "display this text how you best see fit, depending on the
      device you're using to render it." This flexibility is a nice
      thing if you're expecting (or hoping) your content will be read
      on a variety of devices, or if your content will be passed
      programatically to another application or web service.

      Personally, I use <em> and <strong> most of the time because I
      like the flexibility and the accessibility features. I force
      visual formatting by using CSS markup, which still doesn't
      obviate the flexibility of the structural approach.

      > They require fewer keystrokes, thus are faster to write.

      True. But if you're using, say, a Notetab clip to enter your
      code, it doesn't much matter. Ditto if you're using a tool like
      Dreamweaver. If you're actually typing the characters, then yes,
      it's a marginal difference.

      > The tags are logical to their function, thus easier to remember.

      Habit and personal preference. It can be argued that <strong>
      and <em> are more meaningful because they don't just imply a
      visual typographic convention; they're more emotive.

      > Using fewer characters keep the HTML doc as clean as possible, making for
      > better proofing.

      Again, personal preference. If you're using syntax highlighting,
      as in Notetab, the tags are easy enough to ignore regardless of
      these length differences, IMHO. I dunno. Doesn't bother me any,
      but that's just me. Besides I do my real, final editorial proofing
      on the rendered screen, and I use a validator (CSE) to check my code.
      Moreover, I'm pretty OCD about my code formatting, and that helps to
      make it all easier for me to parse visually.

      > Using fewer characters optimizes the file size for faster loading pages to
      > the end user.

      How much bold and emphasis are you turning on and off on each
      page? Really, over the course of a typical page, the difference
      in byte count is trivial. I submit that a bunch of CSS frou-frou
      and cruft can bog things down even more. Gotta be careful with
      this stuff. Good CSS design can go a long way towards reducing
      page size. It's why I cringe when I look at the HTML typically
      generated by Word, FrontPage, or WebWorks. So much cruft, so much
      abuse of <span> and styles.

      > But, now I use them all and style them differently with CSS, giving me 4
      > tags instead of 2 for greater formating flexibility with fewer special
      > classes or ids.

      That's a pretty cool idea. I'd get confused though! I keep it
      simple: one pair of tags, mnemonic style classes if I need more
      than that. Of course, it's all personal. I just go back to the
      physical versus logical part of the argument, and get all OCD
      about maintaining tidy code.

      Cheers!

      Scott

      >
      > Corl
      >
      > ________________________________
      >
      > From: ntb-html@yahoogroups.com <mailto:ntb-html%40yahoogroups.com>
      > [mailto:ntb-html@yahoogroups.com <mailto:ntb-html%40yahoogroups.com>] On
      > Behalf
      > Of Marcelo de Castro Bastos
      > Sent: Monday, March 05, 2007 8:28 AM
      > To: ntb-html@yahoogroups.com <mailto:ntb-html%40yahoogroups.com>
      > Subject: Re: [NH] Re: Using CSS to space lists & paragraphs
      >
      > On the last exciting episode, aired on 5/3/2007 12:27, sisterscape
      > invited the wrath of the gods by saying:
      > > Font and <b> tags are deprecated for starters. Then each paragraph
      > > should be enclosed in a <p> tag of whichever class you choose. It
      > > might look something like this:
      > >
      > >
      > Actually, <b> (along with <i> and <tt>) is not yet deprecated. It is
      > still part of XHTML 1.1 (which few people use, as a matter of fact). But
      > it will no longer be present in XHTML 2.0, which is still in draft.
      > Since most people are still coding in HTML 4.01 and/or XHTML 1.0, and
      > are expected to keep doing that until truly XHTML-compliant software
      > become common, this is not really an issue at present.
      >
      > But you are right in that it's a good idea to begin weeding out those
      > elements and acquiring new coding habits; XHTML 2 breaks a lot of stuff,
      > but also has a lot of good points, and as soon as it becomes feasible to
      > do so, I'll start coding in it. If I do some forward looking now, when
      > the time comes the adjustments will be not be that hard to do.
      >
      >
    • Scott Fordin
      ... For better or worse, HTML has become more of a de facto formatting language rather than a structure-oriented markup language. The DTD is lax enough that
      Message 44 of 44 , Mar 9, 2007
      • 0 Attachment
        absalom_nemini wrote:
        > I have to admit to being appalled. From LaTeX I had expected the
        > following snippet to give visible results:
        >
        > <P>
        > And he said:<BR>
        > <CITE>There is a word here needing to be <EM>emphasized</EM>
        > regardless of context.</CITE><BR>
        > <B>A sentiment to which I <STRONG>strongly</STRONG> agree.</B>
        > </P>

        For better or worse, HTML has become more of a de facto formatting
        language rather than a structure-oriented markup language. The DTD
        is lax enough that you can get away with all sorts of illogical
        structuring schemes -- for example, the hierarchy of heading tags
        (h1, h2, h3, etc.) is not enforced. On the one hand, it's made it
        easy for millions of pages to be written by non-coding types,
        giving us all sorts of wonderful stuff that probably wouldn't
        occur to the aforementioned coding types. On the other hand, it's
        created all sorts of issues around browser compatibility, made it
        very difficult to programmatically port or integrate markup in
        other pages or web-based applications, and has engendered page
        design horror shows analogous to the multifont, carny colored
        nightmares we saw in the early days of Apple and Mac page layout
        programs... the digital equivalents of purple shag carpeting and
        cheesy faux-wood basement paneling!

        As a telling example, note that converting SGML->HTML is generally
        a straightforward process, whereas all bets are off when converting
        HTML->SGML. In some ways, we're starting to see the code hit the
        fan with the rise of XML, XHTML, PHP coding models, which are
        usually more strict (depending on your DTD), and are now learning
        how it's often really painful to suck existing HTML pages in to
        new content structures.

        This said, one reason I generally prefer structural markup to
        physical markup is that it makes it potentially easier to
        repurpose content for things I haven't even anticipated yet --
        and I'm just vain enough to hope that some of my old pages might
        find their ways into these new content models!

        Scott
        (Coding sermonette #3746.12)
      Your message has been successfully submitted and would be delivered to recipients shortly.