Yeah, it was David Hyatt who was working on getting Saf to pass (and got it to be the first browser to pass in any build, and the first to have a generally available release (i.e., a non-development build, even if public) -- the latter being the only thing that truly counts for passing the test).
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008011 details the bug (in this case, it was the test itself that was wrong -- not the reference). The reference rendering for Acid3 is likely correct as the actual rendering isn't overly complex (the complexity is in the ECMAScript and DOM support), though with the complexity of some tests there could easily be bugs in the test again.
XHTML 5 most certainly does exist: it's the XML serialisation of HTML 5 (which is defined in terms of a DOM, and provides two serialisations: one that uses an XML parser and one that uses an HTML parser).
HTML 5 (in both serialisations) most certainly doesn't have a DOCTYPE. A quick look at the spec would confirm that. The closest it gets is which exists only in the text/html serialisation exists purely to switch browsers into standards mode.
As for validation, all you need is a formal definition of a content model: it is absolutely irrelevant how that is specified, be it any schema (including DTDs) or Klingon (or in HTML 5's case, English).
DOCTYPEs have never been used for parsing whatsoever: in XML the content-models are all specified regardless of the presence of a DOCTYPE, and in text/html a DOCTYPE has only ever been used to switch between standards/quirks mode (it's not even read whatsoever).
there were all the software parts to make a wysiwyg (what you see is what you get - in other words direct manipulation of text on screen as on the printed - or browsed page) word processor. I just had to add hypertext, (by subclassing the Text object)
Given their past effort in "supporting" previous standarts, it's not hard for them to claim "XHTML2" support.
Just enable an additional DOCTYPE to be recognised, and throw the exact same broken "quirks-mode" parser as before.
Most of the new XHTMLv2 tags which differs from XHTMLv1's one will fail to be recognized and displayed properly, but that won't be a big change to their traditionnal support of standart....
{/sarcasm}
I didn't mean to imply that MS had say they will support XHTML 2 -- they haven't made any comment regarding it whatsoever. Also, before you make further comments about their support of standards, bare in mind that before they stopped further development of IE that there was a time when IE was known for its standards support, and anyone who knows anyone on the IE team knows they're doing their damnedest to get it back that way (though, inevitably, touching code that hasn't been touched in years is no easy feat).
Sorry ? WTF ?
Just read the DOCTYPE and depending on whether is specifies XHTML2 or HTML5, just switch to the corresponding parser.
The fact that both XHTML5 and XHTML 2 use similar but incompatible namespaces means that you can't mix BOTH in the SAME document in a meaningful way.
That doesn't stop you from using several different parser depending on what dialect a document is using.
DTDs are dead and DOCTYPEs are not relevant except for some obscure things that are not related to this discussion. XHTML 5 doesn't even have one. They were also never intended for any kind of versioning. Also, a DOCTYPE is only required in a strictly-conforming XHTML 2 documents, and the UA requirements for XHTML 2 documents cover those that aren't strictly-conforming (and therefore ones that don't have a DOCTYPE -- if you don't have a DOCTYPE (which is also the case in fragments such as within Atom documents) you have nothing to branch on and nothing to distinguish the two).
But that shouldn't be necessary because since XHTML 1, all document HAVE to be valid before being displayed.
Please look up what validity actually means: the only difference between validity and well-formness is that a document meets requirements set out in a DTD as well as being well-formed (which means there is no difference if no DOCTYPE is specified, and a DOCTYPE is purely optional in XML). Also, there are both validating and non-validating XML parsers (section 5.1, XML 1.0) -- only the former actually checks a document is valid, and all major XHTML processors use non-validating XML parsers. An XML document (therefore including XHTML documents) only needs to be well-formed to be displayed in most cases.
Re:are html 5 and xhtml 2 worked on by W3C?
on
HTML V5 and XHTML V2
·
· Score: 1
There is an HTML WG at the W3C chartered to create a new version of HTML. A basis for review means, in W3C language, a starting document that will then be reviewed and changed as needed.
HTML 5 is aiming to support various things needed for web applications (in fact, the current draft is formed of two documents: Web Applications 1.0 and Web Forms 2.0). Also, see http://www.w3.org/2006/appformats/admin/charter.html.
All the browser vendors have already said they will support HTML 5 (yes, that includes MS) and all but MS have said they won't support XHTML 2 (MS hasn't made much of an effort to suggest they will support it either).
As it stands, with both XHTML 5 and XHTML 2 using the same namespace, it is only possible to support one of the two.
What we still need is to continue moving towards full interoperability. Hopefully having a proper spec will help with that.
Behaviour such as handling of getResponseHeader(header) when no header exists still varies: IE returns null, Fx/Opera return an empty string. If you want to check if a header exists, claiming it is an empty string isn't helpful.
Apple's primary reason for not supporting Ogg/Vorbis (as has been said many times in many places) is that no major company has implemented it yet: those with submarine patents aren't going to sue someone with no money, they'll wait for the biggest company possible to implement it, a company with large amounts of money like MS or Apple before taking legal action. It's a huge risk, and without already deployed content, nobody is going to take the risk.
You have to remember that Ogg/Vorbis isn't truly patent free: one or two companies have granted RF licenses to any and all patents covering Ogg/Vorbis, but that's far from every company/organisation/person with patents, and several major companies have stated they are aware of patents that cover Ogg/Vorbis that are not covered by the RF grants.
The original Half-Life had a nearly production ready port to the Mac OS done -- it was scrapped as multiplayer was incompatible with the Windows release.
The G5 is clock-for-clock quicker than the Core Duo, and as both have two cores within the computer (the G5 on two single core chips, the Core Duo on one dual core chip), they are pretty much comparable (the G5 will undoubtedly be better at fp, and the Core Duo at int, mainly due to the PPC v. x86 design differences).
The concepts aren't GPL'd. The code that implements the concepts are. Anyone is free to re-implement the concept without restriction (unless, of course, you're in a country with software patents).
NeXTSTEP supported 68k, x86, SPARC, and PA-RISC in the early '90s (with an unfinished port to PPC). We know what happened to the PPC port (it was finished by Apple), we know what happened to the x86 port (it was secretly maintained by Apple). What's to say the other ports (or at least SPARC) have been abandoned?
NeXTSTEP had fat binaries that supported 68k, x86, SPARC, and PA-RISC in the early '90s. Mac OS had fat binaries that supported 68k and PPC. They've been around long enough, and the disk space lost is minimal (images and other such binary data makes up the vast majority of disk space of an application).
The dock in OS X is a direct descendent of NeXTSTEP's dock (which is hardly odd, seeming Apple bought NeXT for the OS) which existed since version NeXTSTEP 0.9, released in 1989, before Windows had a taskbar.
Apple, no DRM? You're kidding, right? Might need no serial, but what about the TPM module?
Get your facts right - OS X has no support for the TPM module (heck, the Mac Pro, and the Core 2 Duo modules don't even have the module), although there are free (in cost and source) drivers that add support for it.
Slashdot Mirror
In my view a test isn't a test until it is finished and can be used as a test, so it isn't yet a test (which means any current bugs are irrelevant).
Yeah, it was David Hyatt who was working on getting Saf to pass (and got it to be the first browser to pass in any build, and the first to have a generally available release (i.e., a non-development build, even if public) -- the latter being the only thing that truly counts for passing the test).
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008011 details the bug (in this case, it was the test itself that was wrong -- not the reference). The reference rendering for Acid3 is likely correct as the actual rendering isn't overly complex (the complexity is in the ECMAScript and DOM support), though with the complexity of some tests there could easily be bugs in the test again.
Everything in the ACID3 test is at an implementable stage (look at Anne's blog post in the summary (i.e., RTFA)), and has been since 2004.
XHTML 5 most certainly does exist: it's the XML serialisation of HTML 5 (which is defined in terms of a DOM, and provides two serialisations: one that uses an XML parser and one that uses an HTML parser).
HTML 5 (in both serialisations) most certainly doesn't have a DOCTYPE. A quick look at the spec would confirm that. The closest it gets is which exists only in the text/html serialisation exists purely to switch browsers into standards mode.
As for validation, all you need is a formal definition of a content model: it is absolutely irrelevant how that is specified, be it any schema (including DTDs) or Klingon (or in HTML 5's case, English).
DOCTYPEs have never been used for parsing whatsoever: in XML the content-models are all specified regardless of the presence of a DOCTYPE, and in text/html a DOCTYPE has only ever been used to switch between standards/quirks mode (it's not even read whatsoever).
http://www.w3.org/MarkUp/2007/ED-xhtml2-20071024/conformance.html#strict, even.
The latest public WD of XHTML2 predates the WG being re-chartered: the current decision is to use the same namespace, as is reflected by the ED: .
From his own site:
Tim Berners-Lee originally intended HTML to be created through a WYSIWYG editor. WorldWideWeb (the first web browser) has a WYSIWYG editor built in.
There is an HTML WG at the W3C chartered to create a new version of HTML. A basis for review means, in W3C language, a starting document that will then be reviewed and changed as needed.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5) covers HTML 5, Nobody has started to try to implement XHTML 2 AFAIK (though definitely nobody major).
HTML 5 is aiming to support various things needed for web applications (in fact, the current draft is formed of two documents: Web Applications 1.0 and Web Forms 2.0). Also, see http://www.w3.org/2006/appformats/admin/charter.html.
All the browser vendors have already said they will support HTML 5 (yes, that includes MS) and all but MS have said they won't support XHTML 2 (MS hasn't made much of an effort to suggest they will support it either).
As it stands, with both XHTML 5 and XHTML 2 using the same namespace, it is only possible to support one of the two.
What we still need is to continue moving towards full interoperability. Hopefully having a proper spec will help with that.
Behaviour such as handling of getResponseHeader(header) when no header exists still varies: IE returns null, Fx/Opera return an empty string. If you want to check if a header exists, claiming it is an empty string isn't helpful.
Apple's primary reason for not supporting Ogg/Vorbis (as has been said many times in many places) is that no major company has implemented it yet: those with submarine patents aren't going to sue someone with no money, they'll wait for the biggest company possible to implement it, a company with large amounts of money like MS or Apple before taking legal action. It's a huge risk, and without already deployed content, nobody is going to take the risk.
You have to remember that Ogg/Vorbis isn't truly patent free: one or two companies have granted RF licenses to any and all patents covering Ogg/Vorbis, but that's far from every company/organisation/person with patents, and several major companies have stated they are aware of patents that cover Ogg/Vorbis that are not covered by the RF grants.
The original Half-Life had a nearly production ready port to the Mac OS done -- it was scrapped as multiplayer was incompatible with the Windows release.
The Xbox 360's OS is based on NT 5, running on PPC.
The G5 is clock-for-clock quicker than the Core Duo, and as both have two cores within the computer (the G5 on two single core chips, the Core Duo on one dual core chip), they are pretty much comparable (the G5 will undoubtedly be better at fp, and the Core Duo at int, mainly due to the PPC v. x86 design differences).
Germany's Recording Industry Association of America!? How is that even possible? Or do you mean Germany's equivalent of the RIAA?
The concepts aren't GPL'd. The code that implements the concepts are. Anyone is free to re-implement the concept without restriction (unless, of course, you're in a country with software patents).
NeXTSTEP supported 68k, x86, SPARC, and PA-RISC in the early '90s (with an unfinished port to PPC). We know what happened to the PPC port (it was finished by Apple), we know what happened to the x86 port (it was secretly maintained by Apple). What's to say the other ports (or at least SPARC) have been abandoned?
NeXTSTEP had fat binaries that supported 68k, x86, SPARC, and PA-RISC in the early '90s. Mac OS had fat binaries that supported 68k and PPC. They've been around long enough, and the disk space lost is minimal (images and other such binary data makes up the vast majority of disk space of an application).
The dock in OS X is a direct descendent of NeXTSTEP's dock (which is hardly odd, seeming Apple bought NeXT for the OS) which existed since version NeXTSTEP 0.9, released in 1989, before Windows had a taskbar.
Get your facts right - OS X has no support for the TPM module (heck, the Mac Pro, and the Core 2 Duo modules don't even have the module), although there are free (in cost and source) drivers that add support for it.
http://www.osxbook.com/book/bonus/chapter10/tpm/ has plenty of useful information.
Give a user a choice between a native OS X app, or one that relies on virtualisation. Almost all users will choose the native app.
If you're competitor offers one and you don't, you ain't gonna sell well.