The FCC stays out of the content business. It doesn't care what you broadcast, as long as you pay their fees, identify yourself once an hour, and stay away from the seven dirty words.
LI tags may indent horribly, but the declaration was on the UL, not the LI. Moving the UL to the left moves the entire containing box to the left. Further, according to Eric Meyer, Opera and IE use the exact same list indenting approach: they give the UL element a left margin. Given that, why would Microsoft's CSS author(s) change the CSS that worked perfectly well in their own browser?
Yes, it could be negligence or ignorance or a failure to fully test their code (and it wouldn't be a first for Microsoft;-) ), but given their penchant for breaking things in the past to make their product look better, you'll forgive me if I still have sneaking suspicions.
I might be inclined to agree that it could be negligence and ignorance of authoring CSS AND failing to test...if Microsoft hadn't tried similar shennanigans before.
But WHY would their generic sheet feed a declaration for unordered lists that called for the list to have a left margin that goes 30 pixels off the left side of the containing box (or page if the UL is a direct child of the body)? Even a poor css author would have a hard time pulling that declaration randomly out of his or her bodily orifice of choice. At the very least, it should have been caught during testing...if they wanted to provide any quality assurance at all.
Read the article (or at least the google cached article), and you will see that Opera's research showed that MSN was feeding opera a debilitated style sheet that had list items falling off the left edge of the screen. The code in question is
ul { margin: -2px 0px 0px -30px; }
The research further showed that if you fed this same sheet to MSIE, it behaved exactly the same way -- that is, it fell off the left side of the page. Further, anyone who has ever done anything with style sheets would never feed that -30px declaration and expect anything productive to be done with it. That MSN fed it to someone else's browser but not theirs is suspicious at least.
And in the mid-90s, I had a friend whose name was Sus5an.
The 5 was, of course, silent.
Re:IE works just fine
on
CSS for the LDP?
·
· Score: 3, Informative
Um...in fairness, the grandparent post was talking about IE5 for Mac. Seeing as how MS has abandoned IE for the Mac at that version...there isn't really any Microsoft alternative he can upgrade TO.
And yes, even the most recent version of IE for windows STILL does not handle CSS fully or appropriately in all cases. To wit -- if it were, why would this project exist?
IANAL, but I believe that in response to your first question, it literally depends on how many copies the person who copied the original flyer made, and how those copies were used. If you will recall, copyright law allows for fair use. That generally means a single copy for personal, educational, and non-profit use. The assumption being made in this whole thread is that the people at FatWallet are not posting a PDF or other proprietary copy of the circular; they are only posting the facts that X item will be on sale for $Y on the Friday after Thanksgiving.
So, ironically, the single copy made by the person who leaked BB's info, that was made only so he or she could take it home and post the prices to the internet, is the one thing here that is actually protected under copyright. Consequently, there is no poison fruit.
(And yes, depending on how FatWallet makes their money, you might be tempted to argue that they abused the fair use principle when they made the copy. But again, the copy was not disseminated for their profit: the FACTS were.)
To your second question, I don't know that the analogy between your private documents and Best Buy's embargoed ads necessarily holds up. Unless you are going to be advertising the contents of your checkbook to the public, but not until the day after Thanksgiving, the comparison is moot. Best Buy will be releasing that information (and in fact they already have released it to their printers). They just want control of when that public information is released.
Incidentally, when I was a paperboy, way back in the day, I would get the Sunday advertising circulars on Friday afternoon so that I could stuff them into the papers on Sunday morning. (It is one way the papers saved money -- distribute the labor of stuffing). The upside was that my mom always knew what was going to be on sale the next week, and would make a similar decision of whether to buy this Saturday or next week.
The fact that we had the same system in place for the Thanksgiving papers (we got those circulars on Monday or Tuesday) only underscores how insecure this information has always been. The difference today as opposed to 1988?
In fixing those 12,000 pages, are you going to widen the range from that middle of the road approach? Or are you going to shift the center upwards and favor the rich (who have medical insurance) over the poor (who don't, and don't pay their hospital bills, either)?
Considering that those on the low end of the spectrum can't read our pages correctly anyway, our expansion into CSS will make that content available to ANYONE whose browsers can read basic HTML. So yes, we are expanding the range of people who can access our information. And no, the pages won't be as "pretty" as before but, unlike you, that's not my overrriding goal. My overriding goal is that the content is available and accessible to all.
I've come to accept that you are comfortable with how you do things. It's not how I would do them, but fine. We both have our rationales for why we do things. But I don't care for your implication that because I am not using tables for a purpose for which they were never intended -- layout -- so that the four visitors we saw last quarter who are using Netscape 4.08 get a reasonable approximation of what everyone else sees is somehow dishonorable and elitist. My responsibility is to make sure the CONTENT -- you know, the actual important words and sentences contained within all your font tags -- is available and it makes sense to the end user, no matter what the delivery mechanism is.
Do more users of more recent browsers get a richer visual experience? Sure. But that's a function of using the technology appropriately, not out of any spite for our patients who can't afford the latest and greatest. Do I hide the clinic hours, the medicaid information, and the health information they are looking for so that only people using CSS can see it? Emphatically, no.
Also, the older NS3 (and probably IE3, but I don't have one of those around) is incredibly fast at rendering nested tables. On a 100 MHz Pentium, NS3 was faster than what NS4 does now on an 800 MHz Pentium-III.
And similar pages that don't use tables for anything other than tabular data render even faster....;-)
I can appreciate that you have definite needs and requirements defined for your projects. If html 3.2 works for you, great.
But I also think you have a fundamental misunderstanding of HOW css/xhtml works in tandem to be the most accessible markup combination out there.
With css/xhtml, you use DIVs to mark up the semantic meanings, apply classes to the standard html tags, and let the style sheet do the formatting for you. That way, even if the presentation layer -- the CSS -- is not accepted or is ignored by the browser, the HTML still is available and valid.
Where this helps your user that has a slow computer with a stripped-down browser is that the old browser (Yes, NN3 or IE 3) doesn't waste time rendering your multiple nested layout tables, or applying my CSS files. It ignores what it doesn't recognize and renders out straightforward, simply formatted text that is still VALID HTML.
Again, I can appreciate that your sites look consistent from NN3 through the latest Mozilla build. But I know that I can use CSS to create a similar look and feel from NN4.7 on, that is still readable and understandable in NN3, and is a hell of a lot more lightweight.
Further, with the right css declaration, I can make a single page that will print appropriately with a "media=print" style sheet, render appropriately on a PDA with a "media=pda" style sheet, and even be read correctly using a screen reader. No more printer-friendly pages; no more PDA-only pages; no more javascript or PHP sniffers serving up different pages based on the browser used.
Again, I don't presume to know all the constraints around your pages and sites. What I do know, however, is that despite all the control we try to exert over the different presentations in different browsers and devices, a web developer is never going to get it to look 100% consistent. (If I wanted to be 100% in control of a page's appearance, I'd still be working in print.) But to ignore the tools at your disposal that can make your pages accessible in all those browsers and devices for the sake of making your pages *look* the same is short-sighted. IMO.
(And incidentally, in case you are wondering, I work for a hospital where we too need to be accessible to as many families as possible, and simultaneously to as many docs using bleeding edge technology as possible. Unfortunately, our last design firm took a middle-of-the road tact that tried to preserve formatting, but still ended up being useless to outliers on either end of the technology spectrum. We are now in the arduous task of fixing their mistake. On 12,000 pages.)
What you get on the older browsers is a very poor presentation. For example, if you define the look of your page in cascading stylesheets, when viewed on a browser with no support for CSS, you get crap.
If you do your css correctly, what you get in browsers that don't support css at all is a page that looks like it was coded in plain vanilla html. Oh no! Big H1s! Purple vlinks! And no carefully crafted marketing widgets! But at the very least, the MESSAGE contained within the html is still available and legible.
As for browsers with partial css support, this is where an understanding of the shortcomings of different browsers and, more importantly, testing comes into play. (You do test your sites, don't you?) Regardless of whether you are going to make a nested-table, font-tag infested site or a css-complaint site, or anything in between, any web designer worth his or her salt is going to a) know the methods for effectively rendering the content in most browsers and b) test the hell out of those designs to make sure his or her assumptions are correct.
The designs you cited as displaying poorly had as much -- if not more -- to do with poor testing as it did with CSS support/non-support. You even note as much in your aside about the Texas site:
"But no, they don't actually care (I talked to these people, and they really don't care)"
The construction of the page itself is sloppy. The author uses nested table hell to construct the page, and even with the sloppy-friendly doctype of html transitional, it STILL doesn't validate as valid html 4.01. You cannot put that page's problems all at the feet of CSS.
You note that "Mixing standards can cause problems as well." True enough...but that's even more reason to pick one standard and use it!
Ironically, the pages that you cite as two that "look fine" in older browsers simply don't validate as well. That's great for the users who use Netscape 4. It's also great for whatever designer ever gets to redesign those sites...because they're so full of nested tables and inline half-assed styles that they'll easily be able to charge those States for 3 or 4 or 10 times what a css-centered update would cost.
This is not to say that designers only use CSS because it is easier for them to reprogram, but if you accept the basic premise of css -- that html is for structural markup and css is for presentation -- the ease of redesign is a happy side effect. If done correctly, the content (which, many would argue, is the most important part of the page) is not dependant on the whims of styling that may or may not display on a given user's browser.
In fact your concern that "many in that audience will be using older computers which have smaller drive space, smaller RAM space, slower CPUs, and can only run older versions of operating systems and browser software" is actually helped by a page that depends on properly coded html/css. Because, after all, those older browsers on older systems will ignore the css sheet and display the raw HTML, delivering just the content. This means less time spent rendering unnecessary display tables, less time futzing with every font styled inline, less time loading the widgets the user doesn't need.
Done properly, html/css really does help reach a larger audience. It may not look exactly like the marketing manager wants it to, but it is still better than nothing.
(And really, if your boss doesn't mind you coding separate pages for every possible os/browser combo, more power to you. Your job is probably more secure than mine.;-)
Zeldman isn't the one who is not complying with the standard: microsoft is. px and pt are both valid measurements for defining type sizes. However, because of how the MS engineers interpreted the CSS spec, they made the decision that, unless font sizes were explicitly defined as relative, they would not allow the user to redefine the size.
Once again, MS decides that it is smrater than the end user.
(and yes, there are css workarounds to accomodate IE's shortcomings...but by definition, they are hacks. I am sure there is a reason why he didn't use them.)
If we're suggesting good sources for sampling music, Let me also pimp my favorite modern rock station: 97X (WOXY) outside of Cincinnati. They stream their broadcasts, and their playlists reflect some of the best in modern rock today -- and a good majority of the music they play is from (surprise) small indie labels.
You know, the previous poster has a point. I couldn't use my XP laptop or desktop all day Wednesday as I waited for IS to come around and personally verify that I had patched the machines correctly. It was the least trouble those damn things gave me all week!
Thank goodness I could still do work on my G4 laptop...
It's not the end of Office, certainly. But you have to look beyond just WordPad functionality. Being able to read a Word doc is the first step to making sure whatever alternative Apple develops for Office can actually be compatible WITH Office.
There's no sense in taking on the industry leader in bloatware, er, "productivity software" if you can't make it easy for users to read and edit their legacy documents. Without this basic functionality -- and the corresponding ability to market "works with Office" -- users have no reason to switch to an Office alternative.
Slashdot Mirror
The FCC stays out of the content business. It doesn't care what you broadcast, as long as you pay their fees, identify yourself once an hour, and stay away from the seven dirty words.
LI tags may indent horribly, but the declaration was on the UL, not the LI. Moving the UL to the left moves the entire containing box to the left. Further, according to Eric Meyer, Opera and IE use the exact same list indenting approach: they give the UL element a left margin. Given that, why would Microsoft's CSS author(s) change the CSS that worked perfectly well in their own browser?
Yes, it could be negligence or ignorance or a failure to fully test their code (and it wouldn't be a first for Microsoft ;-) ), but given their penchant for breaking things in the past to make their product look better, you'll forgive me if I still have sneaking suspicions.
I might be inclined to agree that it could be negligence and ignorance of authoring CSS AND failing to test...if Microsoft hadn't tried similar shennanigans before.
But WHY would their generic sheet feed a declaration for unordered lists that called for the list to have a left margin that goes 30 pixels off the left side of the containing box (or page if the UL is a direct child of the body)? Even a poor css author would have a hard time pulling that declaration randomly out of his or her bodily orifice of choice. At the very least, it should have been caught during testing...if they wanted to provide any quality assurance at all.
Read the article (or at least the google cached article), and you will see that Opera's research showed that MSN was feeding opera a debilitated style sheet that had list items falling off the left edge of the screen. The code in question is
The research further showed that if you fed this same sheet to MSIE, it behaved exactly the same way -- that is, it fell off the left side of the page. Further, anyone who has ever done anything with style sheets would never feed that -30px declaration and expect anything productive to be done with it. That MSN fed it to someone else's browser but not theirs is suspicious at least.
Um...could they complain that this new software only requires a one-button mouse?
If so...Those bastards!
And in the mid-90s, I had a friend whose name was Sus5an.
The 5 was, of course, silent.
Um...in fairness, the grandparent post was talking about IE5 for Mac. Seeing as how MS has abandoned IE for the Mac at that version...there isn't really any Microsoft alternative he can upgrade TO.
And yes, even the most recent version of IE for windows STILL does not handle CSS fully or appropriately in all cases. To wit -- if it were, why would this project exist?
...you're asking for couples' advice on /. ? ;-)
IANAL, but I believe that in response to your first question, it literally depends on how many copies the person who copied the original flyer made, and how those copies were used. If you will recall, copyright law allows for fair use. That generally means a single copy for personal, educational, and non-profit use. The assumption being made in this whole thread is that the people at FatWallet are not posting a PDF or other proprietary copy of the circular; they are only posting the facts that X item will be on sale for $Y on the Friday after Thanksgiving.
So, ironically, the single copy made by the person who leaked BB's info, that was made only so he or she could take it home and post the prices to the internet, is the one thing here that is actually protected under copyright. Consequently, there is no poison fruit.
(And yes, depending on how FatWallet makes their money, you might be tempted to argue that they abused the fair use principle when they made the copy. But again, the copy was not disseminated for their profit: the FACTS were.)
To your second question, I don't know that the analogy between your private documents and Best Buy's embargoed ads necessarily holds up. Unless you are going to be advertising the contents of your checkbook to the public, but not until the day after Thanksgiving, the comparison is moot. Best Buy will be releasing that information (and in fact they already have released it to their printers). They just want control of when that public information is released.
Incidentally, when I was a paperboy, way back in the day, I would get the Sunday advertising circulars on Friday afternoon so that I could stuff them into the papers on Sunday morning. (It is one way the papers saved money -- distribute the labor of stuffing). The upside was that my mom always knew what was going to be on sale the next week, and would make a similar decision of whether to buy this Saturday or next week.
The fact that we had the same system in place for the Thanksgiving papers (we got those circulars on Monday or Tuesday) only underscores how insecure this information has always been. The difference today as opposed to 1988?
That damn pesky internet!
Considering that those on the low end of the spectrum can't read our pages correctly anyway, our expansion into CSS will make that content available to ANYONE whose browsers can read basic HTML. So yes, we are expanding the range of people who can access our information. And no, the pages won't be as "pretty" as before but, unlike you, that's not my overrriding goal. My overriding goal is that the content is available and accessible to all.
I've come to accept that you are comfortable with how you do things. It's not how I would do them, but fine. We both have our rationales for why we do things. But I don't care for your implication that because I am not using tables for a purpose for which they were never intended -- layout -- so that the four visitors we saw last quarter who are using Netscape 4.08 get a reasonable approximation of what everyone else sees is somehow dishonorable and elitist. My responsibility is to make sure the CONTENT -- you know, the actual important words and sentences contained within all your font tags -- is available and it makes sense to the end user, no matter what the delivery mechanism is.
Do more users of more recent browsers get a richer visual experience? Sure. But that's a function of using the technology appropriately, not out of any spite for our patients who can't afford the latest and greatest. Do I hide the clinic hours, the medicaid information, and the health information they are looking for so that only people using CSS can see it? Emphatically, no.
And similar pages that don't use tables for anything other than tabular data render even faster....I can appreciate that you have definite needs and requirements defined for your projects. If html 3.2 works for you, great.
But I also think you have a fundamental misunderstanding of HOW css/xhtml works in tandem to be the most accessible markup combination out there.
With css/xhtml, you use DIVs to mark up the semantic meanings, apply classes to the standard html tags, and let the style sheet do the formatting for you. That way, even if the presentation layer -- the CSS -- is not accepted or is ignored by the browser, the HTML still is available and valid.
Where this helps your user that has a slow computer with a stripped-down browser is that the old browser (Yes, NN3 or IE 3) doesn't waste time rendering your multiple nested layout tables, or applying my CSS files. It ignores what it doesn't recognize and renders out straightforward, simply formatted text that is still VALID HTML.
Again, I can appreciate that your sites look consistent from NN3 through the latest Mozilla build. But I know that I can use CSS to create a similar look and feel from NN4.7 on, that is still readable and understandable in NN3, and is a hell of a lot more lightweight.
Further, with the right css declaration, I can make a single page that will print appropriately with a "media=print" style sheet, render appropriately on a PDA with a "media=pda" style sheet, and even be read correctly using a screen reader. No more printer-friendly pages; no more PDA-only pages; no more javascript or PHP sniffers serving up different pages based on the browser used.
Again, I don't presume to know all the constraints around your pages and sites. What I do know, however, is that despite all the control we try to exert over the different presentations in different browsers and devices, a web developer is never going to get it to look 100% consistent. (If I wanted to be 100% in control of a page's appearance, I'd still be working in print.) But to ignore the tools at your disposal that can make your pages accessible in all those browsers and devices for the sake of making your pages *look* the same is short-sighted. IMO.
(And incidentally, in case you are wondering, I work for a hospital where we too need to be accessible to as many families as possible, and simultaneously to as many docs using bleeding edge technology as possible. Unfortunately, our last design firm took a middle-of-the road tact that tried to preserve formatting, but still ended up being useless to outliers on either end of the technology spectrum. We are now in the arduous task of fixing their mistake. On 12,000 pages.)
If you do your css correctly, what you get in browsers that don't support css at all is a page that looks like it was coded in plain vanilla html. Oh no! Big H1s! Purple vlinks! And no carefully crafted marketing widgets! But at the very least, the MESSAGE contained within the html is still available and legible.
As for browsers with partial css support, this is where an understanding of the shortcomings of different browsers and, more importantly, testing comes into play. (You do test your sites, don't you?) Regardless of whether you are going to make a nested-table, font-tag infested site or a css-complaint site, or anything in between, any web designer worth his or her salt is going to a) know the methods for effectively rendering the content in most browsers and b) test the hell out of those designs to make sure his or her assumptions are correct.
The designs you cited as displaying poorly had as much -- if not more -- to do with poor testing as it did with CSS support/non-support. You even note as much in your aside about the Texas site:
The construction of the page itself is sloppy. The author uses nested table hell to construct the page, and even with the sloppy-friendly doctype of html transitional, it STILL doesn't validate as valid html 4.01. You cannot put that page's problems all at the feet of CSS.
You note that "Mixing standards can cause problems as well." True enough...but that's even more reason to pick one standard and use it!
Ironically, the pages that you cite as two that "look fine" in older browsers simply don't validate as well. That's great for the users who use Netscape 4. It's also great for whatever designer ever gets to redesign those sites...because they're so full of nested tables and inline half-assed styles that they'll easily be able to charge those States for 3 or 4 or 10 times what a css-centered update would cost.
This is not to say that designers only use CSS because it is easier for them to reprogram, but if you accept the basic premise of css -- that html is for structural markup and css is for presentation -- the ease of redesign is a happy side effect. If done correctly, the content (which, many would argue, is the most important part of the page) is not dependant on the whims of styling that may or may not display on a given user's browser.
In fact your concern that "many in that audience will be using older computers which have smaller drive space, smaller RAM space, slower CPUs, and can only run older versions of operating systems and browser software" is actually helped by a page that depends on properly coded html/css. Because, after all, those older browsers on older systems will ignore the css sheet and display the raw HTML, delivering just the content. This means less time spent rendering unnecessary display tables, less time futzing with every font styled inline, less time loading the widgets the user doesn't need.
Done properly, html/css really does help reach a larger audience. It may not look exactly like the marketing manager wants it to, but it is still better than nothing.
(And really, if your boss doesn't mind you coding separate pages for every possible os/browser combo, more power to you. Your job is probably more secure than mine. ;-)
Gosh, it resizes in my standards-compliant browser....
Zeldman isn't the one who is not complying with the standard: microsoft is. px and pt are both valid measurements for defining type sizes. However, because of how the MS engineers interpreted the CSS spec, they made the decision that, unless font sizes were explicitly defined as relative, they would not allow the user to redefine the size.
Once again, MS decides that it is smrater than the end user.
(and yes, there are css workarounds to accomodate IE's shortcomings...but by definition, they are hacks. I am sure there is a reason why he didn't use them.)
If we're suggesting good sources for sampling music, Let me also pimp my favorite modern rock station: 97X (WOXY) outside of Cincinnati. They stream their broadcasts, and their playlists reflect some of the best in modern rock today -- and a good majority of the music they play is from (surprise) small indie labels.
You mean like this small department server?
You know, the previous poster has a point. I couldn't use my XP laptop or desktop all day Wednesday as I waited for IS to come around and personally verify that I had patched the machines correctly. It was the least trouble those damn things gave me all week!
Thank goodness I could still do work on my G4 laptop...
One word: strategery.
It's not the end of Office, certainly. But you have to look beyond just WordPad functionality. Being able to read a Word doc is the first step to making sure whatever alternative Apple develops for Office can actually be compatible WITH Office.
There's no sense in taking on the industry leader in bloatware, er, "productivity software" if you can't make it easy for users to read and edit their legacy documents. Without this basic functionality -- and the corresponding ability to market "works with Office" -- users have no reason to switch to an Office alternative.