AC is right. XHTML 1.0 is almost identical to HTML 4.01 semantically. Element types like <b> and <i> aren't deprecated in either. Read the specs.
Re:No more compound documents?
on
XHTML 2 Cancelled
·
· Score: 4, Informative
Unlike HTML 4, HTML 5 doesn't specify the representation. It has SGML and XML bindings. HTML 5 with the SGML binding looks like classic HTML
No, HTML 5 has an XML serialisation and a tag-soup-compatible serialisation that, yes, looks like classic HTML, but in fact isn't based on SGML. It's based on the way popular browsers parse HTML rather than what they are supposed to do according to previous HTML specifications. One consequence of this is that obscure parts of previous versions of HTML that are not well-supported by popular browsers are not supported by HTML 5 - it's not completely backwards-compatible with previous versions of HTML.
When you submit an app to the App Store, you already have to select various categories your app falls into (e.g. you might select realistic violence: frequent/intense), which result in a rating that is a direct analogue of ESRB ratings (Apple publishes a table showing the equivalents). iPhone OS 3.0 will make use of these ratings so a parent can lock out content they think is inappropriate from their children's phones. Apple have shown themselves more than willing to lay down the law to app developers, so why would the ESRB need to get involved?
hat does that have to do with the lack of development for anything other than Windows?
Lack of development? There is development happening for OS X and Linux. It's just not ready for end-users yet.
What does Mozilla's head start have to do with the fact that they are apparently able to do cross-platform development better than a company who has vastly more people and money at their disposal?
Because development isn't simply a matter of money. It takes time to develop software, and organisational/human/communication factors impose an upper limit on how fast development can move. Mozilla have a codebase where 15 years have been spent in development. No amount of money can compensate for that head-start. Mozilla aren't developing any faster than Google, they are further ahead because they've been doing it longer.
Even the original releases of Netscape were cross-platform
The original releases of Netscape were far, far simpler products. I could write "Hello, World" in 30 seconds that would run on more platforms than Chrome - does that make me better than Google? No, because the task of writing a modern web browser is substantially greater than writing "Hello, World" - and substantially greater than writing an early 90s web browser.
So basically even at the start when they had even less resources they were somehow able to do better cross-platform development than a multibillion dollar, multinational company.
Yes, because they had less to do. If your codebase is a fraction of the size and has only a handful of features, of course it's easier to port it to other systems. By the way, have you tried running those early Netscape versions on Linux and OS X?
The first beta of Chrome was released about six months ago. Mozilla's codebase is about 15 years old. You do understand that Mozilla have had a substantial head-start, right?
If you pull up a copy of Netscape Navigator 4.0 you'll find that most things are still identical to today's browsers.
Hardly. The atrocious CSS support in Netscape Navigator 4 was based around transcoding to JSSS - it was a last-minute bolt-on. There's virtually nothing in common with today's browsers, rendering-wise. Same goes for the DOM - back then, there were essentially two incompatible APIs, now we have standardised ECMAScript and a DOM that is mostly compatible, not counting events. The methods available for extending browsers have changed dramatically, with things like user JavaScript and Firefox's addons taking the place of plugins. There's countless ways in which the technologies have been pushed forwards. To refute your examples, Opera has full-text search across your entire browsing history.
I could list more and more examples but I think you get my point.
But examples can't prove your point. Sure, you can make up features you would like to see, and you can complain that they haven't been implemented, but that doesn't mean browsers have stagnated, because there are plenty of other examples of browser technology improving.
Believe it or not, fonts as in the actual shapes of the letters are copyright protected
Actually, this is not true, at least in the USA. The shapes themselves are not copyrightable. You'll find that many fonts are just copies of more reputable fonts. Arial is quite famous for being a poor copy of Helvetica. What is copyrightable is the font file itself, as it is considered a program. Also, a design patent can cover a novel typeface, but this situation is quite rare I believe.
HINT: Cars require licensing because failure to operate one safely potentially results in the deaths of many people. Computers can only potentially result in yourself being harmed in a non-corporeal way.
Harm to a computer is not too trivial for the government to step in and legislate against, as evidenced by the numerous computer misuse laws around the world.
The analogy is that you drive an unmaintained car, after being sold that car with assurance that it requires zero maintenance and "just works", when the car manufacturer knows damn well that it will never work properly and is almost certain to get broken into and driven by others at will from time to time.
Which software vendor claims to be 100% secure with zero maintenance? All common consumer operating systems come configured for maintenance updates out-of-the-box, and these are usually touted as features to the end-user. You have to choose not to apply them, which puts the responsibility firmly with the owner of the computer.
This is the trouble with people saying the first half of a saying and then trailing off. The people who know the saying get the point, and the people who don't remember a fragment and repeat it even though it makes no sense on its own.
To the people tagging this "embraceandextend". Embracing and extending is not a particularly bad thing to do. Many formats, including XML (upon which ODF is based), are built with this in mind. The complete saying that is referred to with "embrace and extend" is embrace, extend and extinguish. The extinguishing is the goal here, the former two are merely tools to help them achieve this.
Let's not limit this to computers. If someone breaks into your house or steals your car, cell phone, credit card, etc. then you should be responsible for all crimes committed by the thief. You are not just a victim, you are an accomplice. If you cannot reasonably protect yourself from physical theft by learning martial arts and proper use of firearms/weapons, you should just stick to...computers?
You've latched onto the wrong thing here. The key is not that you should be responsible to avoid becoming a victim, the key is that you should be responsible for the equipment you are operating causing harm to others. The analogous situation would be driving an unmaintained car. For instance, here in the UK, cars must undergo an MOT every year to determine that they are safe for the road. If a car owner skips their MOT and is involved in an accident, they are in big trouble. In addition, before driving that car, the person must show themselves to be capable of operating it with a degree of skill that is reasonable to avoid harm to others. To turn this back around, the analogous situation with computers would be a course before people are allowed onto the Internet to teach people not to run random executables etc., and a requirement to install all available security patches as part of their ongoing maintenance.
Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.
There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?
It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.
Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?
HTML was syntactically incompatible with SGML on purpose to make it "easier" to use. The most notable example is the fact that early in the HTML standard, you didn't have to close paragraph elements.
You still don't have to close paragraph elements, even in the SGML-formalised modern HTML specifications. This is not an incompatibility with SGML at all, as SGML allows markup languages to have element types that do not require end tags. Perhaps you are thinking of XML, which arose a long time after HTML?
The reason why the App Store has taken off so phenomenally is because they handle commercial applications. This means that any geek who can knock together a mobile application is tempted to do so by potential profits. Think about it, write an app, get it approved, and then instantly make it available to millions of iPhone users who are only a click away from paying you. That's a huge advantage for Apple - because those geeks will be writing their applications for the iPhone and not the other platforms. This is why there are so many applications for the iPhone already. Apple were really smart here. If you look at the numbers, there are more 99c applications than free applications, and taken as a whole, free applications are a minority.
Android Market is soon going to be rolling out support for paid applications in much the same way as the App Store. Once this happens, you'll see a similar surge in the number of applications available for Android. It won't be as pronounced as the App Store's curve, because Apple have a head-start now, but it will certainly put Android in the game. Although the iPhone has the client numbers, Android has the developer numbers simply because you don't need a Mac to develop Android applications.
Acid3 covers some standards which aren't even final yet, such as CSS3.
This is highly misleading.
The criteria for the Acid3 tests included the requirement that they be justifiable using only specifications that were in the Candidate Recommendation stage or better in 2004. Weblog article from the author of the test here. Candidate Recommendation stage is the point at which browsers should be implementing the specifications. You can't get to full Recommendation status until two or more browsers have implemented them.
So yes, they weren't "final", but only in the sense that browser implementations were lacking. The specifications were as ready as they could be years before the Acid3 test was announced.
Meanwhile, IE8 does pass Acid2, which indicates correct implementation of HTML4 & CSS2
It indicates no such thing. It's a collection of test-cases for functionality that would be very useful in day-to-day web development if only they were widely implemented correctly. The Acid2 tests do not indicate that a browser has correctly implemented HTML 4 and CSS, only that it has fixed many bugs that it had previously suffered from.
And by the time IE9 is out, there will be something else to support
Actually, by the time Internet Explorer 6 was out, there was something else to support. The DOM 2 Events specification, an intrinsic part of modern JavaScript, was published in 2000, almost a year before Internet Explorer 6, and even the upcoming Internet Explorer 8 still won't have support for it. That's why all the modern JavaScript libraries like jQuery have workaround code to translate the Internet Explorer event model into the standard event model shared by all the other browsers.
So yes, there will be plenty to work on for Internet Explorer 9, but it will be yet more stuff that other browsers implemented years ago, not a moving target.
Slashdot Mirror
AC is right. XHTML 1.0 is almost identical to HTML 4.01 semantically. Element types like <b> and <i> aren't deprecated in either. Read the specs.
No, HTML 5 has an XML serialisation and a tag-soup-compatible serialisation that, yes, looks like classic HTML, but in fact isn't based on SGML. It's based on the way popular browsers parse HTML rather than what they are supposed to do according to previous HTML specifications. One consequence of this is that obscure parts of previous versions of HTML that are not well-supported by popular browsers are not supported by HTML 5 - it's not completely backwards-compatible with previous versions of HTML.
There's an informative lecture on this technology here.
But I wouldn't steal a policeman's helmet!
When you submit an app to the App Store, you already have to select various categories your app falls into (e.g. you might select realistic violence: frequent/intense), which result in a rating that is a direct analogue of ESRB ratings (Apple publishes a table showing the equivalents). iPhone OS 3.0 will make use of these ratings so a parent can lock out content they think is inappropriate from their children's phones. Apple have shown themselves more than willing to lay down the law to app developers, so why would the ESRB need to get involved?
Lack of development? There is development happening for OS X and Linux. It's just not ready for end-users yet.
Because development isn't simply a matter of money. It takes time to develop software, and organisational/human/communication factors impose an upper limit on how fast development can move. Mozilla have a codebase where 15 years have been spent in development. No amount of money can compensate for that head-start. Mozilla aren't developing any faster than Google, they are further ahead because they've been doing it longer.
The original releases of Netscape were far, far simpler products. I could write "Hello, World" in 30 seconds that would run on more platforms than Chrome - does that make me better than Google? No, because the task of writing a modern web browser is substantially greater than writing "Hello, World" - and substantially greater than writing an early 90s web browser.
Yes, because they had less to do. If your codebase is a fraction of the size and has only a handful of features, of course it's easier to port it to other systems. By the way, have you tried running those early Netscape versions on Linux and OS X?
The first beta of Chrome was released about six months ago. Mozilla's codebase is about 15 years old. You do understand that Mozilla have had a substantial head-start, right?
Huh? Straight from the first line of his comment, emphasis added by me:
Hardly. The atrocious CSS support in Netscape Navigator 4 was based around transcoding to JSSS - it was a last-minute bolt-on. There's virtually nothing in common with today's browsers, rendering-wise. Same goes for the DOM - back then, there were essentially two incompatible APIs, now we have standardised ECMAScript and a DOM that is mostly compatible, not counting events. The methods available for extending browsers have changed dramatically, with things like user JavaScript and Firefox's addons taking the place of plugins. There's countless ways in which the technologies have been pushed forwards. To refute your examples, Opera has full-text search across your entire browsing history.
But examples can't prove your point. Sure, you can make up features you would like to see, and you can complain that they haven't been implemented, but that doesn't mean browsers have stagnated, because there are plenty of other examples of browser technology improving.
Actually, this is not true, at least in the USA. The shapes themselves are not copyrightable. You'll find that many fonts are just copies of more reputable fonts. Arial is quite famous for being a poor copy of Helvetica. What is copyrightable is the font file itself, as it is considered a program. Also, a design patent can cover a novel typeface, but this situation is quite rare I believe.
Doesn't the melted chocolate make the servers sticky?
Harm to a computer is not too trivial for the government to step in and legislate against, as evidenced by the numerous computer misuse laws around the world.
Which software vendor claims to be 100% secure with zero maintenance? All common consumer operating systems come configured for maintenance updates out-of-the-box, and these are usually touted as features to the end-user. You have to choose not to apply them, which puts the responsibility firmly with the owner of the computer.
This is the trouble with people saying the first half of a saying and then trailing off. The people who know the saying get the point, and the people who don't remember a fragment and repeat it even though it makes no sense on its own.
To the people tagging this "embraceandextend". Embracing and extending is not a particularly bad thing to do. Many formats, including XML (upon which ODF is based), are built with this in mind. The complete saying that is referred to with "embrace and extend" is embrace, extend and extinguish . The extinguishing is the goal here, the former two are merely tools to help them achieve this.
You've latched onto the wrong thing here. The key is not that you should be responsible to avoid becoming a victim, the key is that you should be responsible for the equipment you are operating causing harm to others. The analogous situation would be driving an unmaintained car. For instance, here in the UK, cars must undergo an MOT every year to determine that they are safe for the road. If a car owner skips their MOT and is involved in an accident, they are in big trouble. In addition, before driving that car, the person must show themselves to be capable of operating it with a degree of skill that is reasonable to avoid harm to others. To turn this back around, the analogous situation with computers would be a course before people are allowed onto the Internet to teach people not to run random executables etc., and a requirement to install all available security patches as part of their ongoing maintenance.
You have fallen for the Galileo fallacy. As Carl Sagan puts it:
You understand wrong. From my usual copy & paste comment on the subject:
You still don't have to close paragraph elements, even in the SGML-formalised modern HTML specifications. This is not an incompatibility with SGML at all, as SGML allows markup languages to have element types that do not require end tags. Perhaps you are thinking of XML, which arose a long time after HTML?
And JavaScript. And cookies. And Java applets. And on-the-fly rendering. And (I think) JPEG support and plug-ins.
Netscape invented JavaScript, while Microsoft added a small JavaScript property. Therefore Microsoft are the innovative ones? Er, no.
Actually, the iPhone has 1.1% of the entire mobile phone market, not just smartphones. So there's about 90 phone owners for a single iPhone owner.
Correction: Android Market gained support for paid applications yesterday, although at the moment, it is restricted to developers from the USA and UK, and consumers from the USA, with more countries to follow.
The reason why the App Store has taken off so phenomenally is because they handle commercial applications. This means that any geek who can knock together a mobile application is tempted to do so by potential profits. Think about it, write an app, get it approved, and then instantly make it available to millions of iPhone users who are only a click away from paying you. That's a huge advantage for Apple - because those geeks will be writing their applications for the iPhone and not the other platforms. This is why there are so many applications for the iPhone already. Apple were really smart here. If you look at the numbers, there are more 99c applications than free applications, and taken as a whole, free applications are a minority.
Android Market is soon going to be rolling out support for paid applications in much the same way as the App Store. Once this happens, you'll see a similar surge in the number of applications available for Android. It won't be as pronounced as the App Store's curve, because Apple have a head-start now, but it will certainly put Android in the game. Although the iPhone has the client numbers, Android has the developer numbers simply because you don't need a Mac to develop Android applications.
Acid3 was deliberately designed to trigger bugs in all major browsers, because they all have problems. How is that biased?
This is highly misleading.
The criteria for the Acid3 tests included the requirement that they be justifiable using only specifications that were in the Candidate Recommendation stage or better in 2004. Weblog article from the author of the test here. Candidate Recommendation stage is the point at which browsers should be implementing the specifications. You can't get to full Recommendation status until two or more browsers have implemented them.
So yes, they weren't "final", but only in the sense that browser implementations were lacking. The specifications were as ready as they could be years before the Acid3 test was announced.
It indicates no such thing. It's a collection of test-cases for functionality that would be very useful in day-to-day web development if only they were widely implemented correctly. The Acid2 tests do not indicate that a browser has correctly implemented HTML 4 and CSS, only that it has fixed many bugs that it had previously suffered from.
Actually, by the time Internet Explorer 6 was out, there was something else to support. The DOM 2 Events specification, an intrinsic part of modern JavaScript, was published in 2000, almost a year before Internet Explorer 6, and even the upcoming Internet Explorer 8 still won't have support for it. That's why all the modern JavaScript libraries like jQuery have workaround code to translate the Internet Explorer event model into the standard event model shared by all the other browsers.
So yes, there will be plenty to work on for Internet Explorer 9, but it will be yet more stuff that other browsers implemented years ago, not a moving target.