This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Dreamweaver > February 2006 > <h> & <p>
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| how many tags are there of each? <h> and <p>
and can you go beyond that amount?...or will certian browsers not reconize it?
is a good solution for this to use span classes?
| |
| Chris In Madison 2006-02-12, 6:34 pm |
| <h1> - <h6>, and one <p> tag. Anything beyond that is not standard markup
and should be ignored.
Best regards,
Chris
| |
| Michael Fesser 2006-02-12, 6:34 pm |
| ..oO(wadup)
>how many tags are there of each? <h> and <p>
'h1'...'h6' and a single 'p'.
>and can you go beyond that amount?
No.
>...or will certian browsers not reconize it?
No browser will recognize it, because it's no HTML anymore. Unknown
elements are ignored, i.e. the browser will render them as plain text.
>is a good solution for this to use span classes?
For what?
Micha
| |
| Murray *TMM* 2006-02-12, 6:34 pm |
| Span classes?
--
Murray --- ICQ 71997575
Team Macromedia Volunteer for Dreamweaver
(If you *MUST* email me, don't LAUGH when you do so!)
==================
http://www.dreamweavermx-templates.com - Template Triage!
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
http://www.macromedia.com/support/search/ - Macromedia (MM) Technotes
==================
"wadup" <webforumsuser@macromedia.com> wrote in message
news:dsdnp4$abo$1@forums.macromedia.com...
> how many tags are there of each? <h> and <p>
>
> and can you go beyond that amount?...or will certian browsers not reconize
> it?
>
> is a good solution for this to use span classes?
| |
|
| unsure what you're asking here. Can you clarify?
> how many tags are there of each? <h> and <p>
You might want to check the W3c for that.
http://www.w3.org/MarkUp/
<p> is a paragraph tag. <h> is not a tag I recognize. Perhaps <h1> you were
meaning as in header? There are (AFAIR) lik 8 <h1-8>. But I'm not sure on
that, and I've never seen them all used. It seems a poor site design if you
need to use more.
> and can you go beyond that amount?...or will certian browsers not reconize
> it?
If you're asking if you can define more specifics about a paragraph or
heading, then aswer is yes. Simply define them using your DW CSS (text ->
CSS->edit/new), and then assign them either by typing or by appliing the css
(select object to apply, then text->css->what you want to apply. You must,
of course, create new style tags before applying them.
it might look something like this:
CSS file contains this
..big {font-size: 18px;}
HTML file contains your paragraph tag and the css class applied to it.
<p class="big">This is the big text</p>
<h1 class="big">This is the big header</h1>
<h2 class="big"> This header will be just as big</h2>
Now, if you're asking if you must have your <h1> tag first, then an <h2> tag
next, you don't. <h1> is simply telliing the browser this is the biggest
variant of the headers. <h2> will be smaller, <h3> smaller yet. Paragraph
tags <p> simply define where a paragraph sits, and you can use as many of
them on a page as you have paragraphs.
> is a good solution for this to use span classes?
not generally. I'm not sure why span was invented, but I've never found a
decent use for it. Other may disagree.
HTH,
Jon
| |
| darrel 2006-02-12, 6:34 pm |
| > Now, if you're asking if you must have your <h1> tag first, then an <h2>
> tag next, you don't. <h1> is simply telliing the browser this is the
> biggest variant of the headers. <h2> will be smaller, <h3> smaller yet.
The header tags don't tell the browser anything about size. They tell the
browser what level of header it is. Maybe that's what you were saying, but
just wanted to clarify.
Granted, by DEFAULT, most browsers make h1 bigger than h2, etc, but their
main purpose is semantic in nature.
While there is nothing invalid about starting your page with an h2 and then
usinng an h1 afterwords, it may very well be semantically incorrect.
> not generally. I'm not sure why span was invented, but I've never found a
> decent use for it. Other may disagree.
To 'span' other markup without adding any semantic tags to the page. span is
inline, so is used more often to span chunks of text rather than overall
parts of the page.
-Darrel
| |
|
| > The header tags don't tell the browser anything about size. They tell the
> browser what level of header it is. Maybe that's what you were saying, but
> just wanted to clarify.
> Granted, by DEFAULT, most browsers make h1 bigger than h2, etc, but their
> main purpose is semantic in nature.
>
> While there is nothing invalid about starting your page with an h2 and
> then usinng an h1 afterwords, it may very well be semantically incorrect.
Your additional clarification is welcome.
>
> To 'span' other markup without adding any semantic tags to the page. span
> is inline, so is used more often to span chunks of text rather than
> overall parts of the page.
:) I know what they are meant for - I've just never seen them used in any
way that regular text formatting couldn't handle, and I've seen them mess up
many perfectly good pages. This might have been due to my testing of them
(I've not played with span tags for probably 4 years or so) and their poor
support in browsers, but I still stand by the fact that if you are using a
span tag, you are probably using poor design choices. Span, in my opinion,
is equivalent to the font tag ans should be shot on site. Again, just my 2
cents, but I like to give a donation.
j
| |
| Michael Fesser 2006-02-12, 6:34 pm |
| ..oO(crash)
><p> is a paragraph tag. <h> is not a tag I recognize.
Wait for XHTML2, then you will ... ;)
>Perhaps <h1> you were
>meaning as in header? There are (AFAIR) lik 8 <h1-8>.
6
>Now, if you're asking if you must have your <h1> tag first, then an <h2> tag
>next, you don't.
But you should.
> <h1> is simply telliing the browser this is the biggest
>variant of the headers.
No.
><h2> will be smaller, <h3> smaller yet.
Ever seen it in a text browser? It has _nothing_ to do with the size,
it's simply the logical structure. 'h1' is the topmost heading, 'h2' is
one level below it and so on.
>
>not generally. I'm not sure why span was invented, but I've never found a
>decent use for it. Other may disagree.
There are _many_ situations where you want to markup something, but you
simply can't find an appropriate element in HTML. For example a date.
How would you do that? There's nothing like <date> in HTML.
That's where 'span' and 'div' elements come into play - they are generic
inline- and block-level elements, which can be used for nearly anything.
A date for example could be declared like this:
<span class="date">2006-02-08</span>
Micha
| |
| Michael Fesser 2006-02-12, 6:34 pm |
| ..oO(crash)
>[...] but I still stand by the fact that if you are using a
>span tag, you are probably using poor design choices.
In addition to my other post here a real example - a list with some news
about a website. I use a definition list, where 'dt' contains the news
date and title, and 'dd' the text. I want to style the dates slightly
different than the title - what would you do? There simply is no better
element in HTML than a semantically neutral 'span':
<dl>
<dt><span>date 1</span> title 1</dt>
<dd>text 1</dd>
<dt><span>date 2</span> title 2</dt>
<dd>text 2</dd>
...
</dl>
No other inline-level element would fit better in this case.
>Span, in my opinion,
>is equivalent to the font tag ans should be shot on site.
Then you would have to kill 'div' elements as well. Good luck with
building nice looking websites then.
Micha
| |
|
| what will be the proper use of classes
for example:
.big
<p class="big">Text would be here.</p>
or
<p><span class="big"Text would be here.</span></p>
or
<span class="big">Text goes here</span>
| |
| Lionstone 2006-02-12, 6:34 pm |
|
>
> Then you would have to kill 'div' elements as well. Good luck with
> building nice looking websites then.
>
> Micha
Al Sparber managed it. He had an April Fools post about <div> being removed
from the W3C guidelines, complete with a nice looking web page that used
nothing but <p> tags. :)
I wish I had the link right now. Assuming it would even be up any more.
| |
|
| >>[...] but I still stand by the fact that if you are using a
>
> In addition to my other post here a real example - a list with some news
> about a website. I use a definition list, where 'dt' contains the news
> date and title, and 'dd' the text. I want to style the dates slightly
> different than the title - what would you do? There simply is no better
> element in HTML than a semantically neutral 'span':
>
> <dl>
> <dt><span>date 1</span> title 1</dt>
> <dd>text 1</dd>
> <dt><span>date 2</span> title 2</dt>
> <dd>text 2</dd>
> ...
> </dl>
>
> No other inline-level element would fit better in this case.
You're not going to get any arguements from me. I said *I* dont' have any
use for them. You'll see that I said I was sure to be contradicted. A note
of curiosity - could you not style your <dt> tag using css? I don't
generally use definition lists, but it seems I remember styling unordered
lists with success.
>
> Then you would have to kill 'div' elements as well. Good luck with
> building nice looking websites then.
I don't see how. <div> and <span> are two completely different tags,
carrying two completely different sets of characteristics. I *could* argue
that a <div> less site doesn't equate to an ugly site, but I couldn't build
a site without my <div>'s. (i sure maintain a boatload of them, though).
Generally speaking, I'm not for *any* inline tags. Just my preference. If
you're going to be using inline elements heavily, you would be far better
suited to build your page in XML and style it from there.
| |
| darrel 2006-02-12, 6:34 pm |
| >Span, in my opinion, is equivalent to the font tag ans should be shot on
>site. Again, just my 2 cents, but I like to give a donation.
I think you're right. Span should be a 'tag of last resort' if there are
more semantic options out there.
-Darrel
| |
| Donna Casey 2006-02-12, 6:34 pm |
| wadup wrote:
> what will be the proper use of classes
>
> for example:
>
> .big
>
> <p class="big">Text would be here.</p>
>
> or
>
> <p><span class="big"Text would be here.</span></p>
>
> or
>
> <span class="big">Text goes here</span>
>
The proper use of classes is not related to the element or tag to which
it applies. Classes are less specific than IDs and may be used more than
once in any given page. IDs are to be used only once and are more
specific and therefore more important.
But to answer your question about the use of <span></span>, use that set
of tags to define a separate inline box in your content. You can apply a
class to a span to control the properties applied to content within it
(<span class="big"> ), or you can define those properties in a contextual
manner so that you don't have to "apply" anything, as in:
p span {color:#f00;}
or even a combination of those, but the point here is that you wouldn't
use span in the situation you gave above, because there is no inline
content to set off from the rest of the content in the paragraph.
Get it? a perfectly proper use of span might be:
<ul>
<li><span>Emphasized Lead In Text</span> - blah, blah, blah</li>
<li><span>Another Emphasis</span> - blah, blah, blah</li>
<li><span>This One, Too</span> - blah, blah, blah</li>
</ul>
which allows you to define the appearance of li span to define color,
size, weight, etc as desired.
HTH
:D
| |
|
| > Michaels point was that he had hit that 'point of last resort' where he
> had run out of semantic tags.
I missed that.
>
> DT, itself, contained two 'chunks' of information: Date, Title.
>
> Since there are no <date> or <title> tags, that's where <span> has to come
> in.
Thanks d, I missed that, too. :)
>
> XML will likely get rid of SPAN completely if/when browsers support XML
> natively with CSS.
I agree.
>
> Actually, they are almost identical. Both are semanticless tags used to
> wrap a section of markup. The only difference is that, by default, div is
> block-level while span is inline.
The inline and block-level are what makes them so different for me. I don't
dig inline tags.
| |
|
| > So, when creating class names, ask yourself why KIND of content it is
> rather than what STYLE you want to make it.
>
> -Darrel
that's a GREAT bit of advice.
| |
|
| 8^) thanks.
"Donna Casey" <infoREMOVETHIS@n2dreamweaver.com> wrote in message
news:dsds9c$fvh$1@forums.macromedia.com...
> crash wrote:
> Perhaps <h1> you were
>
> 6 of them.
| |
| Donna Casey 2006-02-12, 6:34 pm |
| darrel wrote:
> FYI, 'big' isn't a good way to name a class. The actual style shouldn't be
> the name. Rather, the class name should refer to the TYPE of content. The
> CSS then takes care of the STYLE.
>
> So, when creating class names, ask yourself why KIND of content it is rather
> than what STYLE you want to make it.
yes, this is a great point. Many people see a descriptive name as
appearance, rather than function... and forget that today's .big might
need to be tomorrow's .tiny
Better than you describe the function and let the appearance be separate
of the name used.
| |
| darrel 2006-02-12, 6:34 pm |
|
> You're not going to get any arguements from me. I said *I* dont' have any
> use for them. You'll see that I said I was sure to be contradicted. A
> note of curiosity - could you not style your <dt> tag using css?
Michaels point was that he had hit that 'point of last resort' where he had
run out of semantic tags.
DT, itself, contained two 'chunks' of information: Date, Title.
Since there are no <date> or <title> tags, that's where <span> has to come
in.
XML will likely get rid of SPAN completely if/when browsers support XML
natively with CSS.
> I don't see how. <div> and <span> are two completely different tags,
> carrying two completely different sets of characteristics.
Actually, they are almost identical. Both are semanticless tags used to wrap
a section of markup. The only difference is that, by default, div is
block-level while span is inline.
-Darrel
| |
|
| >>Now, if you're asking if you must have your <h1> tag first, then an <h2>
>
> But you should.
I should have clarified on this. What I mean to say,is that <h> tags are
not "numbered in order". In other words, you can use an <h1> tag after you
use another <h1> tag - you're not "using them up". I think darell called me
on this one as well.
>
> No.
>
>
> Ever seen it in a text browser? It has _nothing_ to do with the size,
> it's simply the logical structure. 'h1' is the topmost heading, 'h2' is
> one level below it and so on.
OK. Font size has nothing to do with headers. I never said it had anythign
to do with TEXT size, though I certainly implied it. Biggest variant =
Biggest container -> Top tree -> First to be search -> Higher
classification. This is generally denoted as a larger font size IN
GRAPHICAL BROWSERS, but doesn't have to be any particular font size. I
explain this a bit further, but I think at this point in time (ie, learing
formating in HTML) the "viewable and/or performance traits" of a tag
illustrate better what is happening on the page. A graphical increase in
size tells us this header is more important than the one below it. It's
bigger - > Font size is bigger, Topic is bigger, Category is bigger, News is
bigger -> Whatever you are definiing by an <h1> tag, it's more important
than what you're defininig in an <h2> tag. The larger font graphically
shows you this is happening. (but not in text browsers, hehehe)
<No offense meant to original poster>
I think we're (and by that i mean you guys) are really splitting hairs on
this. I very seriously doubt if somebody is asking how many paragraph tags
they can have if they have an in-depth knowledge of document structures on
the web. For all intensive purposes, <h> tags, in an HTML page, meant for
viewing on a PC over the internet, are going to change the size of your font
and not do much else. *GRANTED* it's not what defines them, but rather how
they perform in a simple, HTML page. I don't see how arguing over a
document's semantic structure is going to help somebody who is attempting to
learn HTML (i can see the argument that I'm teaching poor practices). One
thing I have found that enables the mind to understand tags and how they
work is showing visual examples of their performace. Now, while somebody
learning XHTML or XML might want to pay attention to document structures and
classifications, I'm going to be that this user is just wanting to put up a
simple page and have it look OK. They can learn about the more complex
stuff after they've gotten a hang of how formatting works. Just my opinion.
And, if I'm wrong I applogize. 8^)
> inline- and block-level elements, which can be used for nearly anything.
> A date for example could be declared like this:
>
> <span class="date">2006-02-08</span>
comment myself out on the other one.
| |
| darrel 2006-02-12, 6:34 pm |
| > <p class="big">Text would be here.</p>
>
> or
>
> <p><span class="big"Text would be here.</span></p>
>
> or
>
> <span class="big">Text goes here</span>
>
Is 'Text would be here' a paragraph? If so, then use a paragraph tag.
All of the above work, they just differ semantically.
FYI, 'big' isn't a good way to name a class. The actual style shouldn't be
the name. Rather, the class name should refer to the TYPE of content. The
CSS then takes care of the STYLE.
So, when creating class names, ask yourself why KIND of content it is rather
than what STYLE you want to make it.
-Darrel
| |
|
| > Wait for XHTML2, then you will ... ;)
any more info on this? what's it going to do, are they just getting rid of
1-6?
| |
| Donna Casey 2006-02-12, 6:34 pm |
| crash wrote:
Perhaps <h1> you were
> meaning as in header? There are (AFAIR) lik 8 <h1-8>. But I'm not sure on
> that, and I've never seen them all used.
6 of them.
| |
| darrel 2006-02-12, 6:34 pm |
| > I don't see how arguing over a document's semantic structure is going to
> help somebody who is attempting to learn HTML
Semantics are a rather important concept to understand if one is learning
how to properly use markup languages.
A common mistake is to treat HTML as merely a styling tool, which, of
course, is what we have CSS for instead.
I do understand that sometimes people just want the super-simple answer and
then we debate things to a finer point that many probably just ignore. ;o)
-Darrel
| |
|
| > Semantics are a rather important concept to understand if one is learning
> how to properly use markup languages.
Perhaps in a course, but I don't see the value in a forum. I think it's too
detailed for the student.
> A common mistake is to treat HTML as merely a styling tool, which, of
> course, is what we have CSS for instead.
Agreed
>
> I do understand that sometimes people just want the super-simple answer
> and then we debate things to a finer point that many probably just ignore.
> ;o)
I guess that's what makes it fun, though, eh? :O)
| |
| darrel 2006-02-12, 6:34 pm |
|
> Get it? a perfectly proper use of span might be:
>
> <ul>
> <li><span>Emphasized Lead In Text</span> - blah, blah, blah</li>
Of course, this might make more sense in that particular example:
<ul>
<li><em>Emphasized Lead In Text</em> - blah, blah, blah</li>
;o)
-Darrel
| |
| Donna Casey 2006-02-12, 6:34 pm |
| darrel wrote:
>
>
> Of course, this might make more sense in that particular example:
>
> <ul>
> <li><em>Emphasized Lead In Text</em> - blah, blah, blah</li>
>
> ;o)
>
> -Darrel
>
>
specifically, if you wanted to emphasize, yes, though setting a color or
weight or size doesn't have to be emphasis necessarily. <em> is
phrasing, whereas span wouldn't imply anything specific.
But span might also be used to enclose the entire content of the item -
to force the text of each item to have one color but the bullet to be
another.
Lots of reasons to use span...
:D
| |
|
| <No offense meant to original poster>
I think we're (and by that i mean you guys) are really splitting hairs on
this. I very seriously doubt if somebody is asking how many paragraph tags
they can have if they have an in-depth knowledge of document structures on
the web. For all intensive purposes, <h> tags, in an HTML page, meant for
viewing on a PC over the internet, are going to change the size of your font
and not do much else. *GRANTED* it's not what defines them, but rather how
they perform in a simple, HTML page. I don't see how arguing over a
document's semantic structure is going to help somebody who is attempting to
learn HTML (i can see the argument that I'm teaching poor practices). One
thing I have found that enables the mind to understand tags and how they
work is showing visual examples of their performace. Now, while somebody
learning XHTML or XML might want to pay attention to document structures and
classifications, I'm going to be that this user is just wanting to put up a
simple page and have it look OK. They can learn about the more complex
stuff after they've gotten a hang of how formatting works. Just my opinion.
And, if I'm wrong I applogize. 8^)
you are wrong....no worries though.....i just forgot how many <h> they
had.....i normally use <span> to style differant headlines....but i am getting
back into the habbit of using more <h> elements...and i could remember how many
existed...
Donna good looking....that makes sense.....that is what i have been using
spans for.....i just used a bad example.....thanks for the clearification
though.....
| |
|
| i mostly use spans for emphasis on the current link.........
so if you are in the about page the about link is emphasised vs the other
links........good reasont o use it?
something like this.....
<ul>
<li><a href="index.html"><span
class="currentheader_mainlinks">Home</span></a></li>
<li><a href="about.html">About</a></li>
<li><a href="products.html">Products</a></li>
<li><a href="news.html">News</a></li>
<li><a href="contact.html">Contact</a></li>
</ul>
| |
| Gary White 2006-02-12, 6:35 pm |
| On Wed, 8 Feb 2006 16:39:56 -0600, "darrel" <notreal@nowhere.com> wrote:
>Since there are no <date> or <title> tags
http://www.w3.org/TR/html4/struct/global.html#h-7.4.2
Sorry, I just couldn't pass it up. I *do* know what you meant though.
;-)
Gary
| |
| Michael Fesser 2006-02-12, 6:36 pm |
| ..oO(crash)
>
>You're not going to get any arguements from me. I said *I* dont' have any
>use for them.
That's OK, I just really didn't like your comment
| Span, in my opinion, is equivalent to the font tag [...]
>You'll see that I said I was sure to be contradicted. A note
>of curiosity - could you not style your <dt> tag using css?
Yes, and I do. But the 'dt' contains both a date and a title. I want the
date to appear differently, so it requires additional markup.
>
>I don't see how. <div> and <span> are two completely different tags,
Both are semantically neutral elements and can be used whenever there's
no better element available. The only big difference is that 'span' is
inline, while 'div' is a block-level element.
>Generally speaking, I'm not for *any* inline tags.
Images and form elements are inline as well ... ;)
And what about 'abbr', 'code', 'em', 'q', 'strong', 'sub', 'sup' etc.?
If you refuse to use them where appropriate then you're ignoring a huge
amount of proper and semantic markup.
>Just my preference. If
>you're going to be using inline elements heavily, you would be far better
>suited to build your page in XML and style it from there.
What has XML to do with that?
Micha
| |
| Michael Fesser 2006-02-12, 6:36 pm |
| ..oO(crash)
>
>any more info on this? what's it going to do, are they just getting rid of
>1-6?
Nope, but in addition there will be a kind of generic heading element
without a number. It's intended use is in combination with a 'section'
element.
8. XHTML Structural Module
http://www.w3.org/TR/xhtml2/mod-str...tructuralmodule
But XHTML2 is still in work and it will take some years until browsers
support it in a usable way ...
Micha
| |
|
| I would use this:
<ul>
<li><a class="currentheader_mainlinks" href="index.html">Home</a></li>
<li><a href="about.html">About</a>
</ul>
You could also put this into an array (if you want to get this in depth)
(psuedo code, you'd have to get a js person to help)
If varPageName = "index.html"
write("<li><a class-"currentheader_mainlinks">
href="index.html">Home</a></li>")
Else
write("<li><a href="index.html">Home</a></li>")
If varPageName="about.html"
write("<li><a class"currentheader_mainlinks"
href="index.html">About</a></li>")
Else
write("<li><a href="about.html">About</a></li>")
and so on to take care of the rest of your menu options. You would need to
capture the page name, strip out the domain name, etc. but it would
certainly ease maintenance to have your menu all contained in one file.
HTH,
Jon
"wadup" <webforumsuser@macromedia.com> wrote in message
news:dse1cb$m7v$1@forums.macromedia.com...
>i mostly use spans for emphasis on the current link.........
>
> so if you are in the about page the about link is emphasised vs the other
> links........good reasont o use it?
>
> something like this.....
>
> <ul>
> <li><a href="index.html"><span
> class="currentheader_mainlinks">Home</span></a></li>
> <li><a href="about.html">About</a></li>
> <li><a href="products.html">Products</a></li>
> <li><a href="news.html">News</a></li>
> <li><a href="contact.html">Contact</a></li>
> </ul>
>
| |
|
| > you are wrong....no worries though.....i just forgot how many <h> they
> had.....i normally use <span> to style differant headlines....but i am
> getting
> back into the habbit of using more <h> elements...and i could remember how
> many
> existed...
:o) You have my appologies.
| |
|
| strange....the separator puzzles me a bit.
are there any browsers out that support this? (I'm checking the site as I
ask). It would be nice to play with this a bit.
"Michael Fesser" <netizen@gmx.de> wrote in message
news:6s2mu15r7ap22un4dfn7ttqupv7o410nsh@4ax.com...
> .oO(crash)
>
>
> Nope, but in addition there will be a kind of generic heading element
> without a number. It's intended use is in combination with a 'section'
> element.
>
> 8. XHTML Structural Module
> http://www.w3.org/TR/xhtml2/mod-str...tructuralmodule
>
> But XHTML2 is still in work and it will take some years until browsers
> support it in a usable way ...
>
> Micha
| |
|
| > | Span, in my opinion, is equivalent to the font tag [...]
>
>
> Yes, and I do. But the 'dt' contains both a date and a title. I want the
> date to appear differently, so it requires additional markup.
d pointed that out - I missed it.
>
> Images and form elements are inline as well ... ;)
I don't consider form elements to be inline as I believe they are a seperate
*function* to the document and not mean to formatting purposes (images,
typically, do not have a function, only an emphasis to written content,
there are cases this isn't true).
I haven't found a way to handle images yet that I like. I'm actually pretty
frustrated with them at this point.
> And what about 'abbr', 'code', 'em', 'q', 'strong', 'sub', 'sup' etc.?
> If you refuse to use them where appropriate then you're ignoring a huge
> amount of proper and semantic markup.
When it comes to business documents, I'm in favor of black and white. I'm in
favor of bold headlines and regular text. Again, I feel I need to stress
that this is a personal design choice or preference rather than me saying
"there is only one way to do things". I *personally* don't like inline
elements. When they are used, it is in my opinion that a
<strong><em><sup><sub> tags are more efficient when writing the code than
*rewriting* that funciton and assinging it to a span class or ID. If you're
goign to bold a date, you're probably always going to bold a date - and
either way, you're still going to have to remove tags - but if you just use
inline and not inline+css, then you only have one place to edit.
>
>
> What has XML to do with that?
If you're talking about creating a document (today) with rigid
classifications and very distinct styling, the correct way to do it is XML.
HTML *works* but is no longer efficient at delivering content across
multiple platforms with minimal maintenance. If you're going to have a
*very* specifically formatted document (ie, what I would say many inline
tags constitute), then I would suggest a rigidly structured document that is
then styled according to it's organization. This is possible today, and I
see no advantage of "learning" HTML and then having to relearn XML. I think
you'd be better off simply starting in XML and learning how to display it in
your different functions - again, if your formatting is going to be rigidly
styled and you're going to be pushing it across multiple platforms (such as
graphical browsers, text browsers, rss feeds, cell phones, etc.). This is,
of course, an ideal situation, and the learning of XML + CSS is extremely
different than learning simple HTML or even HTML+CSS. In reality, inline
tags are a fair way to create a page - again, just not a personal
preference.
OK, too early and I'm not even sure if I'm getting out what I'm meaning to.
:O) I'll just say, I'm not arguing the "correctness" only my preferences.
I think there is enough leeway in programming for both.
| |
| Michael Fesser 2006-02-12, 6:37 pm |
| ..oO(crash)
>strange....the separator puzzles me a bit.
>
>are there any browsers out that support this?
I don't know. Your best chance for such things are Opera and Firefox.
Just try it.
Micha
| |
| Michael Fesser 2006-02-12, 6:37 pm |
| ..oO(crash)
>
>I don't consider form elements to be inline as I believe they are a seperate
>*function* to the document and not mean to formatting purposes
Nearly every element in HTML has a special function. The only elements
whose only purpose is presentation are 'b', 'i' and the like. All others
have a _meaning_, they are there for good reason.
>(images,
>typically, do not have a function, only an emphasis to written content,
>there are cases this isn't true).
Of course images can have a function and be important content. There are
things that simply can't be expressed in words.
>I haven't found a way to handle images yet that I like. I'm actually pretty
>frustrated with them at this point.
What's wrong with 'img' elements?
>
>When it comes to business documents, I'm in favor of black and white. I'm in
>favor of bold headlines and regular text.
Given this you would have to write
<div class="heading">...</div>
<div class="text">...</div>
But I'm sure you don't, but use proper HTML elements instead. Why? Using
heading and paragraph elements on one side, but refusing to use inline
elements on the other doesn't really make sense to me. BTW: 'a' is also
an inline element ...
> Again, I feel I need to stress
>that this is a personal design choice or preference rather than me saying
>"there is only one way to do things". I *personally* don't like inline
>elements.
And the question remains - why? I simply don't understand it, because
there's no reason.
> When they are used, it is in my opinion that a
><strong><em><sup><sub> tags are more efficient
It's not about efficiency, it's not even about presentation. It's simply
about semantics. All these elements have a special meaning:
<span class="important">foo</span>
is just meaningless text, regardless of the class or its presentation.
It means nothing, just "foo". This OTOH:
<em>foo</em>
_is_ important text, even without any explicit styling.
>when writing the code than
>*rewriting* that funciton and assinging it to a span class or ID. If you're
>goign to bold a date, you're probably always going to bold a date - and
>either way, you're still going to have to remove tags - but if you just use
>inline and not inline+css, then you only have one place to edit.
HTML for structure, CSS for presentation.
>
>If you're talking about creating a document (today) with rigid
>classifications and very distinct styling, the correct way to do it is XML.
Not necessarily. Presentation is not my primary task, more important is
a reasonable document structure. _Then_ comes the presentation.
>HTML *works* but is no longer efficient at delivering content across
>multiple platforms with minimal maintenance.
Of course it is. The result is always (X)HTML, even if it may be
generated from an XML source.
>If you're going to have a
>*very* specifically formatted document (ie, what I would say many inline
>tags constitute)
I disagree.
>I think
>you'd be better off simply starting in XML and learning how to display it in
>your different functions
Try to display styled XML in a browser ... and then forget it. Currently
the _only_ portable solution is HTML. And believe me - I _do_ use XML,
but only when it makes sense. And currently this happens rather rarely.
> - again, if your formatting is going to be rigidly
>styled and you're going to be pushing it across multiple platforms (such as
>graphical browsers, text browsers, rss feeds, cell phones, etc.).
HTML does this perfectly, far better than XML (except for RSS, but
that's a completely different issue).
>This is,
>of course, an ideal situation, and the learning of XML + CSS is extremely
>different than learning simple HTML or even HTML+CSS.
The concepts are similar.
> In reality, inline
>tags are a fair way to create a page
They are the _preferred_ way, simply because it's proper use of HTML.
There's no valid reason to ignore them, except maybe for lazyness.
>OK, too early and I'm not even sure if I'm getting out what I'm meaning to.
>:O) I'll just say, I'm not arguing the "correctness" only my preferences.
>I think there is enough leeway in programming for both.
I'm just questioning your preferences, because I can't understand them.
Micha
| |
|
| i am. :)
thanks for the link man.
"Michael Fesser" <netizen@gmx.de> wrote in message
news:csumu193kr2dtig41mp4m71gc26ul9gvfv@4ax.com...
> .oO(crash)
>
>
> I don't know. Your best chance for such things are Opera and Firefox.
> Just try it.
>
> Micha
| |
|
| Micha-
I'm not sure i'll be able to exmplain. I know I don't have time today. I
wil ltry to get somethign written sometime
> Nearly every element in HTML has a special function. The only elements
> whose only purpose is presentation are 'b', 'i' and the like. All others
> have a _meaning_, they are there for good reason.
In my classification - I'm seperating *formatting* from *functionality*. <a
href> is a functional tag. <form> is a functional tag. <ol> is a formatting
tag - while it does denote structure, it doesn't actively *do* anything. It
is document formatting - tree structure showing - whatever. There is no
action associated with this. It's not going to "do" anything relative to
the rest of the site.
> Of course images can have a function and be important content. There are
> things that simply can't be expressed in words.
But you're *conveying content*. You're not functionally changing anything,
you're not effecting the rest of the site - your image is content. And
every image [that i can think of] can be described. If it hasn't, it has no
use on an accessible website, as the blind will not see it.
>
> What's wrong with 'img' elements?
They're inline, I don't like the way I have to handle them in databases
(can't seperate out textual content from image links w/o CMS). They are the
last obstacle (to me, right now) from me seperating text and formatting. I
can't format an image unless I use inline formatting. (i can use css, but it
must still be relative to each individual image).
This isn't true, of course, if you place all images in the same spot, with
the same formatting, etc.etc., but that's not what I'm looking for.
>
> Given this you would have to write
>
> <div class="heading">...</div>
> <div class="text">...</div>
>
> But I'm sure you don't, but use proper HTML elements instead. Why? Using
> heading and paragraph elements on one side, but refusing to use inline
> elements on the other doesn't really make sense to me. BTW: 'a' is also
> an inline element ...
Heading and paragraph are both block level tags. <a> is a functional tag as
it influences the rest of the site, and therefore acceptable to me.
>
> And the question remains - why? I simply don't understand it, because
> there's no reason.
You're using Micha logic - you need to use Jon logic. ;o)
I'm not saying it even needs to make sense to you. I've tried to say all
along that this is simply *my* method of doing things. I'm not tryign to
attack other ways (though it's apparently been perceived that way).
>
> It's not about efficiency, it's not even about presentation. It's simply
> about semantics. All these elements have a special meaning:
>
> <span class="important">foo</span>
>
> is just meaningless text, regardless of the class or its presentation.
> It means nothing, just "foo". This OTOH:
>
> <em>foo</em>
>
> _is_ important text, even without any explicit styling.
and I guess would say, then that if you're writing for semantics, HTML is
the wrong language and you should go to a more strict language, like XML.
I don't write for sematics - I don't care for them. It's not part of my
makeup.
>
> HTML for structure, CSS for presentation.
does structure = text importance? to me, it does not.
>
>
> Not necessarily. Presentation is not my primary task, more important is
> a reasonable document structure. _Then_ comes the presentation.
OK - I jsut see this in support of using XML.
>
> Of course it is. The result is always (X)HTML, even if it may be
> generated from an XML source.
>
>
> I disagree.
>
>
> Try to display styled XML in a browser ... and then forget it. Currently
> the _only_ portable solution is HTML. And believe me - I _do_ use XML,
> but only when it makes sense. And currently this happens rather rarely.
this is just a difference of opinion, i guess. I don't use XML as much as I
should.
>
> HTML does this perfectly, far better than XML (except for RSS, but
> that's a completely different issue).
Not in the circumstances that I have observed. XML is better, IMO.
>
>
> The concepts are similar.
I completely disagree here. HTML is meant for one thing (SML you could
argue is not). XML is meant to classify the text, HTML is meant to setup a
structure for the page - I see a vast difference there.
>
> They are the _preferred_ way, simply because it's proper use of HTML.
> There's no valid reason to ignore them, except maybe for lazyness.
They are preferred by you. I do not prefer them. I write completely valid
HTML. I am exceedingly lazy. I do not wish to do 5 steps when 3 will
suffice.
>
> I'm just questioning your preferences, because I can't understand them.
OK - perhaps this will help you.
I see HTML as a dead dog. It has some uses, but I see them as limited
| |
| Michael Fesser 2006-02-12, 6:38 pm |
| ..oO(crash)
>
>Heading and paragraph are both block level tags.
And? They just markup some part of a text, like all the inline level
elements. They're just rendered differently by default, but of course
you could also render a heading element inline if you want. Or a link
like a block-level element ...
>
>and I guess would say, then that if you're writing for semantics, HTML is
>the wrong language and you should go to a more strict language, like XML.
I can't really follow you. HTML _is_ about semantics! XML alone is
meaningless, it always requires a processing script to get some
semantics out of it.
<h1>foo</h1> in HTML has a meaning in _every_ browser, in XML it would
be nothing, just an element with the name 'h1' and the content 'foo'.
>I don't write for sematics - I don't care for them. It's not part of my
>makeup.
Then HTML is most likely the wrong thing for you, maybe PDF would be a
better choice ...
>
>does structure = text importance? to me, it does not.
Sure it does. An emphased text is something different than a paragraph.
Even the different heading elements have different importances.
>
>Not in the circumstances that I have observed. XML is better, IMO.
Depends on how you define "better". Only the most recent browsers
support XHTML (the most used browser does _not_, BTW) and XML. But _all_
browsers support HTML.
>
>I completely disagree here. HTML is meant for one thing (SML you could
>argue is not). XML is meant to classify the text, HTML is meant to setup a
>structure for the page - I see a vast difference there.
HTML also classifies text. XML just has a stricter syntax and is open
for own definitions and rules, whereas the set of elements in HTML is
restricted and predefined by the spec.
>
>They are preferred by you. I do not prefer them. I write completely valid
>HTML.
Validity is just about syntax, not about semantics. It tells you nothing
about if a website will be really usable or not. The most valid sites
can be completely unusable and vice versa.
>I am exceedingly lazy. I do not wish to do 5 steps when 3 will
>suffice.
Ignoring inline elements will never suffice.
>I see HTML as a dead dog. It has some uses, but I see them as limited
HTML was and is the basis of the WWW. It will be alive for _many_ years,
that's for sure. Even XHTML is still more HTML than XML, so HTML is more
alive than ever.
Micha
| |
|
| > I can't really follow you. HTML _is_ about semantics! XML alone is
> meaningless, it always requires a processing script to get some
> semantics out of it.
>
> <h1>foo</h1> in HTML has a meaning in _every_ browser, in XML it would
> be nothing, just an element with the name 'h1' and the content 'foo'.
>
>
> Then HTML is most likely the wrong thing for you, maybe PDF would be a
> better choice ...
HTML and I have never been a good fit. :) To me, it's a horribly painful
mix of "can almost do this" "can make it work like this" and "need this
[language/plugin] to make it work". I really thought we'd all be running
compiled files by now off the net, more inline to mainstream programming.
>
> Sure it does. An emphased text is something different than a paragraph.
> Even the different heading elements have different importances.
Yeah, i dont' even have any idea where I was coming from on this. That
statement is actually completely contradictory to what I was saying, so I
have *no* idea. Too little caffeine, too little time to get focused
thoughts out (one post usually takes me about 40 minutes, back and forth, to
write).
This statement was why I decided I was definitely no longer being
productive. I never speak as clearly as my minda talks to me, and this is a
great example - I'm not even being clear enough to say so I can understand!
lol.
>
>
> Depends on how you define "better". Only the most recent browsers
> support XHTML (the most used browser does _not_, BTW) and XML. But _all_
> browsers support HTML.
>
[color=darkred]
> HTML also classifies text. XML just has a stricter syntax and is open
> for own definitions and rules, whereas the set of elements in HTML is
> restricted and predefined by the spec.
OK, this is where we were having our problem. I don't guess I can argue
that HTML classifies text, but I would *like* to argue that it should not.
I cannot clarify that right now, however. :) It goes along a bit with my
earlier paragraph that stated I thought the net would have progressed a bit
before this by now. To me, HTML should almost be .... well, I'm gonna get
started again. LOL. I'm too tired and the past two days have been too much
for me. I'm almost absolutely brain dead. I'll try to catch up with you
later on this. I'm sure they will be another post to hijack. 8^)
| |
| Clancy 2006-02-12, 6:39 pm |
| "crash" <crash@bcdcdigital.com> wrote:
>Micha-
..............................
>
>But you're *conveying content*. You're not functionally changing anything,
>you're not effecting the rest of the site - your image is content. And
>every image [that i can think of] can be described. If it hasn't, it has no
>use on an accessible website, as the blind will not see it.
A picture is worth 1000 words.
If I put a picture of Joe Blow on my web site it will give the sighted visitor a
pretty good idea of what he looks like -- probably good enough to recognise him
if the visitor is going to meet him. It will tell the blind visitor nothing.
If I put under Alt "Picture of Joe Blow" it will still tell the blind visitor
nothing useful.
I could put under Alt "Picture of the Joe Blow. Joe is a 50 something white
Caucasian male, about 5'6", a bit overweight, receding hairline, straggly
mustache, daggy choice of clothes, etc, ....". This might give the blind
visitor a slightly better idea of Joe, but nothing that will really help him
much. On the other hand, if I am honest, it is highly probable that it will
offend Joe, if he ever reads it.
So am I going to omit the image, which could be very useful to 999 of my
visitors, because it is virtually useless to the thousandth?
| |
|
| > mustache, daggy choice of clothes, etc, ....". This might give the blind
> visitor a slightly better idea of Joe, but nothing that will really help
> him
> much.
It will if that's the way the person has always interpreted the world. You
can't explain what a picture looks like to somebody who has never perceived
light and dark.
On the other hand, if I am honest, it is highly probable that it will
> offend Joe, if he ever reads it.
dont' be that honest.
> So am I going to omit the image, which could be very useful to 999 of my
> visitors, because it is virtually useless to the thousandth?
no. nor was i saying to leave images out. i just said i'm currently
frustrated by my inability to place images in page without an inline tag.
| |
|
| LOL
nice.
> img {display: block}
>
> SCNR ;)
> Micha
| |
| Michael Fesser 2006-02-12, 6:40 pm |
| ..oO(crash)
>no. nor was i saying to leave images out. i just said i'm currently
>frustrated by my inability to place images in page without an inline tag.
img {display: block}
SCNR ;)
Micha
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|