Gah, I always expect paragraphs to be added automatically in CMSes; to repost with paragraphs (albeit probably still with too few):
What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).
I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed).
As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages.
Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)
What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).
I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed).
As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages.
Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)
Yet realistically if HTML5 was purely XML, how would it help with all the existing content on the web? What would be the roadmap for transitioning to XML from HTML? XHTML 1.0 became a REC over ten years ago now, and we're not much closer to a pure XML web now than we were then.
The big advantage of HTML5 with dealing with arbitrary content is that it has defined parsing rules for any input stream, mapping it to a DOM. This means libraries that parse XML into a DOM can be interchanged with libraries that parse HTML (several already exist following HTML5, see the Validator.nu/Gecko parser (Java/C++) and html5lib (Python, and far less regularly updated PHP/Ruby).
bar, there are (as there were in HTML 4) strict rules about when a tag can be omitted. As for parsing, HTML5 defines how to map any character stream into a DOM (from which normal CSS rules can be applied, without knowledge of the raw source, consistent with how browsers are already architectured) -- defining this was a large part in the reason for HTML5 existing at all.
In terms of global temperature rise, none. In terms of the eco-system within the river itself, and what fish and other animals can live off it given a temperature rise, there's a lot of difference.
OK, it runs on PowerPC, but not on Windows on PowerPC I did actually think of that, intend to reword my comment to avoid that problem, and promptly forgot to do so. I imagine MS would prefer to ship an identical version of Office on all versions of Windows, as surprisingly enough Win32 APIs are the same on all, and likely it would be less effort than trying to port the Mac version to Windows.
The quirks were worked out long before that: Windows NT until 4.0 supported x86, Alpha, MIPS, and PowerPC. 2000 (i.e., NT 5.0) supported Alpha until as late as after RC1.
Yet only one of these four architectures ever had decent support for Office: x86. (There was a single release of Office for the others including Word 6.0 and Excel 5.0, both 32-bit, and PowerPoint 4.0, as 16-bit.) Why? Office, especially PowerPoint and Access, both apparently contain a lot of x86 Assembly.
The other architectures died because nobody used them because the most useful program that ran on them was Calculator. Nobody ever bothered porting to it before. If they try again, will it be different? It will depend on how many people buy ARM-based netbooks, and how much software MS can get to run on them (and they will, de-facto, need emulation to get any decent marketshare, as people expect their old programs to run).
Everything it tests has had a call for implementations out for at least five years. In W3C land to become a recommendation there must be two completely interoperable implementations -- fundamentally they will not become recommendations until they are implemented, so the "not even a standard yet" argument doesn't fly.
Windows NT 4.0 ran on x86, Alpha, MIPS and PowerPC. Nowadays, there are only (really) x86, x86_64, and IA-64 versions now (I say really because there is a PPC version of sorts -- the 360's OS, which is forked from that of the original Xbox (x86) which itself was forked from Windows 2000).
Windows has in the past not been bound to x86 for desktop use, it just never really caught on.
WebKit ToT is nowhere near as stable as the Saf3.2 branch. It crashes a bit more, and there are a lot of regressions (of websites breaking). Currently, there are 225 P1 (priority 1, i.e., top priority) bugs. It's nowhere near shippable.
To my knowledge neither Halo nor Unreal Engine 2.5-3 use Ogg despite using Vorbis.
As for not making comments randomly, just choosing one legal strategy doesn't prevent one from infringing patents. Also, the comments in SVN merely concern On2's patents: they say nothing about any possible other (submarine or not) patents. There is no proof that Theora isn't covered by some such patent.
Can you find a quote for that? I was speaking to a variety of people at the W3C TPAC about it -- too my knowledge only Vorbis has been shipped in bulk (mainly in games) and been looked at in depth, and Ogg has been looked at and not shipped in bulk. Nothing is really known about Theora. We have unsubstantiated claims from both sides.
http://html5.org/tools/web-apps-tracker?from=1200&to=1201&context=10 -- I can't find that change in the WebKit repo quickly, but it must be after 2008-02-09. I don't have anything to cite for Chrome using WebKit from Saf3.1 or it being branched in Jan (though you should find that in the WebKit repo), as it was only ever said in IRC, by developers of the respective products. See if globalStorage exists in Chrome, as that was in WebKit then.
localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.
In en-gb-oed it would be localization too (as it is a word of Greek origin -- however, something like merchandize, which is not, is purely wrong, it should never be -ize, but rather always -ise).
Re:Of Course IE will fail, ACID test is biased...
on
Acid3 Test Released
·
· Score: 2, Informative
Actually, trying to make IE fail it wasn't an aim: the aim was to include tests that one of Firefox, Safari, and Opera fails. If IE happens to fail them too, so be it.
Browsers don't use SGML parsers, they use purpose built HTML parsers that have all kinds of quirks that are totally unspecified (except in the HTML 5 draft). As such, they don't actually read the DTD whatsoever: the only thing the DTD means to the browser is whether it will parse in standards mode, almost standards mode, or quirks mode. They actually have the list of entities in HTML hardcoded.
One thing that XML needs to have defined is non-fatal error handling: a larger and larger amount of content is dependant on non-fatal error handling (especially of Atom/RSS feeds), and also often on RFC3023 not being supported.
If non-fatal error handling is not specified soon, I fear that XML will fall into the same hell that HTML got into in the early 90s: everyone having to reverse engineer one-another to support content. Define it now, and chaos in the future can be avoided. Ignore the reality, and XML will fall into the same trap that HTML fell into. Idealism does not work. The world is not perfect.
- He alluded to the Linux kernel being hard to port because of it's ties to x86 architechture, citing how Minix was ported to x86, 680x0, and SPARC. Yet there's hardly a piece of silicon worthy of driving a terminal that Linux hasn't been ported to
IIRC that comment dates back to when Linus was strongly tied to x86 -- sure, since 2.0 it's modular enough to make porting it easier, but back when 1.x was around that sure as hell wasn't the case. Porting it to 68k took a huge effort of rewriting large parts (the first port of Linux).
Slashdot Mirror
Gah, I always expect paragraphs to be added automatically in CMSes; to repost with paragraphs (albeit probably still with too few):
What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).
I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed).
As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages.
Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)
What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence). I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed). As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages. Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)
Yet realistically if HTML5 was purely XML, how would it help with all the existing content on the web? What would be the roadmap for transitioning to XML from HTML? XHTML 1.0 became a REC over ten years ago now, and we're not much closer to a pure XML web now than we were then. The big advantage of HTML5 with dealing with arbitrary content is that it has defined parsing rules for any input stream, mapping it to a DOM. This means libraries that parse XML into a DOM can be interchanged with libraries that parse HTML (several already exist following HTML5, see the Validator.nu/Gecko parser (Java/C++) and html5lib (Python, and far less regularly updated PHP/Ruby).
foo
bar, there are (as there were in HTML 4) strict rules about when a tag can be omitted. As for parsing, HTML5 defines how to map any character stream into a DOM (from which normal CSS rules can be applied, without knowledge of the raw source, consistent with how browsers are already architectured) -- defining this was a large part in the reason for HTML5 existing at all.
HTML5's text/html syntax is not defined in terms of SGML, it is a separate syntax specific to HTML, defined at http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html.
In terms of global temperature rise, none. In terms of the eco-system within the river itself, and what fish and other animals can live off it given a temperature rise, there's a lot of difference.
What's the meaning of life?
. To a lot of people,
42
is not the answer (as that's the answer to another question, we just don't know which yet).
OK, it runs on PowerPC, but not on Windows on PowerPC I did actually think of that, intend to reword my comment to avoid that problem, and promptly forgot to do so. I imagine MS would prefer to ship an identical version of Office on all versions of Windows, as surprisingly enough Win32 APIs are the same on all, and likely it would be less effort than trying to port the Mac version to Windows.
The quirks were worked out long before that: Windows NT until 4.0 supported x86, Alpha, MIPS, and PowerPC. 2000 (i.e., NT 5.0) supported Alpha until as late as after RC1.
Yet only one of these four architectures ever had decent support for Office: x86. (There was a single release of Office for the others including Word 6.0 and Excel 5.0, both 32-bit, and PowerPoint 4.0, as 16-bit.) Why? Office, especially PowerPoint and Access, both apparently contain a lot of x86 Assembly.
The other architectures died because nobody used them because the most useful program that ran on them was Calculator. Nobody ever bothered porting to it before. If they try again, will it be different? It will depend on how many people buy ARM-based netbooks, and how much software MS can get to run on them (and they will, de-facto, need emulation to get any decent marketshare, as people expect their old programs to run).
True. If I actually think about when five years before Acid3 and not when Acid3 was written, things start to be more sensible. :)
Everything it tests has had a call for implementations out for at least five years. In W3C land to become a recommendation there must be two completely interoperable implementations -- fundamentally they will not become recommendations until they are implemented, so the "not even a standard yet" argument doesn't fly.
Windows NT 4.0 ran on x86, Alpha, MIPS and PowerPC. Nowadays, there are only (really) x86, x86_64, and IA-64 versions now (I say really because there is a PPC version of sorts -- the 360's OS, which is forked from that of the original Xbox (x86) which itself was forked from Windows 2000).
Windows has in the past not been bound to x86 for desktop use, it just never really caught on.
the only rendering engine you should need is your favorite one that supports the standards
provided all your favourite sites use standards themselves.
http://trac.webkit.org/log/branches/Safari-3-2-branch shows it's a fork of the Saf 3.1 branch with selected patches.
WebKit ToT is nowhere near as stable as the Saf3.2 branch. It crashes a bit more, and there are a lot of regressions (of websites breaking). Currently, there are 225 P1 (priority 1, i.e., top priority) bugs. It's nowhere near shippable.
To my knowledge neither Halo nor Unreal Engine 2.5-3 use Ogg despite using Vorbis.
As for not making comments randomly, just choosing one legal strategy doesn't prevent one from infringing patents. Also, the comments in SVN merely concern On2's patents: they say nothing about any possible other (submarine or not) patents. There is no proof that Theora isn't covered by some such patent.
Can you find a quote for that? I was speaking to a variety of people at the W3C TPAC about it -- too my knowledge only Vorbis has been shipped in bulk (mainly in games) and been looked at in depth, and Ogg has been looked at and not shipped in bulk. Nothing is really known about Theora. We have unsubstantiated claims from both sides.
See http://en.wikipedia.org/wiki/Image:Firearmsources.svg -- the majority of guns used in crimes in the US come from _legal_ sources. It does have an effect on whether criminals have guns.
http://html5.org/tools/web-apps-tracker?from=1200&to=1201&context=10 -- I can't find that change in the WebKit repo quickly, but it must be after 2008-02-09. I don't have anything to cite for Chrome using WebKit from Saf3.1 or it being branched in Jan (though you should find that in the WebKit repo), as it was only ever said in IRC, by developers of the respective products. See if globalStorage exists in Chrome, as that was in WebKit then.
localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.
In en-gb-oed it would be localization too (as it is a word of Greek origin -- however, something like merchandize, which is not, is purely wrong, it should never be -ize, but rather always -ise).
Actually, trying to make IE fail it wasn't an aim: the aim was to include tests that one of Firefox, Safari, and Opera fails. If IE happens to fail them too, so be it.
Browsers don't use SGML parsers, they use purpose built HTML parsers that have all kinds of quirks that are totally unspecified (except in the HTML 5 draft). As such, they don't actually read the DTD whatsoever: the only thing the DTD means to the browser is whether it will parse in standards mode, almost standards mode, or quirks mode. They actually have the list of entities in HTML hardcoded.
One thing that XML needs to have defined is non-fatal error handling: a larger and larger amount of content is dependant on non-fatal error handling (especially of Atom/RSS feeds), and also often on RFC3023 not being supported.
If non-fatal error handling is not specified soon, I fear that XML will fall into the same hell that HTML got into in the early 90s: everyone having to reverse engineer one-another to support content. Define it now, and chaos in the future can be avoided. Ignore the reality, and XML will fall into the same trap that HTML fell into. Idealism does not work. The world is not perfect.