Actually, it's not law. Valid code is a WCAG Priority 2 checkpoint, and writing valid HTML will help you automatically pass some Priority 1 checkpoints (e.g., providing a text equivalent for images, since valid HTML must have the "alt" attribute on each img tag) but it is not required by any accessibility law of which I'm aware. And I'd agree 100% with parent on standards-compliance being a good guideline; when it comes to accessibility, validation is a means to an end and should not be confused with the end itself.
His view on "only cater to what you expect", however, belongs in the stone age.
Anyone else find it amusing that these "purist" people haven't even read the official specification?
Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML. Of course, that "compatibility" is imposed by fiat, not by any actual compatibility of the XHTML and SGML-based HTML syntaxes. There are actually some important incompatibilities even if all the guidelines in Appendix C of the XHTML 1.0 spec are followed. But I'm sure a "purist" like yourself has read up on that, right?
And I'm not just talking about problems with XHTML's minimized tag syntax conflicting with SGML's SHORTTAG. For an example, consider the example of point 1 in the HTML Compatibility Guidelines. It says, in part:
Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.
Sounds nice, but it's wrong and can actually lead to well-formedness errors which will be detected by strict XML parsers. This is because any text/* media type, when sent with an HTTP Content-Type header which did not include the charset parameter, is defined as being encoded in US-ASCII. So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document. Whoops. For added fun, note that this problem crops up when you send text/xml, too; the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml, because then RFC 3023 will mandate those to be the default encodings.
IANAL, but... actually, it is. Since 1978, copyright has been granted automatically on the creation of the work, with registration required only to exercise certain legal options such as recovering statutory damages. See Title 17 USC Chapter 3, Section 302 (a) for this, and Chapter 4, Sections 411 and 412 for the limitation on what you can do without registering. The exclusive rights granted by copyright (Chapter 1, Section 106) remain in effect regardless of registration.
First and foremost, the existance of a robots.txt does not constitute a contract between the client (a web surfer/browser agent) and the server (the site hosting the content proper). Repeat that over and over. There is nothing stating that the existance of robots.txt on your server must be requested by my crawler or spider.
The Internet Archive is not interested in offering access to Web sites or other Internet documents whose authors do not want their materials in the collection. To remove your site from the Wayback Machine, place a robots.txt file at the top level of your site (e.g. www.yourdomain.com/robots.txt) and then submit your site below.
The robots.txt file will do two things:
It will remove all documents from your domain from the Wayback Machine.
It will tell us not to crawl your site in the future.
That, to my mind, indicates an agreement on the part of the Internet Archive to respect REP. The question of when exactly this robots.txt file went up is still quite relevant, though.
Since the Robot Exclusion Protocol is voluntary, not mandatory, I don't think it would be "legally enforceable". It exists as a courtesy.
Does simply stating that a site is copyrighted, without registering it, actually mean that it is copyrighted?
In the United States, putting any creative work into a fixed tangible form automatically confers the protection of copyright, effective from that moment. No notice or registration is required.
In this case the plaintiff probably has a leg to stand on, perhaps unfortunately.
No, because they're not alleging that the Internet Archive is automatically violating copyright. Their argument, roughly, is this:
In the past we did not have a robots.txt file, and our site was archived.
We recently put up a robots.txt file disallowing the Internet Archive's robot.
IA did not purge all the previous versions of our pages, which had no such disallowance.
IA are circumventing technological measures designed to control access to a work and thus are in violation of the DMCA.
There are a couple of problems with that:
The Robot Exclusion Protocol doesn't provide an instruction for "purge everything you've ever archived". The most you can say is "please don't request pages from this site in the future".
REP is very explicitly a voluntary system; no standard or law anywhere mandates that it must be obeyed.
The only hope they have is that IA claim that a robots.txt which disallows further crawling will be read as "please remove all back copies of our pages from your archive", but if that hadn't happened the first remedy should be to contact IA and notify them of the problem.
Apply the background to a page-encompassing DIV for example.
Unfortunately, that doesn't work. In XHTML as application/xhtml+xml the root element is 'html', not 'body', so the 'body' element only takes up as much space as is needed to display the page's content. So if you have a tiling background but not enough content to fill a browser window, the background ends where your content does. This can be worked around by setting the background on 'html' instead of 'body' (that's what's meant by 'body isn't magical'), but it can be a bit of a kludge and cause compatibility problems in older browsers. Also, IE mistakenly thinks there's another root element higher up in the DOM tree than 'html', so if it ever gets wind of application/xhtml+xml this may not work anymore.
Eh? This is news to me. I'll go check that out later on this evening if I get the chance. I certainly don't glean that from the linked article. If what you say is true then that is indeed a bit of a showstopper.
It is true. createElement() works in the context of the HTML DOM, but an XHTML document served as application/xhtml+xml gets an XML DOM, not an HTML DOM. Which means that you have to use the method createElementNS() instead and pass in the XHTML namespace as an argument.
Again, it really comes down to a "best tool for the job" question. In a lot of cases I go with XHTML because the tools I prefer are designed with it in mind, but there are times when HTML 4.01 is a stronger choice (for example, I've done a lot of work lately on sites powered by Scoop, the CMS which runs kuro5hin and a few other well-known sites, and it really wouldn't play well with XHTML at all).
Whats the problem? People not using CSS correctly? How is that a problem with XHTML? (I will admit that I have been guilty of this in the past)
It's a problem because, even for some simple effects like page backgrounds, you now need one stylesheet for use when your document is served as text/html and another for when it's served as application/xhtml+xml.
Again, problems encountered because of this are mostly because people are writing (or more likely copy and pasting) broken javascript.
No, this is even to the point where all the tutorials on modern DOM scripting are screwed, because methods like createElement() don't work in a document sent as application/xhtml+xml. Which means you either have to write two separate versions of your script, or use some sort of switching contsruct to determine at run-time which methods your script will use.
This is obviously a problem. How does not using XHTML fix it? It doesn't. Once the browsers are fixed, so is the problem.
Using valid HTML 4.01 with a fully-qualified URL in the DOCTYPE means your document is processed the way you expect (standards-compliance mode in all modern browsers). Using valid XHTML 1.0 with a fully-qualified URL in the DOCTYPE means your document might be read in standards mode or might be read in quirks mode, depending on the browser. Particularly, it's easy to throw IE6 into quirks mode with XHTML whether you want to or not, and even if IE7 fixes this IE6's market share is going to be huge for a very long time to come.
Now, stop for a moment and ask yourself about sending XHTML as text/html: what benefits of XHTML do you gain in doing so? Not draconian error-handling, since no browser will do that with text/html. Not the ability to bring in content from other namespaces, since no browser will do that with text/html. Not ease of processing with XML tools on the client side, since you've told the client that this isn't XML. So where are the advantages of XHTML as text/html? I sure don't see any.
Honestly, the best you can hope for is to serve application/xhtml+xml to browsers which understand it and fall back for IE. And if you don't need any of XML's benefits and don't want to run the risk of a yellow screen of death, why bother with that? Use HTML 4.01 which has the same set of tags and attributes as XHTML 1.0, and much broader browser compatibility. In other words, XHTMl vs. HTML 4 isn't a "use the latest and greatest" debate, it's a "right tool for the job" debate.
The only reason I brought up XHTML is that it caters better to the disabled by requiring less tag soup (closing tags are required); introduces tags like fieldset and label; forces the HTML programmer to nest properly; and requires lots of accessibility orientated tag attributes (alt, title, summary, scope, headers, label, etc.).
The set of tags and attributes available in XHTML 1.0 is identical to the set of tags and attributes available in HTML 4.01; no new elements were added until XHTML 1.1, and then the only addition was the "ruby" module. HTML 4.01 requires all tags to be nested properly. HTML 4.01 requires the use of "alt". No version of HTML or XHTML yet formulated requires the use of header elements, labels, table summaries, etc.
I would like to see a point-by-point rebuttal to Ian's article, by the way, but judging by your apparent ignorance of HTML 4 I'm not expecting anything outstanding from you on the subject of XHTML.
You're right that a 508 compliant site is pretty ugly.
Bullshit. The only reason why the myth of ugly accessible sites persists is that people don't actually read the guidelines; instead they assume "accessible" means "graphics and colors are forbidden".
Except when IE destroyed Navigator's marketshare, it _wasn't_ bundled with Windows.
Internet Explorer has been bundled with Windows since version 2.0 on Windows NT and since version 3.0 on Windows 95 and its descendants. The tide in the browser war turned some time after the release of IE 4.0, and complete dominance didn't come until the release of IE 5.0.
Just because you don't like it doesn't mean Microsoft shouldn't have the FREEDOM to do what it wants with its software.
Actually, Microsoft signed a consent decree abotu ten years ago which said that they would not bundle their other products or services into their OS. It was the violation of this consent decree which really killed them in the antitrust trial over IE's integration, and which would likely kill them again if they integrated their own search service into the OS.
So Microsoft have, in theory, agreed to this limitation, and I would argue that such limitations have a positive effect on a market.
I think the point MS is trying to make is this: I subscribe to the slashdot RSS feed. However, I may only want to read the YRO and AskSlashdot stories. That I know of, there is no way to selectively download stories from a feed. If there was some sort of header of section info, I could pick and choose which stories to view and wich to discard before it reaches the viewer.
Yeah, it's not like RSS already has a "category" tag that you could use to mark which topic an item belongs to and let people filter on...
How most open-source projects think. Hint: anybody with any experience in actual usability can tell you that users, above all else, want things that are simple and work, not things that they have ot spend six weeks configuring. Look at the iPod: simple interface, few controls, hugely popular. Look at the Mozilla suite versus Firefox: Mozilla is huge, bloated, and has more configuration options than most Slashdotters have zits. Firefox is simple, slimmed-down, has a fraction of the visible options, and has taken 10% of a previously heavily-entrenched market in a tiny amount of time.
Surely it sets a password, it just sets it randomly and sets up the sudo trust relationship by default.
No. The root account exists, obviously, but the field for its password in/etc/passwd is blank, meaning no password whatsoever exists for root. This means that it is not possible to log in with the username 'root'.
I can't understand why this is a security feature?
Because every automated script-kiddie attack out there is programmed to try to log in as 'root'. If it's not possible to do so, then all those attacks have been neutered. While it may still be possible to escalate privileges if a user account is compromised, the difficulty of doing so is greater than the difficulty of running an automated exploit; for one thing, 'root' is a username guaranteed to exist on every Linux system, but cracking a user account which might have any username requires much more devoted and detailed attention. Making it more difficult or time-consuming to crack your system increases the chance that an attacker will try somewhere else instead, since very few attacks against home users are deliberately targeted to their victims; instead, attackers simply scan for computers with known vulnerabilities and crack the easiest targets.
thinks like being unable to cancel a lot of actions because the cancel button was deemed to be 'too complex' by the usability expert
I challenge you to name even one instance where an action in a core GNOME application cannot be canceled, and where the person at the GNOME project publicly stated (i.e., mailing list, Bugzilla, whatever) that it was because cancelling it is "too complex".
hiding all the useful options so you can't configure the damned thing any more
The options that hard-core UNIX geeks find useful are frightening and confusing to 99% of the computer-using population. Thus, those options were moved into GConf where the hard-core geeks will still be able to access them, but where they won't cause problems for average users. Meanwhile, GNOME has gone from a bloated "take six weeks to configure before you can use any apps" DE to one with sensible defaults that let most people (including this UNIX geek) just sit down and start getting work done.
making every single app have its own font/style settings instead of a global one
Again, would you care to provide examples? The only applications I've seen which have their own font settings are text editors/word processors, and those are an expected function of such applications. They also only change the text area where editing takes place, not the fonts used by menus and other controls; in other words, even those apps use the fonts set through GNOME's preferences.
In the future, try talking out of your mouth instead of your ass.
Ubuntu doesn't set a root password in the install; the recommended way to perform administrative tasks is to use 'sudo'. The user account you created during the installation will have full sudo privileges, so just typing 'sudo foo' and providing your user account's password at the prompt will work fine.
You can set a root password by doing 'sudo passwd root', but it's really not necessary; with 'sudo' you never have to be able to log in as root or use 'su' to switch to root. Also, some people would argue that having no root password is a security enhancement (since it makes it impossible for outside attackers to try to log in as root).
The "preferred form" of most Apple developers is probably some versioning system running as a client on G5 workstations, so obviously Apple is legally obligated to provide the changed source code to KHTML developers in that form. Go sign on to the KHTML project now and your free G5 will be shipped soon!
Suppose that I drop code into KHTML which calls a function defined in a separate, proprietary library. What you're claiming is that I would then be required to release source to the proprietary library when, in fact, that's precisely what the LGPL is designed to avoid. Apple can drop all the proprietary calls to their own libs that they want into KHTML without having to open source those libs, but they do have to release the KTHML changes which make those calls.
If they can't separate it (release a branch or something) then those bits of safari are based on open source code.
Um. No. The post I was replying to indicated that Apple should make their entire development tree available to KHTML developers. I pointed out that this tree probably includes a heck of a lot of proprietary Apple code for Safari that's not related to KHTML. This dos not in any way make any unrelated code "based on open source". In the future, please make sure you know what you're talking abotu before commenting.
So if Apple releases their KHTML changes with the WebCore stuff in, they get yelled at for being bad citizens. But if they released their changes without the WebCore stuff in, they wouldn't be releasing the source of all their changes and would be violating the license. What's a developer to do?
far more likely they use their VCS tree complete with comments. So that's what they should release
Except doing so would probably expose bits of Safari which are not based on open-source code. Ain't gonna happen. Also, "preferred form" seems to be interpreted by some folks to mean "guarantee compatibility with my version", which I don't think would hold up in court.
basically it's a rigorous test that ensures that a browser has all the goodies that web developers have been lusting after forever.
No, a "rigorous test" would be a test suite with hundreds of carefully-constructed examples (for example, here's one for CSS2.1). The WSG's Acid tests are more like pop quizzes, and only test a few particular items.
Slashdot Mirror
Actually, it's not law. Valid code is a WCAG Priority 2 checkpoint, and writing valid HTML will help you automatically pass some Priority 1 checkpoints (e.g., providing a text equivalent for images, since valid HTML must have the "alt" attribute on each img tag) but it is not required by any accessibility law of which I'm aware. And I'd agree 100% with parent on standards-compliance being a good guideline; when it comes to accessibility, validation is a means to an end and should not be confused with the end itself.
His view on "only cater to what you expect", however, belongs in the stone age.
Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML. Of course, that "compatibility" is imposed by fiat, not by any actual compatibility of the XHTML and SGML-based HTML syntaxes. There are actually some important incompatibilities even if all the guidelines in Appendix C of the XHTML 1.0 spec are followed. But I'm sure a "purist" like yourself has read up on that, right?
And I'm not just talking about problems with XHTML's minimized tag syntax conflicting with SGML's SHORTTAG. For an example, consider the example of point 1 in the HTML Compatibility Guidelines. It says, in part:
Sounds nice, but it's wrong and can actually lead to well-formedness errors which will be detected by strict XML parsers. This is because any text/* media type, when sent with an HTTP Content-Type header which did not include the charset parameter, is defined as being encoded in US-ASCII. So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document. Whoops. For added fun, note that this problem crops up when you send text/xml, too; the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml, because then RFC 3023 will mandate those to be the default encodings.
IANAL, but... actually, it is. Since 1978, copyright has been granted automatically on the creation of the work, with registration required only to exercise certain legal options such as recovering statutory damages. See Title 17 USC Chapter 3, Section 302 (a) for this, and Chapter 4, Sections 411 and 412 for the limitation on what you can do without registering. The exclusive rights granted by copyright (Chapter 1, Section 106) remain in effect regardless of registration.
The Robot Exclusion Protocol is voluntary, yes, but check out this choice quote from the Internet Archive's page on exclusion:
That, to my mind, indicates an agreement on the part of the Internet Archive to respect REP. The question of when exactly this robots.txt file went up is still quite relevant, though.
Since the Robot Exclusion Protocol is voluntary, not mandatory, I don't think it would be "legally enforceable". It exists as a courtesy.
In the United States, putting any creative work into a fixed tangible form automatically confers the protection of copyright, effective from that moment. No notice or registration is required.
No, because they're not alleging that the Internet Archive is automatically violating copyright. Their argument, roughly, is this:
There are a couple of problems with that:
The only hope they have is that IA claim that a robots.txt which disallows further crawling will be read as "please remove all back copies of our pages from your archive", but if that hadn't happened the first remedy should be to contact IA and notify them of the problem.
Should have said "root element of the visual display", since the root element of the document in both cases is 'html'.
Which is another odd thing about XHTML: you can style things in the head.
Unfortunately, that doesn't work. In XHTML as application/xhtml+xml the root element is 'html', not 'body', so the 'body' element only takes up as much space as is needed to display the page's content. So if you have a tiling background but not enough content to fill a browser window, the background ends where your content does. This can be worked around by setting the background on 'html' instead of 'body' (that's what's meant by 'body isn't magical'), but it can be a bit of a kludge and cause compatibility problems in older browsers. Also, IE mistakenly thinks there's another root element higher up in the DOM tree than 'html', so if it ever gets wind of application/xhtml+xml this may not work anymore.
It is true. createElement() works in the context of the HTML DOM, but an XHTML document served as application/xhtml+xml gets an XML DOM, not an HTML DOM. Which means that you have to use the method createElementNS() instead and pass in the XHTML namespace as an argument.
Again, it really comes down to a "best tool for the job" question. In a lot of cases I go with XHTML because the tools I prefer are designed with it in mind, but there are times when HTML 4.01 is a stronger choice (for example, I've done a lot of work lately on sites powered by Scoop, the CMS which runs kuro5hin and a few other well-known sites, and it really wouldn't play well with XHTML at all).
A few points as I drag myself out of bed:
It's a problem because, even for some simple effects like page backgrounds, you now need one stylesheet for use when your document is served as text/html and another for when it's served as application/xhtml+xml.
No, this is even to the point where all the tutorials on modern DOM scripting are screwed, because methods like createElement() don't work in a document sent as application/xhtml+xml. Which means you either have to write two separate versions of your script, or use some sort of switching contsruct to determine at run-time which methods your script will use.
Using valid HTML 4.01 with a fully-qualified URL in the DOCTYPE means your document is processed the way you expect (standards-compliance mode in all modern browsers). Using valid XHTML 1.0 with a fully-qualified URL in the DOCTYPE means your document might be read in standards mode or might be read in quirks mode, depending on the browser. Particularly, it's easy to throw IE6 into quirks mode with XHTML whether you want to or not, and even if IE7 fixes this IE6's market share is going to be huge for a very long time to come.Now, stop for a moment and ask yourself about sending XHTML as text/html: what benefits of XHTML do you gain in doing so? Not draconian error-handling, since no browser will do that with text/html. Not the ability to bring in content from other namespaces, since no browser will do that with text/html. Not ease of processing with XML tools on the client side, since you've told the client that this isn't XML. So where are the advantages of XHTML as text/html? I sure don't see any.
Honestly, the best you can hope for is to serve application/xhtml+xml to browsers which understand it and fall back for IE. And if you don't need any of XML's benefits and don't want to run the risk of a yellow screen of death, why bother with that? Use HTML 4.01 which has the same set of tags and attributes as XHTML 1.0, and much broader browser compatibility. In other words, XHTMl vs. HTML 4 isn't a "use the latest and greatest" debate, it's a "right tool for the job" debate.
The set of tags and attributes available in XHTML 1.0 is identical to the set of tags and attributes available in HTML 4.01; no new elements were added until XHTML 1.1, and then the only addition was the "ruby" module. HTML 4.01 requires all tags to be nested properly. HTML 4.01 requires the use of "alt". No version of HTML or XHTML yet formulated requires the use of header elements, labels, table summaries, etc.
I would like to see a point-by-point rebuttal to Ian's article, by the way, but judging by your apparent ignorance of HTML 4 I'm not expecting anything outstanding from you on the subject of XHTML.
Bullshit. The only reason why the myth of ugly accessible sites persists is that people don't actually read the guidelines; instead they assume "accessible" means "graphics and colors are forbidden".
Internet Explorer has been bundled with Windows since version 2.0 on Windows NT and since version 3.0 on Windows 95 and its descendants. The tide in the browser war turned some time after the release of IE 4.0, and complete dominance didn't come until the release of IE 5.0.
So I think you need to check your history.
Actually, Microsoft signed a consent decree abotu ten years ago which said that they would not bundle their other products or services into their OS. It was the violation of this consent decree which really killed them in the antitrust trial over IE's integration, and which would likely kill them again if they integrated their own search service into the OS.
So Microsoft have, in theory, agreed to this limitation, and I would argue that such limitations have a positive effect on a market.
I think the point MS is trying to make is this: I subscribe to the slashdot RSS feed. However, I may only want to read the YRO and AskSlashdot stories. That I know of, there is no way to selectively download stories from a feed. If there was some sort of header of section info, I could pick and choose which stories to view and wich to discard before it reaches the viewer.
Yeah, it's not like RSS already has a "category" tag that you could use to mark which topic an item belongs to and let people filter on...
I know that the US Copyright Office has granted a DMCA exemption for at least some of the material they archive.
How most open-source projects think. Hint: anybody with any experience in actual usability can tell you that users, above all else, want things that are simple and work, not things that they have ot spend six weeks configuring. Look at the iPod: simple interface, few controls, hugely popular. Look at the Mozilla suite versus Firefox: Mozilla is huge, bloated, and has more configuration options than most Slashdotters have zits. Firefox is simple, slimmed-down, has a fraction of the visible options, and has taken 10% of a previously heavily-entrenched market in a tiny amount of time.
No. The root account exists, obviously, but the field for its password in /etc/passwd is blank, meaning no password whatsoever exists for root. This means that it is not possible to log in with the username 'root'.
Because every automated script-kiddie attack out there is programmed to try to log in as 'root'. If it's not possible to do so, then all those attacks have been neutered. While it may still be possible to escalate privileges if a user account is compromised, the difficulty of doing so is greater than the difficulty of running an automated exploit; for one thing, 'root' is a username guaranteed to exist on every Linux system, but cracking a user account which might have any username requires much more devoted and detailed attention. Making it more difficult or time-consuming to crack your system increases the chance that an attacker will try somewhere else instead, since very few attacks against home users are deliberately targeted to their victims; instead, attackers simply scan for computers with known vulnerabilities and crack the easiest targets.
Hence it's a security improvement.
I challenge you to name even one instance where an action in a core GNOME application cannot be canceled, and where the person at the GNOME project publicly stated (i.e., mailing list, Bugzilla, whatever) that it was because cancelling it is "too complex".
The options that hard-core UNIX geeks find useful are frightening and confusing to 99% of the computer-using population. Thus, those options were moved into GConf where the hard-core geeks will still be able to access them, but where they won't cause problems for average users. Meanwhile, GNOME has gone from a bloated "take six weeks to configure before you can use any apps" DE to one with sensible defaults that let most people (including this UNIX geek) just sit down and start getting work done.
Again, would you care to provide examples? The only applications I've seen which have their own font settings are text editors/word processors, and those are an expected function of such applications. They also only change the text area where editing takes place, not the fonts used by menus and other controls; in other words, even those apps use the fonts set through GNOME's preferences.
In the future, try talking out of your mouth instead of your ass.
Ubuntu doesn't set a root password in the install; the recommended way to perform administrative tasks is to use 'sudo'. The user account you created during the installation will have full sudo privileges, so just typing 'sudo foo' and providing your user account's password at the prompt will work fine.
You can set a root password by doing 'sudo passwd root', but it's really not necessary; with 'sudo' you never have to be able to log in as root or use 'su' to switch to root. Also, some people would argue that having no root password is a security enhancement (since it makes it impossible for outside attackers to try to log in as root).
The "preferred form" of most Apple developers is probably some versioning system running as a client on G5 workstations, so obviously Apple is legally obligated to provide the changed source code to KHTML developers in that form. Go sign on to the KHTML project now and your free G5 will be shipped soon!
Suppose that I drop code into KHTML which calls a function defined in a separate, proprietary library. What you're claiming is that I would then be required to release source to the proprietary library when, in fact, that's precisely what the LGPL is designed to avoid. Apple can drop all the proprietary calls to their own libs that they want into KHTML without having to open source those libs, but they do have to release the KTHML changes which make those calls.
Also, it's somewhat moot now.
Um. No. The post I was replying to indicated that Apple should make their entire development tree available to KHTML developers. I pointed out that this tree probably includes a heck of a lot of proprietary Apple code for Safari that's not related to KHTML. This dos not in any way make any unrelated code "based on open source". In the future, please make sure you know what you're talking abotu before commenting.
So if Apple releases their KHTML changes with the WebCore stuff in, they get yelled at for being bad citizens. But if they released their changes without the WebCore stuff in, they wouldn't be releasing the source of all their changes and would be violating the license. What's a developer to do?
Except doing so would probably expose bits of Safari which are not based on open-source code. Ain't gonna happen. Also, "preferred form" seems to be interpreted by some folks to mean "guarantee compatibility with my version", which I don't think would hold up in court.
No, a "rigorous test" would be a test suite with hundreds of carefully-constructed examples (for example, here's one for CSS2.1). The WSG's Acid tests are more like pop quizzes, and only test a few particular items.