 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / March 2007Doctype question from amateur
I'm trying to clean up my website, and it's in pretty good shape now, but I've gotten confused reading about Doctypes. My site is http://www.simi-therapy.com and my CSS is http://www.simi-therapy.com/simitherapy-screen.css . My pages all start with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Language" content="en-us" /> I think this came from the template I am using, but I'm not sure. Should I be using XHTML strict, or HTML 4.01 strict? And if I should change it, what exactly do I put in each line? I should mention that my pages have 2 things that don't validate in XHTML strict. One is a Google search engine tag, and another is me using an address block for formatting, because I haven't yet figured out how to use CSS to get the same result. Thanks for your help. This group teaches me a lot -- I am amazed at how much I have learned here. Deborah > I'm trying to clean up my website, and it's in pretty good shape now, > but I've gotten confused reading about Doctypes. My site is [quoted text clipped - 24 lines] > > Deborah You might consider simplifying your code and removing the <div class="midHeader"> </div> from your html and removing the associated css, and amalgamating into something like this instead: .headerTitle { background-color: rgb(140,170,230); background-image: url('beach hill long.jpg'); background-repeat: no-repeat; font-size: 200%; font-weight: normal; margin: 0; padding: 0; max-height: 100px;min-height: 100px; } This sort of thing seems to work nicer under different click stops for text size adjustments in good browsers. IE6 and below is not particularly happier I expect. But perhaps they are not unhappier. About xhtml. Perhaps leave it as it is for now. In future use 4.01 Strict and read up on how to run write the tags for this. /Users/tedkroiter/Sites/droovies/test/test3.html:156: The XHTML specification recommends including a space before the trailing ³/>² in empty XML elements. (You do not always do this). In 4.01 there is no need for this. It is a peculiar use of address, yours, for each bit of an address?? Get rid of the span in which it is enclosed. And I would say if you use address, use <br> to separate the lines, not more "address".  Signaturedorayme Scripsit Deborah: > I'm trying to clean up my website, Well, there's always someone who rewrites working code, to clean it up or to speed it up, but why? It's more constructive to orientate to start creating new pages well. Please note that this is c.i.w.a.stylesheets, not c.i.w.a.site-design. > Should I be using XHTML strict, or HTML 4.01 strict? Yes. Oh, you meant which is better? If you had to ask, then surely HTML 4.01 Strict. > And if I should > change it, what exactly do I put in each line? You should write a DOCTYPE declaration exactly as specified in the HTML specifications, mainly to make browsers work in "standards mode", provided that you create pages that use CSS by the specifications. > I should mention that my pages have 2 things that don't validate in > XHTML strict. One is a Google search engine tag, and another is me > using an address block for formatting, because I haven't yet figured > out how to use CSS to get the same result. We have a CSS question! The <address> element indicates, by HTML specifications, contact information for the author of the document. There is nothing mystic in its rendering, except that IE oddly renders it in italics by default. For an address in general (not the document author's address), it's best to use just <div> elements, since there's really no semantic markup you could use. For example, <div class="addr"> <div>Families Counseling Center</div> <div>1633 Erringer Rd. #204</div> <div>Simi Valley, CA 93065</div> <div>805-583-3976</div> </span> Then simply set any desired styling for the outer <div> or maybe for the inner <div>s (if you want to affect e.g. the wrapping of long lines). If you want italics (why?), then you'd use .addr { font-style: italic; } (The thing that makes your use of <address> invalid - in the formal sense - is that you have put it inside <span>. Changing <span> to <div> would fix this, but the markup would still be semantically wrong.) SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > The <address> element indicates, by HTML > specifications, contact information for the author of the document. There is [quoted text clipped - 8 lines] > <div>Simi Valley, CA 93065</div> > <div>805-583-3976</div> It sure is an understandable mistake to use <address> for an address. Seems like an unfortunate decision in the standard. What an oddly quaint _little_ issue, the author's address to be grabbed by such a word! Now address generally, that is what would be really useful to be granted an element. Address giving is so common a task in website communication. BTW, is there any reason not to just use <br> in the above alternative div suggestion, no inner divs where no different styling is required for each line. Be nice to have something like <address-general> Families Counseling Center,1633 Erringer Rd., Simi Valley, CA 93065</address-general> where the commas would be rendered as line breaks. Signaturedorayme In article <doraymeRidThis-932051.07490927032007@news-vip.optusnet.com.au>, > Be nice to have something like <address-general> Families > Counseling Center,1633 Erringer Rd., Simi Valley, CA > 93065</address-general> where the commas would be rendered as > line breaks. OK, not commas, maybe something as easy to type. Signaturedorayme Scripsit dorayme: > It sure is an understandable mistake to use <address> for an > address. Yes, and common enough to make even proper (specification-conformant) use of <address> dubitable. For example, _if_ <address> were used consistently, it would make sense to have a user style sheet that renders its content prominently and in a specific position, so that you can always use the contact information easily. But since <address> may contain just about anything - some people use it just to get italics! - the idea is not that great. > Seems like an unfortunate decision in the standard. What > an oddly quaint _little_ issue, the author's address to be > grabbed by such a word! It's really the _name_ of the element (the tag name, the Generic Identifier) that was poorly chosen. It should have been <author>. > Now address generally, that is what would > be really useful to be granted an element. Address giving is so > common a task in website communication. But there are so many different kinds of addresses. There is little in common between an email address and a postal address, for example. > BTW, is there any reason not to just use <br> in the above > alternative div suggestion, no inner divs where no different > styling is required for each line. My reason was that <div> is slightly more logical (it divides the element into subelements, as opposite to using separators between fragments of text) and more suitable for styling (as well as DOM scripting). Maybe you don't want to style the inner elements, but if you ever decide to, you will have elements to play with, possibly without any extra markup, possibly with the addition of class attributes. For example, even if you expect an address to be rendered in an area wide enough for every line, it doesn't cost much to prepare for narrower areas. Using <div>, you can easily specify that if a <div> (a logical subdivision of the address, normally rendered on one line) is broken into several lines, the second and subsequent lines will be indented a bit to indicate continuation lines > Be nice to have something like <address-general> Families > Counseling Center,1633 Erringer Rd., Simi Valley, CA > 93065</address-general> where the commas would be rendered as > line breaks. That would not fit into the HTML and XML model, which have simplistic markup structure, as opposite to the possibilities of SGML for example. But if you use <div> with inner <div>s as I suggested (without the commas), you can specify, in CSS, alternate renderings like the normal by-lines presentation and a compact presentation as in your proposed _source_ (plus a trailing period, which of course could be omitted if desired): .addr div { display: inline; } .addr div:after { content: ", "; } .addr div:last-child:after { content: "."; } (Allow 8 years for delivery of a CSS 3 specification and browser support to it.) SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > > Now address generally, that is what would > > be really useful to be granted an element. Address giving is so > > common a task in website communication. > > But there are so many different kinds of addresses. There is little in > common between an email address and a postal address, for example. I take your point. Still, I would have thought that postal addresses are a big enough thing to be assigned an element. But it is simple enough otherwise, I have just made a site which contains a lot of postal addresses and I have used something along the lines you have previously suggested, namely a div classed (in my case as "address"). No other fancy inner styling needed, just all left with breaks. > > BTW, is there any reason not to just use <br> in the above > > alternative div suggestion, no inner divs where no different [quoted text clipped - 6 lines] > elements to play with, possibly without any extra markup, possibly with the > addition of class attributes. Fair enough. I should be so pure! Signaturedorayme > I take your point. Still, I would have thought that postal > addresses are a big enough thing to be assigned an element. They're too big a thing. If we have postal address, why not have phone numbers and shoe sizes too? Should the "zip code" be US style, or your own fractal canal-branch identifiers? HTML is _minimal_ and it represents uniform _documents_. It has concepts like "body text" and "header" that can be reasonably applied to any document, but it doesn't have things like "address", "iambic pentameter" or "computer manual menu description" (and of course presentation). If you look at DocBook, which _does_ include markup for such things (including <kitchen-sink>), then you should realise what a good thing this is. How to overlay things like addresses onto HTML is a known problem with some tolerably well-known solutions. They can even disambiguate the author's address from the publisher's address, from the described resource's geographical location. Maybe there are a few too many such protocols, but it's not impractical to use them. Scripsit Andy Dingley: > HTML is _minimal_ No, it isn't. It has many markup elements and attributes that are far from minimal. > and it represents uniform _documents_. I fail to find the meaning (information content) of that statement. > If you look at DocBook, which _does_ include markup > for such things (including <kitchen-sink>), then you should realise > what a good thing this is. Really? Quite the opposite is true. All the babble about "semantic Web" is largely based on the observation that there is rather little semantics in markup (and on a hopeless attempt to solve this by writing treatises on semantic Web and unrealistic formalisms that are far more complex than any proposed HTML enhancements ever). > How to overlay things like addresses onto HTML is a known problem with > some tolerably well-known solutions. The _styling_ problem is solvable, though there is no _natural_ markup to base the styling on. In simple cases, you could use different markup elements (<address> with <br>, <p> with <br>, <div> with <br> or inner <div>, <pre>, or <table>) and achieve the desired appearance using fairly simple CSS. But let's not pretend that this is an optimal situation. The address remains just lines of text, with no defined semantics (except possibly wrong semantics with <address>!) assigned to it in markup. You can't write a Perl few-liner that extracts all address blocks from a given set of web pages, since it cannot know what is an address block. Neither can users write user style sheets that display addresses the way they prefer, Besides, from the styling point of view, you cannot be confident about the rendering in the sense that if your style sheet is not applied, the browser still displays addresses in a useful way that gives a hint about their being addresses. By the way, to return from the markup philosophy to the topic area of this group, the <pre> element is a possible choice for address markup, since CSS can be used to change its font (from the default monospace). The benefit is that you don't need to add <div> or <br> markup to indicate line structure. You could achieve the same using white-space: pre for e.g. a <div> element, but then the presentation is confusing when CSS is off. So the following is a reasonable choice: <pre class="address"> address info here divided into lines with no extra markup </pre> with .address { font-family: Arial, sans-serif; } SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > Scripsit Andy Dingley: > > > HTML is _minimal_ > > No, it isn't. It has many markup elements and attributes that are far from > minimal. It certainly does, 3.2 far more so than 4.01 However compared to what it _could_ have been, as exemplified by DocBook, HTML 3.0 or whatever HTML 3.0 might have spawned as a successor, then it's still pretty minimal. > > and it represents uniform _documents_. > > I fail to find the meaning (information content) of that statement. HTML represents a "document". It makes no claims for anything more than that, for a simple dictionary compatible meaning of document as "a formal piece of writing that provides information". It doesn't express any more semantics than I could find by reading a document in Suomi: I can recognise paragraphs, sentences, emphasis, headings and other structures common to Western languages, but the meaning of any specific contexts applied to sections (such as an "address") is opaque to me. I can even recognise a mechanical linkage for hypertext, but there's no useful citation mechanism of the sort essential for publishing theoretical physics papers. On the whole, this is an excellent level at which it should have been pitched. Praise Tim. > > If you look at DocBook, which _does_ include markup > > for such things (including <kitchen-sink>), then you should realise > > what a good thing this is. I mean of course that HTML's minimalism is a good thing. DocBook combines the worst of bloat with least of usefulness outside its own narrow scope. > a hopeless attempt to solve this by writing treatises on > semantic Web and unrealistic formalisms that are far more complex than any > proposed HTML enhancements ever). The uselesness of SW would presumably be why Yahoo!'s recent "pipes" fail to work, and are failing to work for thousands of users every day? > > How to overlay things like addresses onto HTML is a known problem with > > some tolerably well-known solutions. > > The _styling_ problem is solvable, though there is no _natural_ markup to > base the styling on. As always, your narrow vision for anything outside SGML's narrow descendants is blinding you to actually building anything interestting, new or useful. I'm talking about vCard, Dublin Core and their ilk (it ain't great, but it delivers). > You can't write a Perl > few-liner that extracts all address blocks from a given set of web pages, > since it cannot know what is an address block. As it happens I have done. Python, many lines, evil piece of cruft, mines a surprisingly large amount of useful data and is remarkably accurate (it tends to fail with a null, rather than failing with a false address). Scripsit Andy Dingley: >> No, it isn't. It has many markup elements and attributes that are >> far from minimal. > > It certainly does, 3.2 far more so than 4.01 Are you kidding, or did you just write the exact opposite of what you meant. > However compared to > what it _could_ have been, as exemplified by DocBook, HTML 3.0 or > whatever HTML 3.0 might have spawned as a successor, then it's still > pretty minimal. I'm afraid you have a private definition for "minimal". It's a Latin-based word for "smallest", not "smaller". > The uselesness of SW would presumably be why Yahoo!'s recent "pipes" > fail to work, and are failing to work for thousands of users every > day? Please explain how "Semantic Web" was necessary for "pipes", but please do that on a forum where such issues are on-topic. > As always, your narrow vision for anything outside SGML's narrow > descendants is blinding you to actually building anything > interestting, new or useful. I'm talking about vCard, Dublin Core and > their ilk (it ain't great, but it delivers). Blech. Was Dublin Core ever anything but a write-only system for metadata, at a level that is vaguely defined yet complex enough to make writing real work? Did it ever have any connection with CSS? >> You can't write a Perl >> few-liner that extracts all address blocks from a given set of web >> pages, since it cannot know what is an address block. > > As it happens I have done. Hardly. You have redefined the task, making it something sufficiently trivial (and irrelevant), or you don't actually mean _web_ pages. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ >I'm afraid you have a private definition for "minimal". It's a Latin-based >word for "smallest", not "smaller". HTML isn't perfectly minimal, but it (4 Strict anyway) is a reasonable approximation. It's "minimal + legacy cruft", not "deliberately bigger than minimal". We have absurdities like <var> that simply shouldn't be there and are thankfully ignored, and we have badly stunted half-features like <address> and <cite> that exist, but not in a form that's developed enough to be used. On the brighter side, we've lost the purely presentationals and <em>, <i> and <sub> have some justification to survive. It has also managed to avoid sprouting excresences and protuberances as DocBook has. if you don't think it's minimal, just think what it _could_ have been! It might not be there, but its aspirations are in that direction, not the other. >Blech. Was Dublin Core ever anything but a write-only system for metadata, Yes. You shouldn't have stopped paying attention at the end of the '90s. >>> You can't write a Perl >>> few-liner that extracts all address blocks from a given set of web [quoted text clipped - 4 lines] >Hardly. You have redefined the task, making it something sufficiently >trivial (and irrelevant), or you don't actually mean _web_ pages. No, it slurps down arbitrary web pages. Web pages it gets from hints via supplied FOAF, in an attempt to decorate the FOAF with things that look like a suspicion of being addresses. As I said, it works surprisingly well. It's not an address book replacement, but it's an interesting form of data mining. SignatureCats have nine lives, which is why they rarely post to Usenet. Scripsit Andy Dingley: > HTML isn't perfectly minimal, Either something is minimal (smallest) or it isn't. Being minimal is by definition extremal. You were just trying to say that HTML is small; please admit that. (It's not a correct statement either, but it's relative enough to be non-ridiculous.) >> Blech. Was Dublin Core ever anything but a write-only system for >> metadata, > > Yes. You shouldn't have stopped paying attention at the end of the > '90s. Please show me one practical benefit you get from using Dublin Core on web pages, but please do it on a forum where it is on-topic. SignatureJukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/ > By the way, to return from the markup philosophy to the topic area of this > group, the <pre> element is a possible choice for address markup, since CSS [quoted text clipped - 13 lines] > > .address { font-family: Arial, sans-serif; } This is an excellent suggestion and while I was not so unhappy with div and <br>s, I was not exactly happy either. Next time I do address, I will do this pre of yours and see how it feels. I know the hard-heads around here do not understand this, but for some of us, authoring is a very emotional business. We need rules that make us feel calm and steady and happy. Signaturedorayme In article <1175079419.450838.11310@p15g2000hsd.googlegroups.com>, > > I take your point. Still, I would have thought that postal > > addresses are a big enough thing to be assigned an element. > > They're too big a thing. If we have postal address, why not have phone > numbers and shoe sizes too? Should the "zip code" be US style, or > your own fractal canal-branch identifiers? The answer to this is easy enough surely? Because this would be overkill. At least in my mind, a postal address is much the better choice for address than authors address. What goes on an envelope is universally known in form, it is almost beautiful. Perhaps posting things is a dying art but be careful in dismissing centuries (by now) of postal culture. Why be barbarian about these things? Seriously, I take your point too and yes, less is more powerful and efficient, it is the basis and power of language (we only need a few words, the rest is up to the way we put them together, sure). But really, the context of my remarks was when I saw how some egomaniac decided to push through "author's address". Author's address, for god's sake! Why ponce about styling bits of a reference to some point on the earth? So no, it is silly to even think of specifying the idea of postal address element in advance to the level of zip code bits. The main point is one of meaning, all the text is part of a location. How it is laid out from there is up to the author. Personally, I favour no styling beyond line breaks, all left and no messing about like addressing an average envelope (flat rectangular paper pack that one can insert material, usually more paper, and then seal by licking/pressing a pre gummed paper lid) Signaturedorayme >At least in my mind, a postal address is much the >better choice for address than authors address. You're comparing apples and fish. Earth vegetables: one because of its taxonomy in the plant kingdom, the other because it's regarded as food by some vegetarians. Equally with addresses: "postal address" is a format, a property of the object itself, and one that makes no claims about the usage of it (who's address?). "Author's address" is the address of a defined body (which might be a script) but it doesn't say whether the format is geographical or virtual. I suspect that HTML's <address> is actually a poorly-named dc:creator, because that's something that is a concept applicable to all HTML pages and doesn't pre-suppose a format. It's "design by what's easy" rather than "design for useful purpose". > >At least in my mind, a postal address is much the > >better choice for address than authors address. > > You're comparing apples and fish. ... I can't think how you could so misunderstand what I was saying. Never mind about apples and fish and vegetarians and all this cute stuff. Someone at some stage thought to make an element for something about authors. Right? And I am saying they would have better spent their time on making a different element. Why don't you go and have a nice juicy steak. I think you need one. Signaturedorayme > Someone at some stage thought to make an element for > something about authors. Right? And I am saying they would have > better spent their time on making a different element. Your hypothesis appears to depend on these two axiomatic statements: "<postal-address> would have been more useful than <author-address>" "<postal-address> would have be comparably difficult to define" Although I can see some justification for the first, I disagree over the second. The problem is that one address is an apple, the other a fish. <author- address> is defined by its external _usage_ (a fish) but <postal- address> is defining an internal structure (an apple) without implying what it's used for. They really have no more "address nature" in common than the label applied, they're totally different tasks. <author-address> is a property of the page, not a structure. <postal- address> is a type definition, not a property. As a result, the design work need for each of these just isn't comparable. There's some justification for HTML to include an author property (all pages have it), although I'd prefer to do it through a more generalised mechanism like the existing <meta>, with an external vocabulary like DC to specialise it into authorship. I can only assume that <author-address> was added with the aim of making this visible on the rendered page body, unlike subject or description. A dubious choice, IMHO. If HTML sprouted a structural element, like <postal-address> it's a non-trivial thing to add, mainly though it's a horrible problem for i18n and it has the risk of making HTML into bloated DocBook. Avoid. In article <1175166364.260991.122840@b75g2000hsg.googlegroups.com>, > > Someone at some stage thought to make an element for > > something about authors. Right? And I am saying they would have [quoted text clipped - 11 lines] > address> is defining an internal structure (an apple) without implying > what it's used for. They really have no more "address nature".... OK. It's clearly more complicated than I imagined! So thanks for this. And I do take your point about keeping HTML as simple as possible. Truth is, we should all be perfectly happy to style divs and pres. I just thought ... well, I won't repeat it. Signaturedorayme > Should I be using XHTML strict, or HTML 4.01 strict? HTML 4.01 Strict. Don't even think about it (If you have to ask, you're most in need of the simple blanket answer) * There are two entirely separate issues here: XHTML vs. HTML and Strict vs. Transitional. * You're doing this largely to make IE use "standards" rendering not "quirks", rather than for any SGML reasons. Get that working right first! * The doctype declaration (what you put in your document) matters as much as the doctype (what it refers to). Read this: http://hsivonen.iki.fi/doctype/ Use this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/ TR/html4/strict.dtd" > * Validation is good, but it's not everything. A skilled author can still make an invalid page that behaves better than some badly thought- out but valid pages. Validation's main benefit is that it's objective and fairly simple. The rules are stated visibly, the tools are free and easily available. "Quality" is much more subjective! If you're at all unsure, go with "valid and 0 errors" because then you _know_ it's valid. * For most typical legacy pages, typical authors will do better by switching doctypes to HTML 4.01 Strict straightaway, rather than a Transitional doctype. The pages where Transitional is better are actually quite rare: they need to be not only non-valid as Strict but also well-formed and valid as Transitional. If they're not going to meet either standard (the most common situation), then you might as well switch straight to Strict and aim high. If you switch to standards-based rendering early (even on an old page) then you probably won't even notice the change. The mistake is to start tidying up CSS and putting effort in while things are still in quirks mode, then change later and break work you've already done. > <!-- Navigational metadata for large websites (an accessibility feature): > <link rel="top" href="index.htm" title="Homepage" /> No it isn't, that's just a comment. If you want them to be visible and usable, then don't comment them out! > using an address block for formatting, You're actually using multiple address blocks, one for each line. There are a number of problems here: * <address> means "contact information for an author" according to the specification. This is OK for the author's personal documents, but is unclear when they're authoring for a 3rd party. Is this the webmaster, web designer or the site owner? (This has recently become a significant legal issue for sites of UK companies). * It's fairly strongly implied by the spec that there's only one <address> per document, no matter who it belongs to. * <address> is certainly not intended to be used line-by-line, as you have it. * Your literal validity issue is just that you've placed <address> (a block element) inside <span> (an inline context). On the whole, replace it by something simple like this: <div class="sideBarText address" > Families Counseling Center <br>1633 Erringer Rd. #204 <br>Simi Valley, CA 93065 <br>805-583-3976 </div> and a CSS fragment of .address { font-style: italic; } You'll probably find Joe Clark's accessibility book useful too http://joeclark.org/book/sashay/serialization/ > <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> > <meta http-equiv="Content-Language" content="en-us" /> *Everything* called <meta http-equiv> is only a poor ersatz, a cheapo surrogate, a plastic imitation from China. Use the real HTTP header instead. How to do this depends on your server software. Ask in the comp.infosystems.www.servers.* groups. SignatureIn memoriam Alan J. Flavell http://groups.google.com/groups/search?q=author:Alan.J.Flavell |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.