vs. , vs. (Was: Re: [NH] Re: Using CSS to space lists & paragraphs)
- Corl DeLuna wrote:
> When first confronted with this issue I relized that:It is true that there is a debate about when to use logical (or
> <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:
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 forAgain, personal preference. If you're using syntax highlighting,
> better proofing.
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 toHow much bold and emphasis are you turning on and off on each
> the end user.
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 4That's a pretty cool idea. I'd get confused though! I keep it
> tags instead of 2 for greater formating flexibility with fewer special
> classes or ids.
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.
> From: email@example.com <mailto:ntb-html%40yahoogroups.com>
> [mailto:firstname.lastname@example.org <mailto:ntb-html%40yahoogroups.com>] On
> Of Marcelo de Castro Bastos
> Sent: Monday, March 05, 2007 8:28 AM
> To: email@example.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.
- absalom_nemini wrote:
> I have to admit to being appalled. From LaTeX I had expected theFor better or worse, HTML has become more of a de facto formatting
> following snippet to give visible results:
> 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>
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!
(Coding sermonette #3746.12)