I hope that those who loathe Microsoft for whatever reason, now have something to credit it for.
Yes, when Internet Explorer 8 is released, Microsoft will finally have implemented decent support for CSS 2, a specification published over a decade ago. I hope everybody here on Slashdot will join me in welcoming Microsoft to 1998. Truly, they deserve all the credit they are going to get for being so ahead of the curve. Keep innovating, Microsoft! Don't let those slow-coaches at the W3C hold you back!
I know you are kidding, but since they restarted Internet Explorer development, Microsoft have submitted thousands of testcases to the W3C CSS Test Suite, which were welcomed and almost entirely accepted without change.
Coincidentally, the first draft for Back to the Future had a fridge for the time machine, but that was changed because the director thought it would end up with kids watching the film, playing around climbing into fridges, and getting trapped.
Chapter 15, however, is useless without an actual phone, even though it's perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There's even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It's a shame Apple couldn't figure out a way yet to include the accelerometer in the simulator.
It's possible to link up an iPhone's accelerometer to the simulator, and it's also possible to link up the accelerometer in a MacBook to the simulator as well. More details here. Honestly, though, it's probably easier to just jailbreak your iPhone.
Then you must be a youngin' -- ask an old timer some time what it was like developing for Nutscrape 4.x. IE6 was a fucking wet dream in comparison. You don't know what buggy software is.
I've been a web developer for just over a decade now. Yes, I developed for Netscape 4. It wasn't half as bad as Internet Explorer 6 in terms of bugs. You're forgetting that it just simply didn't support anywhere near as much of the specs as Internet Explorer 6. It has far fewer bugs simply because there was less of it in total. Had it attempted to cover as much of the specs as Internet Explorer 6 did, then I'm sure that it would have been buggier. But it didn't and it wasn't.
But Netscape 4 is just a distraction. Even if it were buggier than Internet Explorer 6, that doesn't make Internet Explorer 6 any less buggy. So what's your point? Just as an excuse to say that I don't know what I am talking about? I supported Netscape 4 for years. I know buggy software. And I stand by my claim that Internet Explorer 6 is one of the most buggiest pieces of software I have ever known.
BTW, my experience with IE6 was not developing web pages to house flows of paragraphs of text, like a blog site. Instead it was mimicking a desktop app with resizable panes of controls and images. With a single table layout as the backbone (I'm a pragmatist, not a purist). And avoiding anything exotic in CSS. I stuck to the common denominator among the Trident and Gecko browsers.
So what you're saying is that as long as you don't count all the buggy bits of Internet Explorer 6, it isn't so buggy?
(And by "strict mode" I mean HTML strict. I heard there were drawbacks with going with XHMTL, so I stayed away from that. So I guess you could say that IE6 was excessively buggy, if you define "buggy" as not working according to a spec it was, as you said, never intended to conform to. Then I guess if MS Word doesn't wash my dog, it's "buggy".
Why are you bringing up XHTML? I didn't say that Internet Explorer 6 was buggy because it didn't support XHTML, I said it was buggy even in "standards" mode, which is the mode that the HTML Strict document type puts Internet Explorer 6 into. I didn't define buggy the way you say, I didn't mention XHTML at all, you are attacking a straw man of your own construction.
Gecko is large and unwieldy compared to Webkit. When Apple decided to build a browser, they hired ex-Mozilla developers, who promptly turned around and used KHTML because it was so much leaner and better designed, despite their extensive experience with Gecko.
It's far from obvious that Firefox is ahead in the technology stakes. It trails in many ways and seems like a far less agile project compared with Webkit and Opera. It does have a few areas where it is ahead, but the downsides seem like an albatross to me.
I totally agree in the context of family members sharing a computer, but I find profiles useful because I'm a web developer and I don't want lots of toolbars taking up screen space and development extensions running when I'm just surfing the web normally as opposed to working on a site.
As an aside, put IE6 in "standards mode" with a doctype declaration of "strict", and that "plethora" abruptly collapses to "a few".
Wow. No. Not even remotely. Even in "standards" mode, Internet Explorer 6 is one of the buggiest pieces of software I have ever come across. Its bugs are quite frankly bizarre and even intended deviations from spec (e.g. "hasLayout") went undocumented for years until somebody reverse-engineered it.
overflow-y is a proprietary Internet Explorer property. It has been included in a CSS 3 draft specification, but hasn't reached the stage where the W3C thinks it is ready for implementation. Mozilla shouldn't have included support for it without using a vendor prefix, I'm guessing they jumped the gun for Internet Explorer compatibility. It's not really something you can blame Opera for holding back on.
Although it does sound a bit anti-Microsoft on Google's part, telling users to switch to another browser, and not offering a direct link to IE7
Internet Explorer 7 has been pushed by Microsoft as an automatic critical update for over two years. Everybody who is able and willing to install it already has. The only people left on Internet Explorer 6 are the people who can't or won't upgrade. So what's the point in suggesting they do so?
Don't misquote him and then argue against the misquotation. He said the license criteria are derived from the FSF's. You changed it to the licenses. He's talking about how the Open Source Definition was based on the Debian Free Software Guidelines, and he's absolutely right.
By threatening to send him an invoice, they are tacitly admitting that the work to deliberate over which of the images should be taken down is billable. And, of course, by not providing a list of which images should be taken down, they are requiring him to do this billable work.
So the response is clear. First he should perform this work they are requiring of him: for each image, decide whether or not it should be taken down. End result: he has decided that none of them need to be taken down. Now, since he has performed this work for each and every image on the site - under their instruction - he should invoice them with a small charge for each image. What are they going to do, claim that this work is not billable? They've already admitted it is.
So? The person you were responding to said he was using HTML. And the thing I took issue with was your claim that "both HTML and XHTML require paragraphs to have end tags". It's not "a technicality" to point out how wrong this is, it's a basic fact about the syntax rules, the very topic of discussion.
that's why it's better to write line breaks as <br/>
No! It's better to write line breaks as <br> when you are using HTML, like the OP said he was, and as <br/> when you are using XHTML. You don't just pick one that is "better" because neither is better, one is always wrong for HTML and one is always wrong for XHTML.
this ensures that your code will be future-proof.
No, it doesn't. Adhering to the syntax rules of the document type you are using aids transitions, fucking things up by doing things like using XHTML syntax in an HTML document only makes it more difficult to do automatic conversions because you are working with non-standard code.
to quote the W3C
Most developers can't "migrate to XHTML today" because Internet Explorer doesn't support it. And in any case, migrating to XHTML and using XHTML syntax in an HTML document are two entirely different things. You want to tell him to use XHTML instead of HTML? Go ahead. I'll disagree with your subjective opinion, but you won't be objectively incorrect. But you want to tell somebody using HTML that he should write <br/> ? No. Wrong. And pointing out that the W3C tells people that migrating to XHTML is good can't save you with that.
besides, closing non-empty elements you make the code more organized/legible.
Perhaps that says more about the complexity of your pages than your skills.
I wasn't trying to say anything about my skills, I was trying to say something about the difference between programming and markup.
For example, it's very difficult to get a three column fluid layout that a) works cross-platform and b) validates.
Not particularly, not when you know the common techniques, e.g. the "holy grail". But any difficulty in that situation has nothing to do with the validity of your HTML, it has to do with understanding the CSS rendering model.
There are lots of mid-level cases where HTML becomes convoluted because the presentation isn't a simple flat document. It's very difficult to keep that kind of document standards compliant without using a syntax checker that respects those standards
Why? Simple syntax highlighting catches the typos, indentation catches nesting errors and forgotten closing tags, which just leaves the content model for you to remember. You really find it difficult to believe that a decade isn't long enough to memorise something as simple as HTML? Maybe if you've spent the whole time coasting and not bothering with QA, but if you actually use a validator, and get exposed to what is and isn't correct, how can you not pick it up?
It is inside a URL for crying out loud, did W3C forget that URLs can use &any-word=something-else?
Yes, it's inside a URL. And that URL is inside HTML for crying out loud. Did you forget that ampersands need to be encoded inside HTML?
Someone should rub it in W3Cs nose that they aren't perfect either. (i shall be doing so in a second)
Please, just grow up instead. It's like whining that a spelling checker is pointing out mistakes. Just because somebody builds a tool to find errors, it doesn't mean they are attacking you or saying that they are perfect themselves, and pointing out things that they've got wrong doesn't make your mistakes disappear.
The problem you describe is really only an issue if you are hooking into the load event of the window object, which only fires after each and every embedded resource - images, ads, etc) has finished loading. There are alternative ways of executing JavaScript before this time, and any decent JavaScript framework includes a way of doing so.
IE was the first browser to implement CSS 2 as specced by the W3C, who then, faced with a working implementation from a large company, decided to make major changes to the spec.
This is quite simply delusional. Here is the first released specification for CSS 2. Go and read the tables section. Go and read the generated content section. Go and find out when Internet Explorer had a working implementation of these features. Then go and inform Microsoft, because they, along with the rest of the world, seem to be under the impression that these are new features in the Internet Explorer 8 betas.
In actual fact, there have been changes made to CSS 2 that make Internet Explorer more compatible. For instance, display: inline-block was originally an Internet Explorer proprietary feature that was added to CSS 2.1.
If you haven't validated an HTML page, you can fairly safely assume it's not valid HTML. Just like if you type in a program and never run it through a compiler, it probably has a syntax error in it somewhere.
Actually, I've been writing HTML for about a decade, and programming for about fifteen years, and I find that my HTML is usually valid on the first attempt, even though the same is not true of programs I write. I think perhaps it's because the syntax is simpler. It's easier to spot an unclosed tag than it is a missing semicolon because syntax highlighting gives it away much more readily.
But yes, you should validate routinely, or better yet, incorporate validation into your development practices. For instance, I like to use WSGI middleware that automatically validates each page, and if there are any errors (including on pages generated in response to a POST), they are displayed prominently in the page itself. As soon as I make a mistake, I see it. And I use XML-based template engine, so if there's a formedness error, it doesn't even get that far. When you make it impossible to ignore your mistakes, you end up making far fewer.
Slashdot Mirror
Yes, when Internet Explorer 8 is released, Microsoft will finally have implemented decent support for CSS 2, a specification published over a decade ago. I hope everybody here on Slashdot will join me in welcoming Microsoft to 1998. Truly, they deserve all the credit they are going to get for being so ahead of the curve. Keep innovating, Microsoft! Don't let those slow-coaches at the W3C hold you back!
I know you are kidding, but since they restarted Internet Explorer development, Microsoft have submitted thousands of testcases to the W3C CSS Test Suite, which were welcomed and almost entirely accepted without change.
I spent 60 seconds on Google and found the draft. Next time don't be so lazy.
Coincidentally, the first draft for Back to the Future had a fridge for the time machine, but that was changed because the director thought it would end up with kids watching the film, playing around climbing into fridges, and getting trapped.
It's possible to link up an iPhone's accelerometer to the simulator, and it's also possible to link up the accelerometer in a MacBook to the simulator as well. More details here. Honestly, though, it's probably easier to just jailbreak your iPhone.
I've been a web developer for just over a decade now. Yes, I developed for Netscape 4. It wasn't half as bad as Internet Explorer 6 in terms of bugs. You're forgetting that it just simply didn't support anywhere near as much of the specs as Internet Explorer 6. It has far fewer bugs simply because there was less of it in total. Had it attempted to cover as much of the specs as Internet Explorer 6 did, then I'm sure that it would have been buggier. But it didn't and it wasn't.
But Netscape 4 is just a distraction. Even if it were buggier than Internet Explorer 6, that doesn't make Internet Explorer 6 any less buggy. So what's your point? Just as an excuse to say that I don't know what I am talking about? I supported Netscape 4 for years. I know buggy software. And I stand by my claim that Internet Explorer 6 is one of the most buggiest pieces of software I have ever known.
So what you're saying is that as long as you don't count all the buggy bits of Internet Explorer 6, it isn't so buggy?
Why are you bringing up XHTML? I didn't say that Internet Explorer 6 was buggy because it didn't support XHTML, I said it was buggy even in "standards" mode, which is the mode that the HTML Strict document type puts Internet Explorer 6 into. I didn't define buggy the way you say, I didn't mention XHTML at all, you are attacking a straw man of your own construction.
Gecko is large and unwieldy compared to Webkit. When Apple decided to build a browser, they hired ex-Mozilla developers, who promptly turned around and used KHTML because it was so much leaner and better designed, despite their extensive experience with Gecko.
It's far from obvious that Firefox is ahead in the technology stakes. It trails in many ways and seems like a far less agile project compared with Webkit and Opera. It does have a few areas where it is ahead, but the downsides seem like an albatross to me.
I totally agree in the context of family members sharing a computer, but I find profiles useful because I'm a web developer and I don't want lots of toolbars taking up screen space and development extensions running when I'm just surfing the web normally as opposed to working on a site.
Wow. No. Not even remotely. Even in "standards" mode, Internet Explorer 6 is one of the buggiest pieces of software I have ever come across. Its bugs are quite frankly bizarre and even intended deviations from spec (e.g. "hasLayout") went undocumented for years until somebody reverse-engineered it.
overflow-y is a proprietary Internet Explorer property. It has been included in a CSS 3 draft specification, but hasn't reached the stage where the W3C thinks it is ready for implementation. Mozilla shouldn't have included support for it without using a vendor prefix, I'm guessing they jumped the gun for Internet Explorer compatibility. It's not really something you can blame Opera for holding back on.
Internet Explorer 7 has been pushed by Microsoft as an automatic critical update for over two years. Everybody who is able and willing to install it already has. The only people left on Internet Explorer 6 are the people who can't or won't upgrade. So what's the point in suggesting they do so?
No, there are commercials about boys. For instance, this one, where the boy is advertised as a future wife-beater.
Don't misquote him and then argue against the misquotation. He said the license criteria are derived from the FSF's. You changed it to the licenses. He's talking about how the Open Source Definition was based on the Debian Free Software Guidelines, and he's absolutely right.
By threatening to send him an invoice, they are tacitly admitting that the work to deliberate over which of the images should be taken down is billable. And, of course, by not providing a list of which images should be taken down, they are requiring him to do this billable work.
So the response is clear. First he should perform this work they are requiring of him: for each image, decide whether or not it should be taken down. End result: he has decided that none of them need to be taken down. Now, since he has performed this work for each and every image on the site - under their instruction - he should invoice them with a small charge for each image. What are they going to do, claim that this work is not billable? They've already admitted it is.
I never believed it. I mean, a web development platform even worse than PHP? How gullible do you think I am?
In case anybody missed it, the "Church" of Scientology successfully censored Slashdot. Using the DMCA, which is currently being praised on the front page of Slashdot right now.
Yeah, to give some idea of just how non-news this is, I first noticed this effect when Slashdot was called Chips & Dips.
Well we are discussing a technical matter...
So? The person you were responding to said he was using HTML. And the thing I took issue with was your claim that "both HTML and XHTML require paragraphs to have end tags". It's not "a technicality" to point out how wrong this is, it's a basic fact about the syntax rules, the very topic of discussion.
No! It's better to write line breaks as <br> when you are using HTML, like the OP said he was, and as <br /> when you are using XHTML. You don't just pick one that is "better" because neither is better, one is always wrong for HTML and one is always wrong for XHTML.
No, it doesn't. Adhering to the syntax rules of the document type you are using aids transitions, fucking things up by doing things like using XHTML syntax in an HTML document only makes it more difficult to do automatic conversions because you are working with non-standard code.
Most developers can't "migrate to XHTML today" because Internet Explorer doesn't support it. And in any case, migrating to XHTML and using XHTML syntax in an HTML document are two entirely different things. You want to tell him to use XHTML instead of HTML? Go ahead. I'll disagree with your subjective opinion, but you won't be objectively incorrect. But you want to tell somebody using HTML that he should write <br /> ? No. Wrong. And pointing out that the W3C tells people that migrating to XHTML is good can't save you with that.
The topic here is validity, not legibility.
I wasn't trying to say anything about my skills, I was trying to say something about the difference between programming and markup.
Not particularly, not when you know the common techniques, e.g. the "holy grail". But any difficulty in that situation has nothing to do with the validity of your HTML, it has to do with understanding the CSS rendering model.
Why? Simple syntax highlighting catches the typos, indentation catches nesting errors and forgotten closing tags, which just leaves the content model for you to remember. You really find it difficult to believe that a decade isn't long enough to memorise something as simple as HTML? Maybe if you've spent the whole time coasting and not bothering with QA, but if you actually use a validator, and get exposed to what is and isn't correct, how can you not pick it up?
Yes, it's inside a URL. And that URL is inside HTML for crying out loud. Did you forget that ampersands need to be encoded inside HTML?
Please, just grow up instead. It's like whining that a spelling checker is pointing out mistakes. Just because somebody builds a tool to find errors, it doesn't mean they are attacking you or saying that they are perfect themselves, and pointing out things that they've got wrong doesn't make your mistakes disappear.
The problem you describe is really only an issue if you are hooking into the load event of the window object, which only fires after each and every embedded resource - images, ads, etc) has finished loading. There are alternative ways of executing JavaScript before this time, and any decent JavaScript framework includes a way of doing so.
This is quite simply delusional. Here is the first released specification for CSS 2. Go and read the tables section. Go and read the generated content section. Go and find out when Internet Explorer had a working implementation of these features. Then go and inform Microsoft, because they, along with the rest of the world, seem to be under the impression that these are new features in the Internet Explorer 8 betas.
In actual fact, there have been changes made to CSS 2 that make Internet Explorer more compatible. For instance, display: inline-block was originally an Internet Explorer proprietary feature that was added to CSS 2.1.
No, WCAG is an instance of a specification that can't be machine-checked, because human judgment comes into it. For example, checkpoint 14.1:
You don't think that's a grey area?
Actually, I've been writing HTML for about a decade, and programming for about fifteen years, and I find that my HTML is usually valid on the first attempt, even though the same is not true of programs I write. I think perhaps it's because the syntax is simpler. It's easier to spot an unclosed tag than it is a missing semicolon because syntax highlighting gives it away much more readily.
But yes, you should validate routinely, or better yet, incorporate validation into your development practices. For instance, I like to use WSGI middleware that automatically validates each page, and if there are any errors (including on pages generated in response to a POST), they are displayed prominently in the page itself. As soon as I make a mistake, I see it. And I use XML-based template engine, so if there's a formedness error, it doesn't even get that far. When you make it impossible to ignore your mistakes, you end up making far fewer.
"Damn idiots shouldn't have chosen to be blind in the first place!"