Post by cajones on May 15, 2008 21:34:23 GMT -5
So I make it no secret that I have yet to see the value in CSS... and I want to rebuild my website to not suck... so I googled "CSS is stupid". Found the complete opposite: "why tables are stupid and css is good".
Ok, so it's in multiple, really really short pages that don't tell me much. I've only found the list of problems with tables... let's go over them...
Nah, the last one just made me feel like casting judgment. Because apparently I like doing that, as though I have any reason to think highly enough of myself to ... umm... finish this sentence...
And I'm wondering... are spacer gifs ... there to make sure that empty cells are the right size? Somehow that seems... ... like it shouldn't be necessary... when you could just define the width (which you can?) and keep the heights fixed to the biggest cell.
-_- *eats web design*
... and in fact, tables are more accessible when it comes to telling where things are on the page, because it's possible to navigate by rows and collumns and such... other layout styles don't leave the slightest clue as to where anything is positioned.
And... ... what does CSS do? Like... I've seen color, maybe position, width, height, marjins, font stuffs... but that doesn't actually make editing a whole site less labor intensive at all (say, if you change a menu by adding or removing items or something).
... Blah, clearly I'm either missing something, or web standards aren't supposed to make sense. (I don't like xhtml.).
Spacers are in fact annoying to navigate with screen readers (If someone actually puts alt tags in spacers... which... people do...). Navigating table cells has never been a problem... if there's content there, it doesn't matter how you lay it out, it'll still take wading to get to it--in fact, tables are the quickest way to get to content that's in tables.
For instance...
Let's look at a forum post system that uses a two-collumn table for posts. The left collumn contains user information (avatars, names, profile stuff, Etc), and the right contains post content.
If this is put in a table, a screen reader can recognize this and, instead of moving through it all linearly (going across each cell sequencially), can navigate by cell or row or collumn or whatever... so instead of having to scroll through all kinds of extra text to get to a specific post, or past profile information, or whatever, I can just hold down a couple extra keys and skip all of that junk.
(I'll also note that Jaws+IE+uneven tables+ctrl+alt leads to glitches that I've dubbed the eraser demon, since... I don't know exactly why (I think I hit the bottom of an uneven table or something and keep trying to move...)... but it locks alt in a limited capacity, and usually strikes while looking at message boards... so when I try to backspace in a post with the eraser demon on, it erases the whole thing rather than the previous character (annoying!). And pushing the left arrow key sends a "back" command to the browser... huh?).
Ahem...
But that two-collumn post format. If that was visually the same, but presented without tables, a screenreader wouldn't know, and _then_ it'd be necessary to wade through all of that mess to find specific things.
What I think this little "Tables suck; CSS rules!" powerpoint did was pick an issue that made sense to them (screenreaders Vs tables) and ... didn't bother researching it thoroughly, because it was just a selling point that was directed at web designers anyway (and how many web designers are visually impaired, anyway? Oh wait... *looks in a mirror, then remembers the visually impaired part*).
1: accessiblity sounds funny. (Hint: there's an i missing.)
2: This has nothing to do with accessibility.
This does, though.
... I'm not even sure what this "summary" is supposed to mean. I think they're trying to prove that tables suck... by throwing together a hodgepodge of languages that I'm too lazy to try and make sense of and somehow that is the table's fault...
Ok, next page is way more intelligent.
You know... my tables are usually like, four cells...
... That's it, I just don't understand web design at all.
True enough. (Though there's not a single alt tag... oh, well, I guess that's more toward an even 14 k...).
Oooh, I'm soooo scared of validation that I don't have to use to run a website...
... So sue me, document.write is way more convenient than document.getElementByTagName("body").elements[Math.random()*document.getElementByTagName("body").elements.length].innerHtml.append("stuff", null, false);
Ok, so I never actually learned the alternate method because it's that messy...
... Why the crap was my computer running on battery despite being plugged in long enough to get a low battery alert?
Agreed... a bulleted list is like... a feature of html... If you need it positioned that precisely... _then_ CSS starts making sense. ... But not with stylesheets. That's overcomplicating things. Just... <div style="position:absolute(or relative, whatever); top:y; left:x;"> list </div>
... As opposed to using multiple files (or moving between various places in one file, which can be even more annoying) and... oh, what's this? Using more characters? (Style atributes ... hmm... shorter than rewriting the name of an element and putting braces around it, perhaps multiple times... but hey, maybe I'm just a n00b.).
I see your accessibility complaints now...
... I have no idea what the crap you're talking about!
Apparently all this complex table stuff is really weird... positioning... or fonts... or... something stupid and pointless that doesn't add to the content at all.
... I am seriously lost as to what the point of super-complex tables is. Forget CSS... why do things need to be so freaking complicated?
"Just mark up your bulleted lists as bulleted lists and let CSS do the rest."
... What rest? There is no the rest that concerns me... sudden changes in marjin? Padding? ... Margerin? Font? Line size? What am I missing?
(Are we trying to make our web pages look like powerpoint presentations? Ur... powerpoint 97's webpage wizard is more efficient than 2000... 'course, the resolution on images is rather crappy... and pretty much why I didn't scale the hotspots in my homepage links correctly...).
"You need a rule for <table>, one for <td>, one for <ul> and one for <li>."
Hehehehe. I still don't even know what <ul> does. I do know, however, that I'm not wasting my time by making special rules for all of those when I'm either using only one per page, or multiples (where multiples would probably look different, anyway... If I'm using multiple tables, they're not supposed to look the same. Lists... maybe... I could see scenarios for a global rule and for individual formats... Except that I'm not really concerned with formats at all beyond "You can read it? It gets the point across? It's appropriately emphasized to get the role of the element across? Ok.").
"That's better than using 8 more table cells to make a fake bulleted list, which ends up being much less accessible."
... You know, your "more accessible" version still isn't showing up as a list that I can shortcut to. Not like I would have... but there are several cases (Like jumping to a list of days on a lunch menu) where Jaws' special "hold the keyboard too long after leaving the browser so we can't type right" shortcuts come in handy... your "more accessible" list doesn't ... ur... Let's start over.
I can press 'l' with jaws 5 and higher to jump to a list in a webpage. None of the lists on this example--including the "more accessible" one--register as lists, so I couldn't jump to either of those. (If I wanted to, though, I'd just press 't' to go to the next table... which would be more annoying if there were several tables to move through, but still...).
Forgetting for a moment the fact that the presence of four colors in the last tag confuses me...
Over embellishment. Does all of that make it prettier, somehow? Oh wait...
... Yeah, so I like shapes to be defined by... shapes, not an outline of the shape...
So borders... meh. Except for rare specific instances where you're imitating a specific style of something...
"CSS layouts: the future is here"
Oh really? Let's see:
... That's not layout. That's decoration. Line height, margins, and background color do not qualify as a layout. The only thing in there that looks like it might be layout related is that float thing... but I don't even care what that actually does.
In fact, their example of a better, css-based layout is... a table. A table that is _still_ bigger than the cheap ol' tables I use... because my content is usually simple and the idea of separating it into multiple collumns is just bizarre to me (if a screen is only about a page of size, why pretend it's two pages? But books do that sometimes... huh? I'm confused... *kicks unnecessary collumn layouts*).
Ahem. Back to my tirade.
"Rather than thinking about things like "this goes here and this goes here" while we are working on a page or a layout, we need to think about the kinds
of information in our page and the structure of that information."
That makes... not sense...
"We give the most important headline an <h1> tag; subheads get marked up with <h2> tags, etc.; and paragraphs are paragraphs."
What about that qualifies as CSS? That looks like regular ol' html to me.
"Instead of putting your content inside of tables and table cells, wrap it in div elements. Give your div elements an id or a class that is descriptive of
their content and/or function, rather than their appearance."
Ah, now, this is where we have problems. (Never mind the fact that such is what I plan to do mostly if I redesign...).
Div elements... I think of these as placeholders that... can overlap. I have little in the way of ...
Now, divs are controlled by css. But each layer is different; do we make a big stylesheet that has the properties of each div (Meaning we label each one)? If we're reusing them across the website, then I see the point... sort of. (Mainly for figuring out what the crap is going on with all of that other junk I listed...).
In the end, I'm pretty much screwed and can't do anything on my own and should just kill myself to make the world lighter. (Unfortunately enough, I'm not suicidal, so nya, put up with it.
. ).
"Think about why you want something to appear a certain way; what does it mean? Your markup can and should convey meaning, even to someone who cannot see
your page. Semantic markup makes our pages more accessible to everyone, including search engines."
... *snicker*. No, I've... ... never seen a web page where all the markup and stuff means anything.
(Please type the numbers in the image... *shotgun* I'll type your numbers, bi--)
"When you italize something, is that because you want to emphasize it, <em>, or because it's the title of a book, <cite>?"
... You know, jaws doesn't tell me when something is italicized, bolded, or any of that crap, unless I explicitly put my cursor over every piece of text and ask. (I don't do that. There's absolutely no point in 99.9% of cases.).
... Jaws does, however, pronounce words that are missing a whole syllible in such a way that you might notice it. "italize" indeed...
"If something is bold, it should probably be marked up as <strong>."
Yeah, that makes no sense.
"If you want a linebreak after something, chances are it should be marked up as a header element. If it's not a header, is it part of a class that occurs
throughout your site? If that's the case then use CSS instead of <br>."
I'm pretty sure none of that makes any sense to someone who just wants to make a website about stuff rather than the most amazing spectacular... what the heck are you even talking about? Linebreak? linebreaks? (There, I used strong..). What's so deadly about linebreaks that you have to throw in CSS all over the place? Umm... don't line breaks... you know... separate lines? Am I missing something, here? (Oh, that one's obvious...)
".foo {display:block}"
Unless that was a Mister T reference, I don't see the point... or... what it does, really. ... the foo layer displays a block? Wow, that... totally... wouldn't happen otherwise... :?
"What are nav bars?"
... You talk about all this fancy eyecandy and coding, and decide a good way to open a slide for the same audience is with this question? I hope you're shooting for amazing insight...
"Think about it: your navigation is actually an unordered list of links."
Oh, is that what <ul> means?
"By using display:inline we can create horizontal nav bars."
That's actually useful. Yay!
But just for you, I'll paste exactly what I get from the list section in jaws.
Well, they're recognized as lists, at least............... identical lists...........
(You know, while we're here... what does the <code> tag even do?)
(... I'll be commenting, I think...)
I just saw what display: block means. Though... that actually... doesn't make a lot of sense, if you really think about it (read: really think about it having only read this page).
And for the road... what is this?
"Analyze your table structure for nested tables and empty spacer and border cells. (We want to replace these with div tags or with a much simpler table structure.)"
Why? Why empty cells? I don't get it at all...
(Ok, so I do use empty cells... in the css/js button villages.. maybe this is one?)
"• For the love of all that is pure and good, get rid of <font> tags and spacer GIFs!"
Spacer GIFs... ok. Font? Umm, 'xcuse me... I don't think it'd be inconceivable to imagine a situation where CSS couldn't handle the sort of font changes that one might want...
"• Likewise, lose the <b> and <br> markup."
... No.
"• Get rid of presentational markup for tables (bgcolor, background, and the like)."
Only in tables that are part of the style of multiple pages. Otherwise, cssing those away would be pointless.
"• Replace purely presentational CSS coding (things like <span class="header">) with appropriate structural markup."
Good. Please, <span> reaks of "Look at me, I'm microsoft!".
"Think about the structure of your document! Merely replacing <b> tags with <strong> tags is not enough."
Start making sense, and quickly.
"What is the most important header? Mark it up with an <h1> tag. Mark your subheads with <h2> tags and so on. Mark up paragraphs with <p> tags. Mark up your
navigation as unordered lists."
Done, done, and done... a long time ago. Point?
"Choose a DOCTYPE and use it. (We recommend XHTML transitional, unless you're hard core, in which case, go for it and use XHTML strict.)"
... Who cares about doctypes? Since when is java simpler than "valid" html, anyway? -.-.
"Divide your page into logical divs"
Umm... you realize I'm not likely to throw out all sorts of font adventures, right?
"Put your main navigation into a div with an id of mainnav; put your subnav inside a div with an id or class of subnav, put your footer in a <div id="footer">,
and wrap your content inside a <div id="content">."
... What if I don't want to?
(... I'll probably need to do exactly that, though.... )
"It doesn't look like much now, but once you start adding rules to your style sheets, things will get better quickly."
If by that you mean "I don't have to scroll so much when selecting what to replace when I copy and paste my first page to reuse the layout", then...
(So, what I'm getting from this is... CSS actually doesn't help eliminate the labor intensiveness of site-wide modifications at all. Oh, wonderful.)
"At the begining, give each div a border. For example, div {border: 1px dotted gray; padding: .5em} This will help you see where they begin and end, and
also whether or not you have any nesting going on."
Umm... it didn't help you see that you left an 'n' out of "beginning". (Jaws is particularly confused by that one... "beh-jeaning"?).
Speaking of jaws... what's this nonsense about useless "I neither see them nor want to" border crap?
"Write your CSS for element selectors first (<html>, <body>, <p>, <h1>, <h2>, <ul>, <li>, etc.)"
Assuming, of course, we even need css for all of those.
I actually did try to use an external stylesheet when I built the current version of my website. ... And it's only on like one page... because all it does is define things that I could easily have defined in the body tag (bgcolor, text, link, vlink, alink...). And really, what else am I going to do with this sort of junk?
Oh, right. Layers. And... stuff.
(*cough*CSSstillisn'tworkingwithlayouts!)
"Use contextual or descendant selectors as much as possible. This will keep your markup much cleaner. For example, #subnav li {border: 1px solid black; padding:
.5em; display: inline} will only affect list items that occur within your subnav div."
I have no idea how your example has anything to do with your first statement.
"Test in as many browsers as you can and get your friends to test it in their browsers."
Or rather, "Get your friends to test it in their browsers while you do nothing of consequence because all of this eyecandy doesn't do much for eyes without teeth".
"Examples of sites that use CSS"
Oh, that's it... I'm out of here...
... I hate the internet.
Ok, so it's in multiple, really really short pages that don't tell me much. I've only found the list of problems with tables... let's go over them...
- mixes presentational data in with your content. <-- I guess this means reloading pictures? Which is a valid complaint.
- This makes the file sizes of your pages unnecessarily large, as users must download this presentational data for each page they visit.
- Bandwidth ain't free. <--I still don't see why.
- This makes redesigns of existing sites and content extremely labor intensive (and expensive). <-- True enough, as that's the problem I'm currently facing...
- It also makes it extremely hard (and expensive) to maintain visual consistency throughout a site. <-- Hmm... Hehehehe...
- Table-based pages are also much less accessible to users with disabilities and viewers using cell phones and PDAs to access the Web. <-- simply not true. I like viewing pages with tables. Not "more difficult" in the slightest.
Nah, the last one just made me feel like casting judgment. Because apparently I like doing that, as though I have any reason to think highly enough of myself to ... umm... finish this sentence...
And I'm wondering... are spacer gifs ... there to make sure that empty cells are the right size? Somehow that seems... ... like it shouldn't be necessary... when you could just define the width (which you can?) and keep the heights fixed to the biggest cell.
-_- *eats web design*
... and in fact, tables are more accessible when it comes to telling where things are on the page, because it's possible to navigate by rows and collumns and such... other layout styles don't leave the slightest clue as to where anything is positioned.
And... ... what does CSS do? Like... I've seen color, maybe position, width, height, marjins, font stuffs... but that doesn't actually make editing a whole site less labor intensive at all (say, if you change a menu by adding or removing items or something).
... Blah, clearly I'm either missing something, or web standards aren't supposed to make sense. (I don't like xhtml.).
Visitors using screen readers (as well as those with slow connections) do not have to wade through countless table cells and spacers to get at the actual
content of our pages.
Spacers are in fact annoying to navigate with screen readers (If someone actually puts alt tags in spacers... which... people do...). Navigating table cells has never been a problem... if there's content there, it doesn't matter how you lay it out, it'll still take wading to get to it--in fact, tables are the quickest way to get to content that's in tables.
For instance...
Let's look at a forum post system that uses a two-collumn table for posts. The left collumn contains user information (avatars, names, profile stuff, Etc), and the right contains post content.
If this is put in a table, a screen reader can recognize this and, instead of moving through it all linearly (going across each cell sequencially), can navigate by cell or row or collumn or whatever... so instead of having to scroll through all kinds of extra text to get to a specific post, or past profile information, or whatever, I can just hold down a couple extra keys and skip all of that junk.
(I'll also note that Jaws+IE+uneven tables+ctrl+alt leads to glitches that I've dubbed the eraser demon, since... I don't know exactly why (I think I hit the bottom of an uneven table or something and keep trying to move...)... but it locks alt in a limited capacity, and usually strikes while looking at message boards... so when I try to backspace in a post with the eraser demon on, it erases the whole thing rather than the previous character (annoying!). And pushing the left arrow key sends a "back" command to the browser... huh?).
Ahem...
But that two-collumn post format. If that was visually the same, but presented without tables, a screenreader wouldn't know, and _then_ it'd be necessary to wade through all of that mess to find specific things.
What I think this little "Tables suck; CSS rules!" powerpoint did was pick an issue that made sense to them (screenreaders Vs tables) and ... didn't bother researching it thoroughly, because it was just a selling point that was directed at web designers anyway (and how many web designers are visually impaired, anyway? Oh wait... *looks in a mirror, then remembers the visually impaired part*).
Speaking of accessiblity, minimizing your markup and using header tags properly will also help improve your search engine ranking.
1: accessiblity sounds funny. (Hint: there's an i missing.)
2: This has nothing to do with accessibility.
Reducing the ratio of code to content, using keywords in your header tags, and replacing header GIFs with actual text will all help your sites get better
search engine results.
This does, though.
... I'm not even sure what this "summary" is supposed to mean. I think they're trying to prove that tables suck... by throwing together a hodgepodge of languages that I'm too lazy to try and make sense of and somehow that is the table's fault...
Ok, next page is way more intelligent.
Guess how much markup there is in this little table? 13.7k. There are 17 rows and 9 columns in this thing. And did I mention all of the spacer GIFs?
You know... my tables are usually like, four cells...
... That's it, I just don't understand web design at all.
There are way too many table cells and spacers in here.
True enough. (Though there's not a single alt tag... oh, well, I guess that's more toward an even 14 k...).
And all of the dotted borders are done with a background attribute on table cells, which won't validate.
Oooh, I'm soooo scared of validation that I don't have to use to run a website...
... So sue me, document.write is way more convenient than document.getElementByTagName("body").elements[Math.random()*document.getElementByTagName("body").elements.length].innerHtml.append("stuff", null, false);
Ok, so I never actually learned the alternate method because it's that messy...
... Why the crap was my computer running on battery despite being plugged in long enough to get a low battery alert?
•
A nested table? What for?
•
To make a bulleted list? You're kidding, right?
Agreed... a bulleted list is like... a feature of html... If you need it positioned that precisely... _then_ CSS starts making sense. ... But not with stylesheets. That's overcomplicating things. Just... <div style="position:absolute(or relative, whatever); top:y; left:x;"> list </div>
... As opposed to using multiple files (or moving between various places in one file, which can be even more annoying) and... oh, what's this? Using more characters? (Style atributes ... hmm... shorter than rewriting the name of an element and putting braces around it, perhaps multiple times... but hey, maybe I'm just a n00b.).
This could all be done with 8 table cells and 4 CSS rules.
Seriously. 8 cells and 4 css rules, that's all it takes.
I see your accessibility complaints now...
... I have no idea what the crap you're talking about!
Apparently all this complex table stuff is really weird... positioning... or fonts... or... something stupid and pointless that doesn't add to the content at all.
... I am seriously lost as to what the point of super-complex tables is. Forget CSS... why do things need to be so freaking complicated?
"Just mark up your bulleted lists as bulleted lists and let CSS do the rest."
... What rest? There is no the rest that concerns me... sudden changes in marjin? Padding? ... Margerin? Font? Line size? What am I missing?
(Are we trying to make our web pages look like powerpoint presentations? Ur... powerpoint 97's webpage wizard is more efficient than 2000... 'course, the resolution on images is rather crappy... and pretty much why I didn't scale the hotspots in my homepage links correctly...).
"You need a rule for <table>, one for <td>, one for <ul> and one for <li>."
Hehehehe. I still don't even know what <ul> does. I do know, however, that I'm not wasting my time by making special rules for all of those when I'm either using only one per page, or multiples (where multiples would probably look different, anyway... If I'm using multiple tables, they're not supposed to look the same. Lists... maybe... I could see scenarios for a global rule and for individual formats... Except that I'm not really concerned with formats at all beyond "You can read it? It gets the point across? It's appropriately emphasized to get the role of the element across? Ok.").
"That's better than using 8 more table cells to make a fake bulleted list, which ends up being much less accessible."
... You know, your "more accessible" version still isn't showing up as a list that I can shortcut to. Not like I would have... but there are several cases (Like jumping to a list of days on a lunch menu) where Jaws' special "hold the keyboard too long after leaving the browser so we can't type right" shortcuts come in handy... your "more accessible" list doesn't ... ur... Let's start over.
I can press 'l' with jaws 5 and higher to jump to a list in a webpage. None of the lists on this example--including the "more accessible" one--register as lists, so I couldn't jump to either of those. (If I wanted to, though, I'd just press 't' to go to the next table... which would be more annoying if there were several tables to move through, but still...).
The code that shows the table structure:
table { margin: 3px; padding: 2px; border: solid 2px blue }
td { padding: 2px; border-style: solid; border-width: 1px; border-color: gray gray silver silver }
Forgetting for a moment the fact that the presence of four colors in the last tag confuses me...
Over embellishment. Does all of that make it prettier, somehow? Oh wait...
... Yeah, so I like shapes to be defined by... shapes, not an outline of the shape...
So borders... meh. Except for rare specific instances where you're imitating a specific style of something...
"CSS layouts: the future is here"
Oh really? Let's see:
body {margin:0; padding:0}
.related {float:right; width: 15em; margin-left:1em; margin-bottom: 1em; color:blue}
#footer {color: gray; font-size: 0.6em; line-height: 1.2em; background-color: white; margin: 0}
... That's not layout. That's decoration. Line height, margins, and background color do not qualify as a layout. The only thing in there that looks like it might be layout related is that float thing... but I don't even care what that actually does.
In fact, their example of a better, css-based layout is... a table. A table that is _still_ bigger than the cheap ol' tables I use... because my content is usually simple and the idea of separating it into multiple collumns is just bizarre to me (if a screen is only about a page of size, why pretend it's two pages? But books do that sometimes... huh? I'm confused... *kicks unnecessary collumn layouts*).
Ahem. Back to my tirade.
"Rather than thinking about things like "this goes here and this goes here" while we are working on a page or a layout, we need to think about the kinds
of information in our page and the structure of that information."
That makes... not sense...
"We give the most important headline an <h1> tag; subheads get marked up with <h2> tags, etc.; and paragraphs are paragraphs."
What about that qualifies as CSS? That looks like regular ol' html to me.
"Instead of putting your content inside of tables and table cells, wrap it in div elements. Give your div elements an id or a class that is descriptive of
their content and/or function, rather than their appearance."
Ah, now, this is where we have problems. (Never mind the fact that such is what I plan to do mostly if I redesign...).
Div elements... I think of these as placeholders that... can overlap. I have little in the way of ...
- Being able to tell how wide a line of text will be.
- putting the hp sticker back on the laptop that my hand somehow just flipped to the side of the computer opposite the direction of impact...
- Knowing how much virtical space a block of text (or whatever other content is involved) will take up.
- Knowing how the div will treat overflow, scrolling, Etc...
- Keeping track of how to control these when I find them... because I'm more worried about things other than how div layers work.
Now, divs are controlled by css. But each layer is different; do we make a big stylesheet that has the properties of each div (Meaning we label each one)? If we're reusing them across the website, then I see the point... sort of. (Mainly for figuring out what the crap is going on with all of that other junk I listed...).
In the end, I'm pretty much screwed and can't do anything on my own and should just kill myself to make the world lighter. (Unfortunately enough, I'm not suicidal, so nya, put up with it.
. )."Think about why you want something to appear a certain way; what does it mean? Your markup can and should convey meaning, even to someone who cannot see
your page. Semantic markup makes our pages more accessible to everyone, including search engines."
... *snicker*. No, I've... ... never seen a web page where all the markup and stuff means anything.
(Please type the numbers in the image... *shotgun* I'll type your numbers, bi--)
"When you italize something, is that because you want to emphasize it, <em>, or because it's the title of a book, <cite>?"
... You know, jaws doesn't tell me when something is italicized, bolded, or any of that crap, unless I explicitly put my cursor over every piece of text and ask. (I don't do that. There's absolutely no point in 99.9% of cases.).
... Jaws does, however, pronounce words that are missing a whole syllible in such a way that you might notice it. "italize" indeed...
"If something is bold, it should probably be marked up as <strong>."
Yeah, that makes no sense.
"If you want a linebreak after something, chances are it should be marked up as a header element. If it's not a header, is it part of a class that occurs
throughout your site? If that's the case then use CSS instead of <br>."
I'm pretty sure none of that makes any sense to someone who just wants to make a website about stuff rather than the most amazing spectacular... what the heck are you even talking about? Linebreak? linebreaks? (There, I used strong.
.). What's so deadly about linebreaks that you have to throw in CSS all over the place? Umm... don't line breaks... you know... separate lines? Am I missing something, here? (Oh, that one's obvious...)".foo {display:block}"
Unless that was a Mister T reference, I don't see the point... or... what it does, really. ... the foo layer displays a block? Wow, that... totally... wouldn't happen otherwise... :?
"What are nav bars?"
... You talk about all this fancy eyecandy and coding, and decide a good way to open a slide for the same audience is with this question? I hope you're shooting for amazing insight...
"Think about it: your navigation is actually an unordered list of links."
Oh, is that what <ul> means?
"By using display:inline we can create horizontal nav bars."
That's actually useful. Yay!
But just for you, I'll paste exactly what I get from the list section in jaws.
Think about it: your navigation is actually an unordered list of links.
Mark them up inside <ul> tags.
List of 5 items
• link1
• link2
• link3
• link4
• link5
list end
Horizontal Nav bars
We can use CSS to control how these lists are displayed on our pages.
By using display:inline we can create horizontal nav bars.
List of 5 items
link1
link2
link3
link4
link5
list end
Well, they're recognized as lists, at least............... identical lists...........
(You know, while we're here... what does the <code> tag even do?)
(... I'll be commenting, I think...)
Here's the code used for this nav bar:
#nav1{
margin-top: 1em; <--em? What unit is this?
margin-bottom: 0.5em;
}
#nav1 ul {<--I'm assuming nav1 is some manner of layer ID, and we're defining styles for its ul elements.
background-color: silver; <--Eerily significant...
text-align: center;
margin-left: 0; <--Oooh, a whole line to say "nope, no margin..."
padding-left: 0;
border-bottom: 1px solid gray <-- isn't 1px really small? That's the sort of thing that means nothing to me.
}
#nav1 li { <--Umm... So... li goes inside ul, right? Hehehehe... yeah... I... never bothered studying this part. (that would imply I had a reason, which... no.)
list-style-type: none; <-- Huh? What's this... numbering or something?
padding: 0.25em 1em; <-- Again with the 'em'. Ok, pad the list items, then.
border-left: 1px solid white; <-- Yawn.
display: inline <-- Unyawn.
}
#nav1 li:first-child {<--Now I'm losing patience.
border: none;
}<-- that's it? >.<...
I just saw what display: block means. Though... that actually... doesn't make a lot of sense, if you really think about it (read: really think about it having only read this page).
And for the road... what is this?
"Analyze your table structure for nested tables and empty spacer and border cells. (We want to replace these with div tags or with a much simpler table structure.)"
Why? Why empty cells? I don't get it at all...
(Ok, so I do use empty cells... in the css/js button villages.
. maybe this is one?)"• For the love of all that is pure and good, get rid of <font> tags and spacer GIFs!"
Spacer GIFs... ok. Font? Umm, 'xcuse me... I don't think it'd be inconceivable to imagine a situation where CSS couldn't handle the sort of font changes that one might want...
"• Likewise, lose the <b> and <br> markup."
... No.
"• Get rid of presentational markup for tables (bgcolor, background, and the like)."
Only in tables that are part of the style of multiple pages. Otherwise, cssing those away would be pointless.
"• Replace purely presentational CSS coding (things like <span class="header">) with appropriate structural markup."
Good. Please, <span> reaks of "Look at me, I'm microsoft!".
"Think about the structure of your document! Merely replacing <b> tags with <strong> tags is not enough."
Start making sense, and quickly.
"What is the most important header? Mark it up with an <h1> tag. Mark your subheads with <h2> tags and so on. Mark up paragraphs with <p> tags. Mark up your
navigation as unordered lists."
Done, done, and done... a long time ago. Point?
"Choose a DOCTYPE and use it. (We recommend XHTML transitional, unless you're hard core, in which case, go for it and use XHTML strict.)"
... Who cares about doctypes? Since when is java simpler than "valid" html, anyway? -.-.
"Divide your page into logical divs"
Umm... you realize I'm not likely to throw out all sorts of font adventures, right?
"Put your main navigation into a div with an id of mainnav; put your subnav inside a div with an id or class of subnav, put your footer in a <div id="footer">,
and wrap your content inside a <div id="content">."
... What if I don't want to?
(... I'll probably need to do exactly that, though...
. )"It doesn't look like much now, but once you start adding rules to your style sheets, things will get better quickly."
If by that you mean "I don't have to scroll so much when selecting what to replace when I copy and paste my first page to reuse the layout", then...
(So, what I'm getting from this is... CSS actually doesn't help eliminate the labor intensiveness of site-wide modifications at all. Oh, wonderful.)
"At the begining, give each div a border. For example, div {border: 1px dotted gray; padding: .5em} This will help you see where they begin and end, and
also whether or not you have any nesting going on."
Umm... it didn't help you see that you left an 'n' out of "beginning". (Jaws is particularly confused by that one... "beh-jeaning"?).
Speaking of jaws... what's this nonsense about useless "I neither see them nor want to" border crap?
"Write your CSS for element selectors first (<html>, <body>, <p>, <h1>, <h2>, <ul>, <li>, etc.)"
Assuming, of course, we even need css for all of those.
I actually did try to use an external stylesheet when I built the current version of my website. ... And it's only on like one page... because all it does is define things that I could easily have defined in the body tag (bgcolor, text, link, vlink, alink...). And really, what else am I going to do with this sort of junk?
Oh, right. Layers. And... stuff.
(*cough*CSSstillisn'tworkingwithlayouts!)
"Use contextual or descendant selectors as much as possible. This will keep your markup much cleaner. For example, #subnav li {border: 1px solid black; padding:
.5em; display: inline} will only affect list items that occur within your subnav div."
I have no idea how your example has anything to do with your first statement.
"Test in as many browsers as you can and get your friends to test it in their browsers."
Or rather, "Get your friends to test it in their browsers while you do nothing of consequence because all of this eyecandy doesn't do much for eyes without teeth".
"Examples of sites that use CSS"
Oh, that's it... I'm out of here...
... I hate the internet.