dbrimlow
-
Posts
712 -
Joined
-
Last visited
Never
Posts posted by dbrimlow
-
-
Whoa! Um, you should actually create an html document before attempting to debug any css layout elements.
This, is no way to go about in web life, son:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <link type="text/css" rel="stylesheet" href="parastyle1.css"> <title>Brandeis University : Business Club</title> <style type="text/css"> body {background-color: #213AB5;} </style> <div class="container2"> <div class="container">PROPER HTML document structure. DOCTYPE, html tag, head tag, title tag, meta tags, link to css, close head tag, body tag, web content HERE, close body tag, close html tag.
Without a proper structure, your page is something that every browser will have to assume as html (and display as it can best guess).
Here is what that page needs (at minimum):
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <link type="text/css" rel="stylesheet" href="parastyle1.css"> <title>Brandeis University : Business Club</title> <style type="text/css"> <!-- body {background-color: #213AB5;} --> </style> </head> <body> <div class="container2"> <div class="container"> etc. etc. Blah, blah blah. </body> </html>Once you fix your HTML structure, we can help work on your css.
Dave
-
Well I was going to argue with you, but I'm actualy finding myself agreeing with what you posted dang it.
LOL! I know, doesn't that suck?!! That's what happened to me.
while those without or not left with windows or tabs all over the shop whith no real representation of how to get back.The whole point was to ONLY use it on those links that take you away from the site, so they could just kill the window to return. Remember the OLD rule of website Navigation Design (from back in the 90s)? "Never leave your visitors with nothing but a browser back button".
-
wow what kind of site is that ???
Major NYC Real Estate Apartment rental/sales firm.
I've recently been permitted to convert the old quirks crap, that I made 5 years ago
, to valid css. It has taken me nearly one year to convert half the site and I am now in the process of converting the other half.At least, once finished, changing how the site looks in future will be easy by just changing the css.
This week alone I recoded 150 static html pages to a new layout (but not live yet) and I have another 200 or so to go until all static pages are done. Then I have to go to work on the php pages ... AGGGGGHHH! All those echos of <trs>, <tds> and hundreds of <font="....>!!!!
-
Here is an example of the technique. The corners are NOT images at all. It is a series of ascending or descending margins in the css like this;
b.rtop b, b.rbottom b{display:block;height: 1px; overflow: hidden; background: #800000} b.r1{margin: 0 5px} b.r2{margin: 0 3px} b.r3{margin: 0 2px}In the markup, it is displayed like this:
<body> <div id="container"> <b class="rtop"> <b class="r1"></b> <b class="r2"></b> <b class="r3"></b> <b class="r3"></b> <b class="r4"></b> </b> <b class="r4"></b> <!-- end top rounded corner styles --> <div id="pageHeader">Name of Web Site</div>
The pageHeader id uses a very simple small graphic which is tiled and has the same color for the top as the b class background color -
. Here is how it looks in action:
http://www.regisresidential.com/home.php
Of course, you can change the thickness of the curve by adding more "b classes".
-
Ah, yes ... IE Conditional Comment.
I don't go anywhere without my good old IE conditional comment!
TM, I use DW 8 (for speed editing of tags) and my main site has over 60,000 files including 2500 html and 200 php pages ... doing a site-wide replace just crashes XP like a Mini-Van housewife on a cellphone.
-
Ah. So, you are asking if there is a css command specifically to modify the actual input[type=text] TAG itself (as there is for other tag level elements like p, ul, form, table, td, tr, etc.)? ...
... no.
There was a reason IE had different thoughts. And so would Opera in SuSe 10.1, Safari in OS X 10.4, FF in OX 10.4 or Win XP or SuSe 10.1, IE 6.0 or 7.0 winXP.
As I said in MY post, assigning a css style to the actual single or multiple line text input control "widget" itself (or any other browser-skin controlled web element, like scroll-bars) is NOT cross-browser OR cross-platform compatible. It is an exercise in futility and will make your form look ridiculous except in the browser/platform you specifically tested (and therefore designed) it in.
Here is an actual example of css styling for a single line text input with screenshots of the same css/html in 14 different browser/platforms:
http://www.456bereastreet.com/lab/styling-form-controls-revisited/text-input-single/
-
I am trying to use CSS rules to only input[type=text] but IE seems to be has different thoughts , any solution other than assigning a class to each text box ?
Thanks
You need to be clearer and more specific - perhaps show an example of your html markup and the css. I assume you mean a form text box. If so, rather than applying a class to each box, you apply text styles to the form element within the css itself, like so:
form { font-family:verdana, sans-serif; font-size:.95em; color:#666666; }CSS is NOT recommended for styling the actual form controls (not cross-browser and cross-platform friendly), but certainly fine for overall text, widths, margins, paddings, borders.
Here is an article about why the form controls are screwy, but you can pick up tips on styling parts of form elements with css.
http://www.456bereastreet.com/archive/200409/styling_form_controls/
-
I actually miss target="_blank"
-
Instead of "thin" designate 1px
-
don't worry about ie5....
LOL!
Once again ... wisdom like pearls.
-
You know, you can create rounded corners in css without using graphics. With proper border sizing and coloring, it could pretty much replicate what you have now only making your page load much leaner.
-
Actually, my argument is that I have yet to see a web site created with Expression that isn't tag soup, code heavy and table-based.
I take as much time (and pride) stream-lining my code as possible. My ultimate goal is to be as lean and tag free as possible.
So, show me a site created with EW that is clean and well coded and I will concede the point.
Editors should be tools that simply HELP you to craft a website properly ... not craft the whole thing for you based solely on how it LOOKS in a browser. How a website looks is only half of the story ... how quickly it loads, how it performs cross-browser and how search engine friendly it is takes up the other half.
-
You guys can do whatever you like, the fact that it IS a long-running debate means there are two sides to the issue. It just so happens I now am convinced by one side.
I belong to, and daily frequent, quite a few boards and blogs for professional web admins. I have been in the "so long as it validates, it is better than quirks mode and tag soup" camp for 2 years. But I found that the major players (those who right the books and have a seat on various w3c projects) have been hammering at us to change our thinking for the past 8 months or so. So I decided to stop being so stubborn and listen to what they were saying with an open mind.
I'm not following this mime serving thing. Do you declare the mime type in the document, much like the doctype?
No. The mime type is set in your server's configuration files. If you don't have server access (and are not admin authorized) to modify your server config file, then most likely it is set to serve xhtml as text/html by default.
Again, at the moment, this is all a matter of choice, and perception of what is truely "Valid". So don't panic. What got me, though, was why use xhtml trans, when, with a few tweaks here and there, you can just as easily use HTML strict?
For me, it would also not be much work to migrate xhtml to html
I started at the beginning of the week. You're right, it isn't really that hard. I can keep my lowercase tags and just remove the closing forward slash for the xhtml single closing tags. There were a few surprises, but they were minor (like not using "language=" in script headers).
-
All I can say guys, is read the links. Don't just argue without fully understanding the implications (like I always did). Read the links! I am not trying to be arbitrary ... I am trying to warn you all that you are NOT writing valid code when you use transitional and that serving XHTML 1.0 as text/html is going to bite you on the ass once xhtml 2.0 comes out and the w3c stops validating any text/html served xhtml. They made a mistake! And they now admit it! And I am just as bummed as you - once I accepted the truth.
was teh big deal of teh content type??? just set it to application/xhtml+xml - there job done. Browsers then know what they are dealing with."Internet Explorer does not support XHTML. Like other web browsers, when a document is sent as text/html, it treats the document as if it was a poorly constructed HTML document. However, when the document is sent as application/xhtml+xml, Internet Explorer won't recognize it as a webpage; instead, it will simply present the user with a download dialog. This issue still exists in Internet Explorer 7.
Although all other major web browsers, including Firefox, Opera, Safari, and Konqueror, support XHTML, the lack of support in Internet Explorer as well as major search engines and web applications makes use of it very discouraged.
Using XHTML does not encourage better support by web browsers and it is not “a vote for a better Web” if you are still supporting Internet Explorer and various search engines and other user agents which require text/html. If you serve it with the typical text/html content type, you are giving all browsers a thumbs-up to treat it exactly like classic HTML, meaning absolutely no progress is made. Even if you use only application/xhtml+xml and shut out Internet Explorer and various other user agents entirely, it won't mean anything: Microsoft already plans to support real XHTML in an upcoming release of Internet Explorer; they just want to make sure they support it correctly from the initial launch. Even still, XHTML 1.x is a dead-end standard, since it's completely incompatible with XHTML 2.0 and all other future HTML/XHTML standards, as explained aboved, and since the majority of XHTML content on the Web today cannot be safely parsed as XML."
I don't get the big fuss. XHTML 1.0 Strict was made with the intention of allowing it to be served as text/html. The W3C even have it as their primary template example - http://www.w3.org/QA/2002/04/valid-dtd-list.html - and use xhtml 1.0 strict served as text/html for their own website. In addition, when people are looking to use mootools (for example) then you need to be serving xhtml 1.0 as text/html. A lot of people doing this are fully aware of what is going on (i.e., xhtml should not ideally be served as html, and html should use an html doctype) but for the sake of practicality they are not always going to use HTML 4.01 strict. If the world ever did come to an end, converting to html 4.01 strict is simple.When the XHTML 1.0 specification was first written, there were provisions that allowed an XHTML document to be sent as text/html as long as certain compatibility guidelines were followed. The idea was to ease migration to the new format without breaking old user agents. However, these provisions are now viewed by many as a mistake. The whole point of XHTML is to be an XML alternative to HTML, yet due to the allowance of XHTML documents to be sent as text/html, most so-called XHTML documents on the Web now would break if they were treated like XML (see the real-world examples in http://www.webdevout.net/articles/beware_of_xhtml.php). Aware of the problem, the W3C had these provisions removed in the first revision of the XHTML specification. In XHTML 1.1 and onward, the W3C now clearly says that an XHTML document should not be sent as text/html. XHTML should be sent as application/xhtml+xml or one of the more elaborate XHTML content types.
-
Okay. missed the .copyright on a quick look when I couldn't find push.
I simply removed the negative margin from the footer and gave it a margin-top:10px.
That removed the extra 200px. Worked fine in FF and IE 6.
Also, you have a typo in your css: html/body has a colon missing from padding:0
-
Wartweet, you've done this before and it has driven you crazy. And it will continue to do so until you finally realize that you need to use a DOCTYPE if you want CSS to work for you.
Without a proper DOCTYPE, your web pages will NEVER look and behave the same in FF and IE.
You are creating "quirks mode" web pages.
You can't just start a web page with "<HTML>".
And since you are using xhtml style closed tags, use the xhtml DOCTYPE instead of just an <html> tag:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
Until you do, no one can help you because the css will not work properly.
-
You have elements there with no "obvious" css commands (#push, .copyright,...)
And javascript that is creating layout widths, margins, etc.
There is no way for us to help without knowing how the other hidden styling elements are affecting the layout.
-
As TM says, order is crucial. That was your whole problem. But so is proper declaration.
Once you declare a:link and a:hover, you MUST also declare a:visited and a:active. Here is the shorthand version assuming visited and active are the same as link and hover (respectively):
a:link, a:visited { color:#DCDCDC; text-decoration:none; font-size:12px } a:hover, a:active { color:#000000; text-decoration:underline }The same order, however, STILL applies even if visited and active are not the same as link and hover (respectively):
a:link{ color:#DCDCDC; text-decoration:none; font-size:12px } a:visited{ color:##DCCCCC; text-decoration:none; font-size:12px } a:hover{ color:#000000; text-decoration:underline } a:active{ color:#CCCCCC; text-decoration:underline } -
Hey,
thanks for all the help. I tried what you said, but the text from the content on the left is still overflowing :\.
???
Hmmm, I wonder if you did it right. I use an old 15" CRT monitor at 1024 x 768 resolution. And Win 2K OS.
Both Firefox and IE 6.0 handled my changes at a Window width of 918px (before the navbar menu items dropped beneath the banner).
Here are screen-shots for both:
in IE 6.0 - http://www.bluesmandeluxe.com/images/inIE2.jpg
in FF - http://www.bluesmandeluxe.com/images/inFF2.jpg
(I will remove the screenshots in a few days).
-
LOL, yeah, it feels like that.
Try this on just one of your pages.
Change your DOCTYPE to HTML Strict. Go ahead and remove the xhtml style closed meta tags, images and breaks.
Then go to the validation tool. It should validate. This would prove that your xhtml was basically just html (with a few strange tags). It is not xhtml because it is not parsing an xml file, it is not behaving as xhtml should ... it is behaving as html.
It isn't a matter of good or bad, it is a matter of intent. The correct language for using a text/html mime-type is ... html. Period.
The correct use of XHTML is when it is using the application/xhtml+xm mime-type.
Here is how I can put it into perspective:
If you create a web page using html and save it with a php extension, is it an actual php page?
No, it is an html page with a php extension that displays html. The php extension doesn't REQUIRE actual php code present to display as html.
It WOULD be an actual php page if it included server-side php code that output html based upon php commands it was given in the code. However, if you saved the php page, with the php code included, as an html extension, what would happen? BOOM! Garbage.
-
The key to the whole thing is in the mime type.
If you are serving xhtml as a "text/html" mime type (weather you use Strict or Transitional DTD), then you are, in essence, serving up the page as HTML!
XHTML is NOT, nor was it ever meant to be, an HTML replacement.
XHTML was meant, and is valid in strict mode, as an application in order to display the results of an XML file. As such it is MEANT to use the "application/xhtml+xml" mime-type and NOT "text/html".
So, using XHTML as an html replacement is meaningless because it is merely being served as HTML with strange closing tags. But make no mistake ... it IS being served as HTML and NOT XHTML.
There is no argument there ... it is simply a fact.
AND, I believe XHTML 2.0 will no longer be backwards compatible with the text/html mime type anyway. So there is no point in using xhtml transitional, because it is NOT XHTML, it is HTML with funny tags allowed.
What it comes down to, for me anyway, is that it took me a long time to convert my old tag soup quirks mode html to what I thought was Valid code. Yet using the Transitional DTD for XHTML or HTML was an exercise in futility.
Because VALID HTML 4.0 will only validate using the Strict DTD.
-
Not that I've ever come across (unless it tiles seamlessly, of course)
That may be what he is looking for, guys.
If you have a graphic that can seamlessly tile, then, YES, it can be a 100% screen width (and height) background.
For instance, here is an image I use:
Here is how I use it:
-
Ah Ha! Not four days ago I would have made the same argument, guys. This debate has been going on for a while now, and I always firmly stood in the "if it validates, it is valid for that DTD!" camp.
I would have posted a blistering response to my post and the logic would have seemed so indisputable that you would have joined me in signing my praise for "killing this "poser"".
But I (and you) was wrong. And it is something you are going to have to face, as I did (kicking and screaming). You will eventually HAVE to acknowledge it as true (even if you don't think so now). I can be as stubborn as the next guy, but when actually proven that am wrong, however distasteful, I have to give in.
Transitional DTD does NOT make valid html or xhtml. It validates the code based upon it being a transition to PROPER, VALID HTML or XHTML.
Here are a few links that were rammed down my throat during a heating argument in another forum for web standard coding professionals (which FORCED me to acknowledge, however distasteful it always is, that I was wrong and they were right):
Best references on that issue, READ THEM TO OPEN YOUR EYES, are:
XHTML's Dirty Little Secret by Mark Pilgrim
http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
Beware of XHTML
http://www.webdevout.net/articles/beware_of_xhtml.php
is also a very complete document on the issue.
It even lists quotes from Browser Manufacturers:
"Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support."
Mozilla Web Developer FAQ
http://www.mozilla.org/docs/web-developer/faq.html#accept
Safari Developer FAQ
http://developer.apple.com/internet/safari/faq.html#anchor13
"On today's web, the best thing to do is to make your document HTML4 all the way. Full XHTML processing is not an option, so the best choice is to stick consistently with HTML4."
Safari developer Maciej Stachowiak
"I don't think XHTML is a realistic option for the masses. HTML5 is it."
Håkon Wium Lie, CTO of Opera
http://www.heise.de/ct/Redaktion/heb/w3c/lie_english.html
etc...
http://www.webdevout.net/articles/beware-of-xhtml#quotes
No to XHTML
http://www.spartanicus.utvinternet.ie/no-xhtml.htm
which explains the misconceptions, exaggerations regarding XHTML. This is the best document on this issue.
XHTML is dead by Tommy Olsson
http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead
XHTML - What's the point? by Henri Sivonen
http://hsivonen.iki.fi/xhtml-the-point/
XHTML is not for Beginners by Lachlan Hunt
-
Looking at the code and the css, I found a few flaws that will make this layout blow up as written.
First, as I mentioned before, ALWAYS check your markup for errors BEFORE blaming the css.
You left out a ul tag for div id"menu".
If you use a certain DOCTYPE, but use invalid code for that DOCTYPE you can never be certain how it will behave. IE, for sure, will toss it into quirks mode.
You are using the xhtml Strict DTD! But, your are then causing all kinds of problems with the markup because it is "invalid" xhtml strict. All images require an "alt" tag Even if you change it to Transitional (which you should), you have some cleanup to do (like closing your img tags!), using proper characters for quotes, ampersands, etc:
change " to "
Second, after checking the html markup, and before modifying any css elements, check for errors in your css (typos, parse problems, etc.). If you have css errors, tweaking elements will not solve problems.
Your css has a few parse errors for IE (because of the hacks - which could be done with conditional comments instead, but can remain for validation purposes and will not affect the css elements); there is no color value "lightyellow", use the proper color code (in your case #FFFF99).
Okay. now that the markup and css is fixed, you can look at the actual elements for fixing. As an aside, the fixes I made will work beautifully in IE (I tested in 6.0) and FF, as the screen is narrowed.
As I thought, your layout will not work as written. You have to use percentages for the content_half and content_right and make them both float left and lose those right margins (content_half needs a 30px or so right margin, but you can play with that to taste). Change the four css elements as following
#header { height: 82px; background: #CCC url(http://gamebulge.com/img/img01.gif) repeat-x; margin: 0px; width:100% } #menu ul { margin: 0; padding: 0; list-style: none; } #content_half { float:left; border: 2px solid #f6e88c; text-align: left; background: #FFF url(http://gamebulge.com/img/img05.gif) repeat-x top; padding: 5px; width: 60%; } #content_right { float: left; width: 30%; border: 2px solid #CCC; background: #FFF; text-align: left; padding: 5px; margin-left:30px }Now, go back to your markup and cut and paste the entire <div id="content_right"> code to be AFTER the
<div id="content_half"> code (@ line 277 or where it shows </table></div>)
You are floating left two IDs so they need to be in the proper order within the markup for which you want to be left, first in order, then right, second in order.
And that's it.
Works like a charm now.
I do suggest that you lose the xhtml DOCTYPE altogether and change it to HTML 4.0 Strict. Then go to the w3c validation tool and fix the markup errors to make it valid html 4.0 Strict (shouldn't be too many).
I'll take the Five bucks in cash, please
Are you REALLY using valid code, or just getting "validated"?
in CSS Help
Posted
As usual, good points, TM. Yeah, accessibility ... it IS as important as standards, and as soon as my main site is converted I need to make it 100% accessible.
And, like I said, I "miss" target=_blank, but realize that valid code is much more important.
That says it all in a nutshell. Even though we may sometimes disagree with the standards rules, we should defer to them; better minds than ours worried over them long and hard enough.
Which, LOL, brings me back to the xhtml/html debate.
Once one concedes that xhtml was initially conceived to be served as application/xhtml+xml and only "permitted" to be served as text/html (consequently when served as text/html really only makes it actually HTML with strange some strange tags), then one has to accept that the HTML Strict doctype is the ONLY valid standard for serving text/html web pages.
Using transitional doctypes for ANY new web page is lazy and wrong. It means you are NOT coding to the actual valid version of the code right out of the gate. It means are starting your page/site actually using old, deprecated, no longer valid tags, previously permitted but no longer proper syntax and basically a mishmash of previous versions.
Transitional doctypes are totally abused and not being implemented as intended. They were NEVER intended as an initial page doctype; they were intended for the poor suckers like me, who have thousands of pages of a LIVE website to revise that could take up to a year to complete. By using transitional doctypes, I was able to convert my quirks mode pages quickly and serve a transitionally valid website within a month or two, while working on the true revisions of the pages.
prime, converting your valid xhtml pages to html strict is much easier than you may think due to the "optional" nature of html 4.01 ... upper/lowercase tags or closing/not closing block level tags are equally valid. So the main things I had to change were simply single closing tags - like img, br or meta and remove "language" from my script tags.
I was able to convert all of my xhtml to html strict within a few days.
Dave