No. It's a buzzword. It doesn't even have a precise meaning, it's certainly not a standard. Roughly, most people understand it to mean "Javascript that changes the page contents and style". Netscape invented DHTML, it's not some Internet Explorer only thing. And, supporting the DOM and CSS far better than Internet Explorer, Firefox is in no way deficient when it comes to "DHTML".
None of IE's standards deficiencies happen to bother my browsing experience.
Yes, they do. If Internet Explorer wasn't so broken, there'd be thousands of web developers working on new features and content for their websites - stuff that matters to you - instead of spending ages working around Internet Explorer.
Er, XML is an SGML application profile. XHTML might be built on top of XML, but XML is built on top of SGML.
Just as you can't write an HTML parser without understanding the non-open SGML, you can't write an XML parser (and consequently and XHMTL parser) without understanding the non-open SGML.
You're right that the First Amendment protects only your ability to speak and publish whatever you want.
The First Amendment doesn't protect free speech, it protects free speech from Congress. It's much narrower than people generally assume.
The right to free speech, like any other right, is not some narrow, situational privilege.
Agreed. But there's a vast difference between the right to free speech and the First Amendment which merely protects that right from the government.
Whether the government or a private entity infringes those rights, they're being infringed. And it's the government's purpose to protect them from infringement. So the government is required to stop private parties from infringing those rights.
Why is the government required to do so? The First Amendment certainly doesn't require it.
Re:"Graceful Degradation" = Don't Use It.
on
DHTML Utopia
·
· Score: 1
Unnecessary != not useful. Possibly buggy is irrelevent so long as you test properly.
Does it take an Einstein to see which is the lowest-cost, lowest-bandwidth, most reliable solution?
Does it take an Einstein to realise that it depends on what you are doing?
Example: If you have something like Hotmail's signup page, you can save bandwidth by using XMLHttpRequest, because you'll get a hell of a lot of people constantly going back and forth on the registration pages trying to get a username that isn't already taken. Those registration pages might be in the region of 40K per request or more. An XMLHttpRequest script could do it in around 1K per request.
As with anything else, declaring one thing to be the best solution in all situations is a blanket statement that doesn't hold true in all cases.
This is an application of Occam's Razor: use only what is necessary and avoid unnecessary complication.
So you don't use CSS or images either then? Even links are unnecessary, users can copy & paste the URIs or type them in by hand. Maybe what's necessary isn't the only thing that's important.
It also reduces your cache hits, increasing server load and bandwidth costs, and slowing down your website.
Your code is broken, BTW. You need to transmit a Vary header when you vary content based upon request headers, otherwise you can screw up caches so they send application/xhtml+xml to Internet Explorer.
You're going to tell me once more that IE6 in strict mode doesn't have this problem and I must be in quirks mode, but I assure you that in the circumstances I described, IE6 in strict mode most definitely does calculate box widths incorrectly, resulting in incorrect positioning of those boxes.
If that's true, then don't bother posting it to Slashdot, post it to the IEBlog so that they can fix it.
The Internet Explorer developers believe that they've finished support for CSS 1, but if you read the comments in TFA, nobody's quite sure yet. It's feature complete (finally!) in terms of CSS 1 support (the only thing lacking was fixed backgrounds), but there might still be a few bugs lurking.
Quite a lot, I would imagine, as the majority of "CSS hacks" are based around Internet Explorer's lack of support for CSS 2 selectors, which will be fixed in the next beta.
Come on, you're kidding, right? The smiley face is just a gimmick. The parts of HTML, CSS, etc that are used to create it aren't.
how many 3-column websites with links and graphics actually benefit
Off the top of my head, websites with multi-column layouts benefit from display: table-cell support and websites with graphics benefit from data: URIs. Both of these are practical to implement and tested by Acid2.
The test is used to test whether a page will render pages that are not 100% compliant.
No. Lots of people have said this, it's misleading. It's true that one of the things Acid2 tests is error handling. That's one checkpoint on a list of over a dozen items.
Personally I prefer that my browser does not render non-compliant pages.
The CSS specification includes mandatory error handling. If a browser acts in the way you describe, it will be rendering pages in a non-standard way.
The Acid2 test has to include invalid CSS. The CSS specification describes mandatory error handling. The only way to test if a browser conforms to this is to include invalid CSS and see if the browser acts as it should.
actually any standards-compliant browser will produce the same output given standards-compliant html or css.
This is nonsense. Both HTML and CSS are built around the concept that rendering should vary depending on the circumstances. You will never get consistent rendering, because varying presentations is one of the primary benefits of the web.
Example: how wide does this make elements?
* { width auto; padding: 10em; }
Answer: even if you use nothing but completely conformant browsers it depends on at least:
Font settings
Windows size
Scrollbar width
Screen resolution
Monitor size
The user-agent stylesheet
And that's assuming that the users hasn't done anything like used a user stylesheet (part of the CSS specifications) or Greasemonkey.
Early on, browser developers made a huge mistake - accepting invalid html and making a best-effort to render it by assuming defaults for uninitialized values.
There is a more subtle reason why browsers absolutely will not ever comply with any modern HTML specification: the specifications aren't entirely open.
You see, HTML is based on SGML. SGML is not an open standard - you have to pay ISO to get a copy of it. Unsurprisingly, when people were developing early web browsers, they just winged it and wrote something that worked with all the examples they could find.
HTML, in order to make things easier for authors, included a few SGML shortcuts so you could do things like <input disabled> instead of <input disabled=disabled>. Because of this, one of the shortcuts that HTML inherited was the ability to write <foo/bar/ as a substitute for <foo>bar</foo>.
Of course, because none of the browser developers had read the SGML standard, they were completely unaware of this shortcut. By the time browser development "grew up" and the developers started reading the specs, it was too late. There were enough broken HTML documents out there that made it impossible to fix this bug.
RFC 2854 was the final nail in the coffin - it permitted authors to transmit some XHTML documents as text/html. The empty element syntax of XHTML is incompatible with these shortcuts, so every XHTML-as-text/html document on the web is another reason why browsers can't render HTML 100% according to spec.
Any flaw in XML data no matter how benign or subtle causes the entire stream to be rejected outright.
This is not true either. Only flaws that make a document malformed cause parsers to throw a fatal error; flaws that make a document invalid don't.
If success is defined as enhancing your job security, then boobytrap your code with misleading comments to make it impossible for anybody else to work on it.
Freenet is a peer-to-peer network designed to allow the distribution of information over the Internet in an efficient manner, without fear of censorship.
Freenet implements free speech, nothing more. It won't encourage or enable criminal behavior that wouldn't have happened without it, and it might actually help us better understand and deal with criminals. While our hope is that people under oppressive governments can use Freenet to describe their plight without retribution, it is also possible for a terrorist to publish on Freenet why he chose to bomb a building or hijack a plane.
Freenet's political goal isn't revisionist history. Implying that it's intended for copyright infringement is.
Comparing web development to something like third world hunger is absurd.
It's called an analogy. I was using it to demonstrate that a person need not be fully informed about the reasons why something happens in order to care that it is happening. Your previous comment was asserting that if you aren't fully informed about something then you can't care about it.
As for features, what? Another form, shopping cart or method of net marketing? Great! More insidious pop-under banners telling me to get a big "hoo-hoo" or grow hair on a cue ball.
Don't be so silly. Not all features are bad. Example: the time spent to fix Internet Explorer issues could have been spent setting up a local search, or an Atom feed, or a mobile version, or text alerts, or anything really.
There's no sensible reason to assume that any further development time would be harmful to the end-user.
Get a clue. The majority of people have no idea what's under the hood.
I know that perfectly well. Did you not read my last comment properly?
Buy their software? Who pays for net software? I don't think I've ever paid for net software.
Who said anything about buying software?
As for the extra cost, we grumble and pay.
So you are conceding that you care about extra cost then?
Slashdot Mirror
It isn't a standard, but the parts (sans javascript, sorta) are.
Javascript syntax was formalised in the ECMA-262 standard.
Isn't DHTML a standard?
No. It's a buzzword. It doesn't even have a precise meaning, it's certainly not a standard. Roughly, most people understand it to mean "Javascript that changes the page contents and style". Netscape invented DHTML, it's not some Internet Explorer only thing. And, supporting the DOM and CSS far better than Internet Explorer, Firefox is in no way deficient when it comes to "DHTML".
None of IE's standards deficiencies happen to bother my browsing experience.
Yes, they do. If Internet Explorer wasn't so broken, there'd be thousands of web developers working on new features and content for their websites - stuff that matters to you - instead of spending ages working around Internet Explorer.
XHTML is derived from XML, not SGML.
Er, XML is an SGML application profile. XHTML might be built on top of XML, but XML is built on top of SGML.
Just as you can't write an HTML parser without understanding the non-open SGML, you can't write an XML parser (and consequently and XHMTL parser) without understanding the non-open SGML.
You're right that the First Amendment protects only your ability to speak and publish whatever you want.
The First Amendment doesn't protect free speech, it protects free speech from Congress. It's much narrower than people generally assume.
The right to free speech, like any other right, is not some narrow, situational privilege.
Agreed. But there's a vast difference between the right to free speech and the First Amendment which merely protects that right from the government.
Whether the government or a private entity infringes those rights, they're being infringed. And it's the government's purpose to protect them from infringement. So the government is required to stop private parties from infringing those rights.
Why is the government required to do so? The First Amendment certainly doesn't require it.
Unnecessary != not useful. Possibly buggy is irrelevent so long as you test properly.
Does it take an Einstein to see which is the lowest-cost, lowest-bandwidth, most reliable solution?
Does it take an Einstein to realise that it depends on what you are doing?Example: If you have something like Hotmail's signup page, you can save bandwidth by using XMLHttpRequest, because you'll get a hell of a lot of people constantly going back and forth on the registration pages trying to get a username that isn't already taken. Those registration pages might be in the region of 40K per request or more. An XMLHttpRequest script could do it in around 1K per request.
As with anything else, declaring one thing to be the best solution in all situations is a blanket statement that doesn't hold true in all cases.
This is an application of Occam's Razor: use only what is necessary and avoid unnecessary complication.
So you don't use CSS or images either then? Even links are unnecessary, users can copy & paste the URIs or type them in by hand. Maybe what's necessary isn't the only thing that's important.
Content negotiation is an old concept.
It also reduces your cache hits, increasing server load and bandwidth costs, and slowing down your website.
Your code is broken, BTW. You need to transmit a Vary header when you vary content based upon request headers, otherwise you can screw up caches so they send application/xhtml+xml to Internet Explorer.
You're going to tell me once more that IE6 in strict mode doesn't have this problem and I must be in quirks mode, but I assure you that in the circumstances I described, IE6 in strict mode most definitely does calculate box widths incorrectly, resulting in incorrect positioning of those boxes.
If that's true, then don't bother posting it to Slashdot, post it to the IEBlog so that they can fix it.
It then goes on to say "we have already fixed the following bugs" - indicating that everything in the list is part of the 1st beta.
No, you are reading too much into what they say. When they say "we've fixed [x]", they mean "we've fixed [x]", not "we fixed [x] for beta 1".
Mind you, the post does come from the same author who thinks that 2.1 isn't the current CSS recommendation.
It's not. It's been moved back to working draft status.
Will it even fully support just pure CSS1?
The Internet Explorer developers believe that they've finished support for CSS 1, but if you read the comments in TFA, nobody's quite sure yet. It's feature complete (finally!) in terms of CSS 1 support (the only thing lacking was fixed backgrounds), but there might still be a few bugs lurking.
Dave's post refers to what is fixed in beta 1, TFA is talking about what is fixed in beta 2 and the goals for final release.
Quite a lot, I would imagine, as the majority of "CSS hacks" are based around Internet Explorer's lack of support for CSS 2 selectors, which will be fixed in the next beta.
Fix the box model
They did that four years ago, when they released Internet Explorer 6.0.
Fix inheritance issues
They are asking for examples on the weblog; feel free to post a testcase or two.
Implement :hover: correctly
RTFA. They have fixed this for the next beta
CSS doesn't have tags. It has properties, values, selectors, blocks... no tags.
Data URIs are not somebody's "pet project". They are a standards-track IETF RFC.
What Acid2 is designed to test is the browser's resilience to errors.
This is wrong. Please stop spreading this mistruth.
CSS 2.1 isn't a standard. It isn't even a recommendation at this point. The data: URI scheme, on the other hand, is an IETF standards track RFC.
Come on, you're kidding, right? The smiley face is just a gimmick. The parts of HTML, CSS, etc that are used to create it aren't.
how many 3-column websites with links and graphics actually benefit
Off the top of my head, websites with multi-column layouts benefit from display: table-cell support and websites with graphics benefit from data: URIs. Both of these are practical to implement and tested by Acid2.
The test is used to test whether a page will render pages that are not 100% compliant.
No. Lots of people have said this, it's misleading. It's true that one of the things Acid2 tests is error handling. That's one checkpoint on a list of over a dozen items.
Personally I prefer that my browser does not render non-compliant pages.
The CSS specification includes mandatory error handling. If a browser acts in the way you describe, it will be rendering pages in a non-standard way.
The Acid2 test has to include invalid CSS. The CSS specification describes mandatory error handling. The only way to test if a browser conforms to this is to include invalid CSS and see if the browser acts as it should.
actually any standards-compliant browser will produce the same output given standards-compliant html or css.
This is nonsense. Both HTML and CSS are built around the concept that rendering should vary depending on the circumstances. You will never get consistent rendering, because varying presentations is one of the primary benefits of the web.
Example: how wide does this make elements?
Answer: even if you use nothing but completely conformant browsers it depends on at least:
And that's assuming that the users hasn't done anything like used a user stylesheet (part of the CSS specifications) or Greasemonkey.
Early on, browser developers made a huge mistake - accepting invalid html and making a best-effort to render it by assuming defaults for uninitialized values.
There is a more subtle reason why browsers absolutely will not ever comply with any modern HTML specification: the specifications aren't entirely open.
You see, HTML is based on SGML. SGML is not an open standard - you have to pay ISO to get a copy of it. Unsurprisingly, when people were developing early web browsers, they just winged it and wrote something that worked with all the examples they could find.
HTML, in order to make things easier for authors, included a few SGML shortcuts so you could do things like <input disabled> instead of <input disabled=disabled>. Because of this, one of the shortcuts that HTML inherited was the ability to write <foo/bar/ as a substitute for <foo>bar</foo>.
Of course, because none of the browser developers had read the SGML standard, they were completely unaware of this shortcut. By the time browser development "grew up" and the developers started reading the specs, it was too late. There were enough broken HTML documents out there that made it impossible to fix this bug.
RFC 2854 was the final nail in the coffin - it permitted authors to transmit some XHTML documents as text/html. The empty element syntax of XHTML is incompatible with these shortcuts, so every XHTML-as-text/html document on the web is another reason why browsers can't render HTML 100% according to spec.
Any flaw in XML data no matter how benign or subtle causes the entire stream to be rejected outright.
This is not true either. Only flaws that make a document malformed cause parsers to throw a fatal error; flaws that make a document invalid don't.
<blink> was Netscape, not Internet Explorer. And its CSS equivelant, text-decoration: blink, will not be in Internet Explorer 7.
So, you think that a browser that automatically downloads a file without your knowledge is secure?
Most browsers do this. Do you get notified when your browser automatically downloads a stylesheet? Javascript? Uses XMLHttpRequest?
Downloading files is benign. It's executing them that is harmful, and that clearly didn't happen in this case.
If success is defined as enhancing your job security, then boobytrap your code with misleading comments to make it impossible for anybody else to work on it.
From the Wayback Machine archive of May 2000:
Another page from the Wayback Machine:
Freenet's political goal isn't revisionist history. Implying that it's intended for copyright infringement is.
Comparing web development to something like third world hunger is absurd.
It's called an analogy. I was using it to demonstrate that a person need not be fully informed about the reasons why something happens in order to care that it is happening. Your previous comment was asserting that if you aren't fully informed about something then you can't care about it.
As for features, what? Another form, shopping cart or method of net marketing? Great! More insidious pop-under banners telling me to get a big "hoo-hoo" or grow hair on a cue ball.
Don't be so silly. Not all features are bad. Example: the time spent to fix Internet Explorer issues could have been spent setting up a local search, or an Atom feed, or a mobile version, or text alerts, or anything really.
There's no sensible reason to assume that any further development time would be harmful to the end-user.
Get a clue. The majority of people have no idea what's under the hood.
I know that perfectly well. Did you not read my last comment properly?
Buy their software? Who pays for net software? I don't think I've ever paid for net software.
Who said anything about buying software?
As for the extra cost, we grumble and pay.
So you are conceding that you care about extra cost then?