All of the major browsers (even IE, IIRC) support User CSS, which allows you to write some CSS that is applied to certain sites automatically. So, you can write a CSS stylesheet, and set it to apply to *.slashdot.org, and it'll apply automatically.
And how on earth do you do that? I know that you can make a stylesheet and have it applied to every page you visit, but how do you set it to *.slashdot.org? First time I heard of that.
I actually used to rely on Netscape 3 on some slower computers until around the release of Mozilla 1.0.
Old versions of Opera are better for old hardware, and maybe even the new versions. Very small, very fast. Also good support for User CSS. Just hit Ctrl + G to enable user mode. Alt + P, Document, User CSS to add a style sheet.
Slashdot can not be expected to be responsible for bugs or feature absence in 3rd party software, I'm sorry to say.
What? Slashdot can't be expected to provide a page that works in all browsers, even though they have for a decade, but it's reasonable to expect the rest of the world to upgrade their hardware and software just so they can view/.?!
Remember,/. users, by definition as nerds, are on all sorts of hardware, systems, and browsers.
This isn't a problem with Konqueror alone, it's a problem with many browsers, IE5, Opera5 and I'm sure many more. It's very difficult to use CSS and have a page render in all browsers the same because the interpretation of the box model, the margin and padding calculations, and just plain support of different features differs in each browser.
I don't expect/. to become expert CSS coders over night, especially since that task is so difficult, what I do expect however, is an option to turn off styles, and not just because beta. They for years have provided a Light version, which was lighter than all this div-itis; why can't they continue to provide something like that.
The page may look better in Mozilla, but it's god-awful in konqueror... The teal article header background now takes up over an entire page for the first article on the page (including in comments view). The input boxes are now way to spaced out - it looks like below (only worse):
The teal article header has been given height:100% and this causes bugs in many browsers that interpret height:100% as 100% of the screen or window or something. Therefore height:100% should not be used.
The bug effects Internet Explorer 5*, Opera 5*, and as you said Konqueror EL3. The complaint has been made, yet no one is fixing it. I hope it doesn't take 8 years.
We should be able to disable stylesheets in our browsers according to the accessibility guidelines, yet the only browser that lets you is Opera, (Shift + G and/or Alt + P, Advanced, Content, Style options...). Therefore,/. needs to add an option to disable styles in preferences.
Make a new text doc and paste my CSS in it, then rename it whatever.css and in mozilla I recommend finding the Web Developer extension, or maybe the EditCSS extention.
The/. Light version had no styling before, but now it has stylesheets, so you have to disable All Styles then CSS Add Style with webdeveloper plugin. Don't know a better way at this point, someone Pleas tell me.
Opera does a better job with user CSS, and it's now free. Opera is how I got hooked on User CSS.
Press: Alt + P, Advanced, Content, Style options... Then when browsing, hit Shift + G or hit the glasses and/or the Document button. (Doing Shift + G without specifying a stylesheet will just strip the styles out.)
Err, except the way it is now is semantically correct - it's a list of links. Your way it's just a bunch of links all mooshed together with no semantics at all.
I don't agree, and who cares. Where does this cause a problem for anybody?!
Just because you have two elements in a row doesn't mean that you have a list. If you're going to make a side bar, maybe use list items, but put it at the bottom of the document. Other wise, it's stupid to make list items and make them in-line.
Let me give you some examples on non list-item embedded links on this page:
[ Reply to This | Parent ]
1 | 2 | (3) | 4 | 5
Slashdot HTML 4.01 and CSS | Preferences | Top | 631 comment
It just doesn't make sense to embed these in list items.
One place they used list items is with [ Read More... ] links. I wish they would switch this.
The problem with list-item embedded links is that the links at times get separated from the style sheet and show up as 7 pages of list items that you have to scroll through, and why, because someone is being obsessive compulsive. As for me, I use my custom stylesheet and I have to constantly wade through pages of list-item links, and it's annoying.
If we have to choose between semantics and functionality, I choose functionality. Semantics is not accessibility.
There is a lot of "div-itis" though, but I'm guessing that was to provide flexibility for user defined stylesheets in the future, so can be forgiven i guess.
Yes, the tabled light version was smaller than the current div-itis.
An empty file might do the trick as this should make your browser use it's default fonts and colours etc.
Are you sure about that?!
How to get slashdot/your browser to use your css file instead of the default one defined in the HTML might be a little trickier... Anyone got any ideas?
> making a new style sheet for your computer will remedy the situation.
Well I'm a programmer but I'll be fucked if I can be arsed to learn all that web crap. Can someone point me in the direction of a style sheet or whatever that makes Slashdot look like it did a few days ago?
The whole "If you don't like it, too bad, or re author the page" is idiotic.
I don't have a style sheet that makes it look the same, but you can apply the one from my journal to make it less retarded:
I just did some comparisons, and as a matter of fact, Light mode with tables is smaller than light mode with CSS. That's right! The CSS is making the page bigger. That's why they're rationalizing about how it's not needed anymore. (Someone compare the un-light.)
The whole religious movement against tables is ridiculous when the end result is bigger and doesn't work in everyones' browsers.
I have been using light mode with my personal style sheets for years now, very accessible. I have one in my journal if you're looking. It is way better than the nested DIVs and it works in every browser, and it's smaller.
I would post better stylesheets but hard to post without them getting mangled.
In Firefox 1.5b1, the stuff after Read More has really odd linebreaks when you set your/. preferences to the bare minimum. (no graphics, threshold 3 and higher...)
That's because they're using list items and displaying them in line in the stylesheet. I think it's wrong and they should convert it to class=commentSub like the do with [ Reply to This | Parent ].
That goes for the side bars when you're not logged in too. When you disable the style sheet you have six pages of list items before the content.
I've used Opera for years and have always paid for it.
I've used Opera for years and have always cracked it.
Just kidding. I love Opera though. Very sad that they're doing this. Maybe in the future they can switch back? I think they should have made one version free. Maybe they can revert back at version 9?
You are now charged with sedition for posting racist comments online. You will not have representation. Bail is set at $10,000. Punishment is 16 canings followed by death.
Some science magazine I read a while ago suggested that the drug problem in the US was a credible factor in gun violence. No one has mentioned that yet.
It removes the ability of suicidal individuals to use an extremely effective means of suicide. Since suicide is by far the leading cause of firearm death in countries like Canada with low firearm violence, banning guns in such countries lowers the number of suicides by virtue of making any attempt at suicide less likely to succeed.
I think the next most common method, is hanging which is also highly lethal, so it wouldn't make suicide attempts less likely to succeed. Hanging is preferred by women over guns.
(Certainly, some of those people would keep trying until they succeeded, but many would not, and would go on to be healthy and productive members of society.)
I'm not sure exactly what you mean but Firefox can by default use custom stylesheets which I would think, accomplishes the same thing.
Not really. User stylesheets are not intuitive in FireFox and I think they cascade with the authors. You can accomplish this with the Web Developer extension you can Disable All CSS, then Add Stylesheet to accomplish the same thing. If there is no CSS in the page, just do Add.
If you know of a better extension, let me know.
However, in Opera, the User Mode overrides the Authors styles, and in opera it has generally been easy to do this... They moved it and changed the shortcut...
Just hit Shift + G.
Or you can click on the glasses on the right you should see the Author/User Mode button.
Now for the good part:
Press Alt + P, Advanced, Content, Style options...
Then specify a user stylesheet. Use one of mine from my journal.
I think one of the most important features of Opera is the User Style Sheets.
If you give every element a color, background, font, or border, you can essentially skin web pages. It's wonderful and entertaining and can make pages more 'accessible'. My journal has some stylesheets for the Light PDA-Version of Slashdot. I would give more, but/. hacks them.
This can also be accomplished with Firefox web developer extension, but Opera is just faster.
One thing that I dislike about Opera is that starting after version 5, every new version is so drastically different in its behavior, rendering, shourtcuts, etc.. it's a bit annoying, but generally you can customized the behavior back to how you like.
I stopped using bookmarks a long time ago too. It was too much of a hassle to keep track of them. One bad side effect is that sometimes I don't know where to go, and over time I start to forget about pages I previously frequented.
A DIV has very little meaning and a SPAN has even less meaning. You should know that yet your arguing about it
I'm not arguing about that. I agree. You said that they were undefined and implied that they were non-standard. They are neither.
The point is that it offers little value to focus on that, except to avoid the real issue and be difficult.
just because it's stupid to use a generic element type in place of a more accurate element type, that doesn't mean it's clever to use a specific element type in the wrong way, or that it's stupid to use a generic element type where no more accurate element types exist.
If people don't have a more accurate tag, yes I said tag asshole, than according to you, they should use DIV or SPAN, obviously with a class to differentiate. The most commonly use would be class=note or footer, but outside of that you have billions of possibilities... There is no way for a computer to data mine or for a user to glean more than that without debugging and hacking through a page to determine what's going on behind the scenes.
Never said it was clever. I suggested that it was the lesser of two evils.
The correct use of a <div> element is where no more appropriate element type is available. This isn't a "my blind friend can't understand headings" argument, because appropriate element types exist for headings.In situations where there is no more appropriate element type, an aural user-agent is assisted best by an accurate description - a description that says "this is simply a part of the document and I cannot be more specific".
Here we go with you being difficult. I never said that the blind can't read headings. I was saying that headings are defined as something useful while DIV and SPAN are not useful to the blind, or anyone for that matter, except for authors self-gratification, because their definition is inadequate. I think you knew what I was saying, so pleas stick to the pertinent points.
If you can't be more specific about what a DIV is, then you are producing unsemantic inaccessible pages. Sure, sometimes you will come across DIV.NOTE and DIV.FOOTER, but that's about as close you can get to accessibility to the user or user style sheet.
If a blind person, or any person goes to a page layout that's using tables, they can at least jump to table cell 2 and get to the heart of the content. With DIV you can't do that.
By mislabelling the contents of your documents, the semantic information provided by your markup is garbage, so any computer program that could work with such information will produce garbage itself.
Nonsense. Not true. If someone uses table for layout then you either are looking at a table or a table layout. It's not that hard. The Internet doesn't come to a complete halt.
If you're talking about a computer that you're using to run data mining on sites, obviously you have a little problem. You may be able to come up with a formula to get around it, but if using a DIV with a class of layout or something is acceptable, I think it might be equally acceptable to use TABLE.LAYOUT and have a page that degrades well on all browsers.
Again, that's unsemantic, but then so is DIV.LAYOUT, at least to everyone but the author. The W3C should have provided a layout mechanism in earlier versions of HTML, but because they didn't, people have to make a choice between layouts that are currently 'unsemantic' that work, and ones that are recommended but fail in many browsers.
And why? Because of the ridiculous belief that our tables and elements will spin and dance about to our every wish, and the ad hoc theory that they don't because people use tables for layout.
On the contrary, use of DIV and CSS for layout can be 65% garbage in some browsers.
We're arguing but that doesn't mean that you have to nit pick over every single word of every sentence. Otherwise you're being difficult.
A DIV has very little meaning and a SPAN has even less meaning. You should know that yet your arguing about it now because you have every intention of being as difficult as possible and avoiding the fact that DIV/CSS layout is not as widely supported in browsers as the TABLE is. Period.
How many class or ids can be added to a DIV or a SPAN? Billions. Therefore the DIV/SPAN can be used for billions of things. That makes for less accessibility because the definition is not standardized in the way that a heading is a heading and can be expected by the blind to be read as a heading.
Traditionally people use tables for layout, today people are preaching about using DIV. So there is a dichotomy between what to use because if you use DIV you will have pages that won't display in many browsers.
Have you heard the phrase "garbage in, garbage out"? By mislabelling the contents of your documents, the semantic information provided by your markup is garbage, so any computer program that could work with such information will produce garbage itself.
No. I disagree. I think you're being overly dramatic. If someone uses a table for layout, the end result does not come out as 100% garbage. On the contrary, use of DIV and CSS for layout can be 65% garbage in some browsers.
Browsers have box model, and other bugs, making it difficult to use DIV in the place of TABLE.
Once more, I'm not saying "use <div> elements instead of <table> elements". I'm saying "use the correct element type". Sometimes that's the <div> element type. Sometimes it's the <p> element type. Sometimes it's the <table> element type.
Yes but were talking about TABLE being used for layout. Look at your other comments. And obviously P is not intended for layouts.
CSS layouts aren't some insurmountable task. Unless you already have experience in table layouts, they aren't any harder than table layouts. Yeah, browsers sometimes render them oddly, but that's true of table layouts too.
No, it's more of a problem with CSS/DIV layouts. I have experience with both. That's how I know. Your attitude is careless towards other browsers. The end result with CSS can be quite unpredictable, whereas with tables the end result is generally about the same.
Funny how you avoid the issue up to a point, then you say: "So what.. tables don't display the same in browsers either." or "We're not arguing about IE." and then you have the nerve to tell people that they are arguing deceptively.
And I don't agree that the misuse of tables is holding back the web.
I gave you one very specific example of a feature that would only work if misuse of tables wasn't widespread, but you haven't refuted it.
The ability to rotate elements is something that should be available to whoever wants it. That people use tables for layout is hardly an excuse to not provide it, nor is it the reason. You can't let the browsers rotate tables or format a page by itself because it's bound to do it by mistake because the task is too complex. That is the fundamental reason browsers don't rotate TABLES. Consider that people use IMG correctly... Yet the browsers don't yet rotate IMGs.
A table rotating formula shouldn't rotate any table that is as wide as it is tall, nor tables that are taller than they are wide. Nor should it rotate tables that are 100% of the screen. So I think that the majority of table layouts would be unaffected by this bug you speak of.
The issue is that the ability to rotate anything is not here yet. Then the ability to specify what should rotate would be something for a newer version of CSS perhaps.
If there's a more specific element type available, that's even better.
Bingo! There isn't. And that's what I said.
We're left to choose between the (traditionally used for layout) TABLE that's supported in all browsers consistently, and DIV with CSS that the end results will be bizarre. It is not trivial and I'm not talking exclusively of one bug in one browser.
Now, you can call the use of TABLE for layout as wrong, incorrect, or unsemantic. The fact is that it works.
You should use the most appropriate element type...
I agree. But the w3c isn't making any new elements, therefore, we have to work with what we've got and what actually works.
Let's look at your logic:
1. Rotating tables is wonderful. 2. It's impossible because loads of people misuse the element type.
I actually think that rotating tables is impossible because no one made it possible. If they did, they could also make something like Table:max-width[100%] rotate-table or something.
I also think it's not practical to let computers auto rotate because, contrary to your theory of autonomous AI-computers formatting pages, people are required to format pages correctly.
If a page author messes up a page, the user should be able to override his style. The user can't do that if everything on the page is inside a DIV or a SPAN. Nor can the computer do that. Maybe the author told how a class of DIV is to be displayed, but a computer can't come up with a more acceptable alternative. This requires the user to debug a page. There goes accessibility.
If you don't want HTML to work that way, by all means convince the W3C that you are right and they are wrong, or convince browsers to support your own markup language that isn't HTML.
Like it or not, tables can be used for layout because browsers already support HTML TABLEs, and the spec was written to let them. Maybe there is a new spec that insists we use DIV class=whatever, but browsers have box model bugs.
I know what you're saying. What I'm saying is that it's better to use one standardized element for two things than it is to use one undefined element for a billion things because it's more accessible to the user. A blind user, or any user, can't differentiate between individual DIV and SPAN elements because they are generic. Knowing that something is a DIV or a SPAN is about as useful as knowing that something has a FONT tag around it.
And, browsers don't support your philosophy uniformly.
On the contrary, pretty much every user-agent that has ever existed can tell the difference between element types if you actually mark up your content properly.
Browsers have box model, and other bugs, making it difficult to use DIV in the place of TABLE. I know because I've made CSS versions of/. and plastic and tested them against browsers and it requires lots of work. I'm not in favor of using a million tables to have one comment, but it might be better to use one table per comment and add class to differentiate, and that would be more compatible with every browser than to simply use DIV for the entire page.
And I don't agree that the misuse of tables is holding back the web.
I have nothing against Web pages looking pretty--but when it's 2005 and they're still using HTML rather than CSS to do it, it's time to wake up. It will generally make the pages lighter, faster to load, reduce bandwith costs, and improve accessibility (provided you use semantic HTML)--and I don't mean just for blind users; this goes also for people on cell phones, etc.
I agree with most of what you say, but correct me if I'm wrong, most of this argument centers around TABLE vs DIV, and how tables are just more solid and widely supported by all browsers. So what difference does it make how old they are, as long as they work?
Slashdot Mirror
All of the major browsers (even IE, IIRC) support User CSS, which allows you to write some CSS that is applied to certain sites automatically. So, you can write a CSS stylesheet, and set it to apply to *.slashdot.org, and it'll apply automatically.
And how on earth do you do that? I know that you can make a stylesheet and have it applied to every page you visit, but how do you set it to *.slashdot.org? First time I heard of that.
I actually used to rely on Netscape 3 on some slower computers until around the release of Mozilla 1.0.
Old versions of Opera are better for old hardware, and maybe even the new versions. Very small, very fast. Also good support for User CSS. Just hit Ctrl + G to enable user mode. Alt + P, Document, User CSS to add a style sheet.
Slashdot can not be expected to be responsible for bugs or feature absence in 3rd party software, I'm sorry to say.
/.?!
/. users, by definition as nerds, are on all sorts of hardware, systems, and browsers.
/. to become expert CSS coders over night, especially since that task is so difficult, what I do expect however, is an option to turn off styles, and not just because beta. They for years have provided a Light version, which was lighter than all this div-itis; why can't they continue to provide something like that.
What? Slashdot can't be expected to provide a page that works in all browsers, even though they have for a decade, but it's reasonable to expect the rest of the world to upgrade their hardware and software just so they can view
Remember,
This isn't a problem with Konqueror alone, it's a problem with many browsers, IE5, Opera5 and I'm sure many more. It's very difficult to use CSS and have a page render in all browsers the same because the interpretation of the box model, the margin and padding calculations, and just plain support of different features differs in each browser.
I don't expect
The page may look better in Mozilla, but it's god-awful in konqueror... The teal article header background now takes up over an entire page for the first article on the page (including in comments view). The input boxes are now way to spaced out - it looks like below (only worse):
/. needs to add an option to disable styles in preferences.
The teal article header has been given height:100% and this causes bugs in many browsers that interpret height:100% as 100% of the screen or window or something. Therefore height:100% should not be used.
The bug effects Internet Explorer 5*, Opera 5*, and as you said Konqueror EL3. The complaint has been made, yet no one is fixing it. I hope it doesn't take 8 years.
We should be able to disable stylesheets in our browsers according to the accessibility guidelines, yet the only browser that lets you is Opera, (Shift + G and/or Alt + P, Advanced, Content, Style options...). Therefore,
Make a new text doc and paste my CSS in it, then rename it whatever.css and in mozilla I recommend finding the Web Developer extension, or maybe the EditCSS extention.
/. Light version had no styling before, but now it has stylesheets, so you have to disable All Styles then CSS Add Style with webdeveloper plugin. Don't know a better way at this point, someone Pleas tell me.
/* optional */: 0;padding-left:3px;} /* font optional */
The
You can also try and add it to you chrome\userContent-example.css but it might just cascade.
Opera does a better job with user CSS, and it's now free. Opera is how I got hooked on User CSS.
Press: Alt + P, Advanced, Content, Style options...
Then when browsing, hit Shift + G or hit the glasses and/or the Document button.
(Doing Shift + G without specifying a stylesheet will just strip the styles out.)
Here's another small one:
body,td{font-size:12px;
font-family:verdana,sans-serif;}
h1,h2,h3,h4,h5,h6,a[name] b{display:block;background:#696;color:#eff;margin
td td{background:#cdc;}
ul{margin:1em;}
b{font-family:tahoma,sans-serif;}
I don't agree, and who cares. Where does this cause a problem for anybody?!
Just because you have two elements in a row doesn't mean that you have a list. If you're going to make a side bar, maybe use list items, but put it at the bottom of the document. Other wise, it's stupid to make list items and make them in-line.
Let me give you some examples on non list-item embedded links on this page:
[ Reply to This | Parent ]
1 | 2 | (3) | 4 | 5
Slashdot HTML 4.01 and CSS | Preferences | Top | 631 comment
( http://slashdot.org/ | Last Journal )
Domo-Sun [ Log Out ]
It just doesn't make sense to embed these in list items.
One place they used list items is with [ Read More... ] links. I wish they would switch this.
The problem with list-item embedded links is that the links at times get separated from the style sheet and show up as 7 pages of list items that you have to scroll through, and why, because someone is being obsessive compulsive. As for me, I use my custom stylesheet and I have to constantly wade through pages of list-item links, and it's annoying.
If we have to choose between semantics and functionality, I choose functionality. Semantics is not accessibility.
There is a lot of "div-itis" though, but I'm guessing that was to provide flexibility for user defined stylesheets in the future, so can be forgiven i guess.
Yes, the tabled light version was smaller than the current div-itis.
An empty file might do the trick as this should make your browser use it's default fonts and colours etc.
Are you sure about that?!
How to get slashdot/your browser to use your css file instead of the default one defined in the HTML might be a little trickier... Anyone got any ideas?
Yeah. Use opera, it's free now.
Press: Alt + P, Advanced, Content, Style options...
Then when browsing, hit Shift + G formerly Ctrl + G. (Or hit the glasses and/or the Document button.)
In Fire Fox you have to use the Web Developer Extension, disable styles, the add style.
IE is options Accessibility or something, but it just cascades and you have to add ! important and override all the stylesheet declaration:
body,td,* {color:black;background:white;}
I'm not going to waste my time.
The only browser that gets this right is Opera.
> making a new style sheet for your computer will remedy the situation.
/* Slashdot.org */
/* Small fonts */
/* headings. Formerly H2,H3 */
Well I'm a programmer but I'll be fucked if I can be arsed to learn all that web crap. Can someone point me in the direction of a style sheet or whatever that makes Slashdot look like it did a few days ago?
The whole "If you don't like it, too bad, or re author the page" is idiotic.
I don't have a style sheet that makes it look the same, but you can apply the one from my journal to make it less retarded:
body{font-family:arial narrow,arial,sans-serif;}
h1,h2,h3,h4,h5,h6 {
color:white;
background:#006666;
margin:0%;
font-family:arial,sans-serif;}
h1 a,h2 a,h3 a,h4 a,h5 a,h6 a{
color:#CCCCCC;}
ul,ol{border:thin solid gray}
li{margin:0;}
i,em,cite,dfn,var{
color:maroon;}
b,strong{color:navy;
font-family:arial,sans-serif;}
tt{font-family:"Andale Mono",monospace;}
blockquote{color:#300;
background:#cdc;
font-family:verdana,tahoma,"Trebuchet MS",sans-serif;
font-size:10px;
margin:1em 3em;
padding:3px}
img{font-family:verdana,sans-serif ;
font-size:9px;
border:thin solid #933;}
a[name] b{display:block;
color:white;
background:#006666;
margin:0%;
font-family:arial,sans-serif;}
a{text-decoration:none;
border-bottom:thin solid blue;}
a:hover{color:navy;
border-bottom:thin solid navy;}
td{background:#aaa;}
td + td{background:#bbb;}
dt{background:#CCCC99;}
I just did some comparisons, and as a matter of fact, Light mode with tables is smaller than light mode with CSS. That's right! The CSS is making the page bigger. That's why they're rationalizing about how it's not needed anymore. (Someone compare the un-light.)
Look at the difference:
<div class="commentTop"><div class="title"></div><div class="details">
<TD></TD>
The whole religious movement against tables is ridiculous when the end result is bigger and doesn't work in everyones' browsers.
I have been using light mode with my personal style sheets for years now, very accessible. I have one in my journal if you're looking. It is way better than the nested DIVs and it works in every browser, and it's smaller.
I would post better stylesheets but hard to post without them getting mangled.
Can't use height:100% in IE 5 and Opera 5. It creates large vertical gaps. In Opera 5 they are the size of the window, in IE 5 they can be enormous.
Also change Read More... from block-level list items to in-line elements like those seen between div class="commentSub" [ Reply to This | Parent ].
In Firefox 1.5b1, the stuff after Read More has really odd linebreaks when you set your /. preferences to the bare minimum. (no graphics, threshold 3 and higher...)
( Read More... |
# 23 of 139 comments
| games.slashdot.org
)
That's because they're using list items and displaying them in line in the stylesheet. I think it's wrong and they should convert it to class=commentSub like the do with [ Reply to This | Parent ].
That goes for the side bars when you're not logged in too. When you disable the style sheet you have six pages of list items before the content.
I've used Opera for years and have always paid for it.
I've used Opera for years and have always cracked it.
Just kidding. I love Opera though. Very sad that they're doing this. Maybe in the future they can switch back? I think they should have made one version free. Maybe they can revert back at version 9?
Did you just say chink, spic, and niggardly?
You are now charged with sedition for posting racist comments online.
You will not have representation. Bail is set at $10,000.
Punishment is 16 canings followed by death.
Some science magazine I read a while ago suggested that the drug problem in the US was a credible factor in gun violence. No one has mentioned that yet.
It removes the ability of suicidal individuals to use an extremely effective means of suicide. Since suicide is by far the leading cause of firearm death in countries like Canada with low firearm violence, banning guns in such countries lowers the number of suicides by virtue of making any attempt at suicide less likely to succeed.
I think the next most common method, is hanging which is also highly lethal, so it wouldn't make suicide attempts less likely to succeed. Hanging is preferred by women over guns.
(Certainly, some of those people would keep trying until they succeeded, but many would not, and would go on to be healthy and productive members of society.)
I'm not so sure about that. More info here http://suicidemethods.net/
I'm not sure exactly what you mean but Firefox can by default use custom stylesheets which I would think, accomplishes the same thing.
Not really. User stylesheets are not intuitive in FireFox and I think they cascade with the authors. You can accomplish this with the Web Developer extension you can Disable All CSS, then Add Stylesheet to accomplish the same thing. If there is no CSS in the page, just do Add.
If you know of a better extension, let me know.
However, in Opera, the User Mode overrides the Authors styles, and in opera it has generally been easy to do this... They moved it and changed the shortcut...
Just hit Shift + G.
Or you can click on the glasses on the right you should see the Author/User Mode button.
Now for the good part:
Press Alt + P, Advanced, Content, Style options...
Then specify a user stylesheet. Use one of mine from my journal.
I think one of the most important features of Opera is the User Style Sheets.
/. hacks them.
If you give every element a color, background, font, or border, you can essentially skin web pages. It's wonderful and entertaining and can make pages more 'accessible'. My journal has some stylesheets for the Light PDA-Version of Slashdot. I would give more, but
This can also be accomplished with Firefox web developer extension, but Opera is just faster.
One thing that I dislike about Opera is that starting after version 5, every new version is so drastically different in its behavior, rendering, shourtcuts, etc.. it's a bit annoying, but generally you can customized the behavior back to how you like.
I stopped using bookmarks a long time ago too. It was too much of a hassle to keep track of them. One bad side effect is that sometimes I don't know where to go, and over time I start to forget about pages I previously frequented.
The point is that it offers little value to focus on that, except to avoid the real issue and be difficult.
If people don't have a more accurate tag, yes I said tag asshole, than according to you, they should use DIV or SPAN, obviously with a class to differentiate. The most commonly use would be class=note or footer, but outside of that you have billions of possibilities... There is no way for a computer to data mine or for a user to glean more than that without debugging and hacking through a page to determine what's going on behind the scenes.
Never said it was clever. I suggested that it was the lesser of two evils.
Here we go with you being difficult. I never said that the blind can't read headings. I was saying that headings are defined as something useful while DIV and SPAN are not useful to the blind, or anyone for that matter, except for authors self-gratification, because their definition is inadequate. I think you knew what I was saying, so pleas stick to the pertinent points.
If you can't be more specific about what a DIV is, then you are producing unsemantic inaccessible pages. Sure, sometimes you will come across DIV.NOTE and DIV.FOOTER, but that's about as close you can get to accessibility to the user or user style sheet.
If a blind person, or any person goes to a page layout that's using tables, they can at least jump to table cell 2 and get to the heart of the content. With DIV you can't do that.
Nonsense. Not true. If someone uses table for layout then you either are looking at a table or a table layout. It's not that hard. The Internet doesn't come to a complete halt.
If you're talking about a computer that you're using to run data mining on sites, obviously you have a little problem. You may be able to come up with a formula to get around it, but if using a DIV with a class of layout or something is acceptable, I think it might be equally acceptable to use TABLE.LAYOUT and have a page that degrades well on all browsers.
Again, that's unsemantic, but then so is DIV.LAYOUT, at least to everyone but the author. The W3C should have provided a layout mechanism in earlier versions of HTML, but because they didn't, people have to make a choice between layouts that are currently 'unsemantic' that work, and ones that are recommended but fail in many browsers.
And why? Because of the ridiculous belief that our tables and elements will spin and dance about to our every wish, and the ad hoc theory that they don't because people use tables for layout.
A DIV has very little meaning and a SPAN has even less meaning. You should know that yet your arguing about it now because you have every intention of being as difficult as possible and avoiding the fact that DIV/CSS layout is not as widely supported in browsers as the TABLE is. Period.
How many class or ids can be added to a DIV or a SPAN? Billions. Therefore the DIV/SPAN can be used for billions of things. That makes for less accessibility because the definition is not standardized in the way that a heading is a heading and can be expected by the blind to be read as a heading.
Traditionally people use tables for layout, today people are preaching about using DIV. So there is a dichotomy between what to use because if you use DIV you will have pages that won't display in many browsers.
No. I disagree. I think you're being overly dramatic. If someone uses a table for layout, the end result does not come out as 100% garbage. On the contrary, use of DIV and CSS for layout can be 65% garbage in some browsers.
Yes but were talking about TABLE being used for layout. Look at your other comments. And obviously P is not intended for layouts.
No, it's more of a problem with CSS/DIV layouts. I have experience with both. That's how I know. Your attitude is careless towards other browsers. The end result with CSS can be quite unpredictable, whereas with tables the end result is generally about the same.
Funny how you avoid the issue up to a point, then you say: "So what.. tables don't display the same in browsers either." or "We're not arguing about IE." and then you have the nerve to tell people that they are arguing deceptively.
The ability to rotate elements is something that should be available to whoever wants it. That people use tables for layout is hardly an excuse to not provide it, nor is it the reason. You can't let the browsers rotate tables or format a page by itself because it's bound to do it by mistake because the task is too complex. That is the fundamental reason browsers don't rotate TABLES. Consider that people use IMG correctly... Yet the browsers don't yet rotate IMGs.
A table rotating formula shouldn't rotate any table that is as wide as it is tall, nor tables that are taller than they are wide. Nor should it rotate tables that are 100% of the screen. So I think that the majority of table layouts would be unaffected by this bug you speak of.
The issue is that the ability to rotate anything is not here yet. Then the ability to specify what should rotate would be something for a newer version of CSS perhaps.
If there's a more specific element type available, that's even better.
Bingo! There isn't. And that's what I said.
We're left to choose between the (traditionally used for layout) TABLE that's supported in all browsers consistently, and DIV with CSS that the end results will be bizarre. It is not trivial and I'm not talking exclusively of one bug in one browser.
Now, you can call the use of TABLE for layout as wrong, incorrect, or unsemantic. The fact is that it works.
You should use the most appropriate element type...
I agree. But the w3c isn't making any new elements, therefore, we have to work with what we've got and what actually works.
Let's look at your logic:
1. Rotating tables is wonderful.
2. It's impossible because loads of people misuse the element type.
I actually think that rotating tables is impossible because no one made it possible. If they did, they could also make something like Table:max-width[100%] rotate-table or something.
I also think it's not practical to let computers auto rotate because, contrary to your theory of autonomous AI-computers formatting pages, people are required to format pages correctly.
If a page author messes up a page, the user should be able to override his style. The user can't do that if everything on the page is inside a DIV or a SPAN. Nor can the computer do that. Maybe the author told how a class of DIV is to be displayed, but a computer can't come up with a more acceptable alternative. This requires the user to debug a page. There goes accessibility.
If you don't want HTML to work that way, by all means convince the W3C that you are right and they are wrong, or convince browsers to support your own markup language that isn't HTML.
Like it or not, tables can be used for layout because browsers already support HTML TABLEs, and the spec was written to let them. Maybe there is a new spec that insists we use DIV class=whatever, but browsers have box model bugs.
If you havn't got anything to hide then you don't have anything to worry about
The whole "We have nothing to fear" argument is dumb. We always have something to fear.
Obviously you aren't grasping my analogy,
/. and plastic and tested them against browsers and it requires lots of work. I'm not in favor of using a million tables to have one comment, but it might be better to use one table per comment and add class to differentiate, and that would be more compatible with every browser than to simply use DIV for the entire page.
I know what you're saying. What I'm saying is that it's better to use one standardized element for two things than it is to use one undefined element for a billion things because it's more accessible to the user. A blind user, or any user, can't differentiate between individual DIV and SPAN elements because they are generic. Knowing that something is a DIV or a SPAN is about as useful as knowing that something has a FONT tag around it.
And, browsers don't support your philosophy uniformly.
On the contrary, pretty much every user-agent that has ever existed can tell the difference between element types if you actually mark up your content properly.
Browsers have box model, and other bugs, making it difficult to use DIV in the place of TABLE. I know because I've made CSS versions of
And I don't agree that the misuse of tables is holding back the web.
I have nothing against Web pages looking pretty--but when it's 2005 and they're still using HTML rather than CSS to do it, it's time to wake up. It will generally make the pages lighter, faster to load, reduce bandwith costs, and improve accessibility (provided you use semantic HTML)--and I don't mean just for blind users; this goes also for people on cell phones, etc.
I agree with most of what you say, but correct me if I'm wrong, most of this argument centers around TABLE vs DIV, and how tables are just more solid and widely supported by all browsers. So what difference does it make how old they are, as long as they work?