It's not the outrageous hack you think it is. Ahem is a dummy font that needs to have specific sizing in order for Acid3 to give accurate results. If Ahem doesn't have the specific size assumed by the Acid3 test, that means Acid3 can't give accurate results, not that Acid3 failed. So the Webkit developers disabled font smoothing for that specific font so that Acid3 could give accurate results, not to cheat. This isn't cheating because Acid3 isn't testing the font size, it's assuming the font size. It doesn't make sense to test the font size because that's volatile in real world conditions anyway.
165MB is a HUGE amount of source code for something that you claim has a 'much smaller and cleaner' design and is "not all that large".
Firstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the websites drops that ~100MB to ~80MB. So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there.
Secondly, I didn't say that Safari is "not all that large". I said that browsers are not all that large. Download, for example, KDE, and see how small a part of it Konqueror is. You were characterising developing a browser as this monumental effort that required a special, painstakingly slow development approach. In reality, there are far larger codebases that are worked on at a much faster rate by many more people, with way less communication. Browsers really aren't anything special in this regard.
Thirdly, it's not just my claim about the relative sizes of the codebases. Check out the announcements (1 and 2) explaining the reasons for going with KHTML:
Not only were they the basis of an
excellent modern and standards compliant web browser, they were also
less than 140,000 lines of code. The size of your code and ease of
development within that code made it a better choice for us than other
open source projects. Your clean design was also a plus. And the
small size of your code is a significant reason for our winning startup
performance
Weighing in at less than one tenth the size of another open source renderer, Konqueror helps Safari stay lean and responsive.
Do you think Webkit is ten times the size it was then? Or do you think Gecko is ten times smaller than it was then?
Instead of fixing the rendering of the 'Ahem' font, it seems to turn off font smoothing just to make it look like the reference rendering(note that it does it only for the web font). What about such bugs for other fonts?
Ahem isn't a real font. It's a dummy font that only has four glyphs and weird sizing. Its glyphs need to have very specific dimensions in order for the test to be accurate. Turning off font smoothing for this font in particular is enforcing those very specific font metrics. Yes, it looks like a hack, but that's far from the whole truth. In the real world, users that change their font sizes would also cause "failures" like this; the specific font metrics of the Ahem font are assumed by the test for accurate results. At worst, you could say it's a hack to set up the necessary conditions for the Acid3 test to run. These font metrics aren't part of the Acid3 test, they are a prerequisite for accurate results.
Bug 17086 is the bug you should be looking at for background. The question is whether or not antialiasing/font smoothing should have an effect on font metrics or if it should be clipped. It may turn out that the Acid3 test is updated to make this a non-issue.
What about such bugs for other fonts? Brushed under the carpet called Acid3 compliance.
Here you go misrepresenting your guesses as actual fact again. If you don't know the details, don't make accusations like that. Should antialiasing/font smoothing increase the size of text slightly or is that a bug? That's a difficult question to ans
And Acid2, for all its emphasis on CSS, hasn't fixed CSS -- it's still wildly different everywhere, even if you only consider Acid2-passing browsers.
That hasn't been my experience.
my HTML pages don't look or act quite the same in any of them.
That in itself isn't necessarily a bug. Examples? And make your mind up — "wildly different everywhere" and "don't look or act quite the same" are two very different things.
That's neat, but how hard is it really to write a more authoritative test suite?
I'm not sure what you mean by authoritative, but there have been CSS test suites available at the W3C for years and Microsoft have just submitted over 700 more tests for inclusion.
The problem with races is that the teams do almost anything just to cross the finish line faster.
Do you have any evidence for this?
Any developer worth his salt knows that browsers are huge and complex applications and every change must be discussed, designed and implemented properly as to not impact something else and be modular, be properly commented and be clean and well written code.
No, browsers aren't actually all that large (the rendering engines for the Opera desktop browser and the mobile browser are the same), and you don't have to painstakingly discuss absolutely everything. Nothing would ever get done.
It's true that rushing to meet one goal can cause regressions elsewhere; that is what regression tests are for. And I don't know about Opera, but Safari/Webkit has plenty of them.
I think there is a very good chance of the code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which features are being thrown into the code.
So this is actually just wild-ass speculation and not something you have solid reasons to believe?
Yes, Safari and Opera are both moving fast. Extremely fast compared with Firefox and Internet Explorer. But that is because they are much smaller codebases. Gecko is huge and crufty. Changing one thing can have knock-on effects all over the place. Internet Explorer has three very different rendering engines attempting to remain compatible with years-old intranet applications.
One of the reasons Apple chose KHTML instead of Gecko for Safari was that it was much smaller and had a cleaner design. And that choice has paid off in spades, the turnaround on new features and functionality is extremely quick.
Opera have been focusing on the mobile market for a long time now, it's a core part of their business and a substantial portion of their revenue, so they've always kept the code small and manageable.
What you are seeing here are not crazy hacks, but the consequences of years of savvy architectural and management decisions. When you invest in clean design up-front, the cost of efforts like this is vastly reduced.
most of these specifications are in "Candidate Recommendation" state, and not yet in "Web Standard".
I'm sorry, that's not true either. I count eleven Recommendations, one ECMA standard, five Candidate Recommendations and two RFCs.
Candidate Recommendation is the stage when browsers are supposed to implement them. They don't reach final Recommendation status ("Web Standard") until after there are two interoperable implementations.
So of the nineteen specifications listed, over half have final Recommendation status and all have reached the stage where they should be implemented. So again, the Acid3 test is primarily a test of things browsers should have had years ago.
The OS's developers can add/remove functionality module by module.
How is this any different to what they have done all along, where custom installations allow you to pick and choose components? I remember doing that all the way back in the mid-90s.
I guess what I'm saying is: what separates a "module" from an application or a library? There appears to be no meaningful difference.
So I suppose the HTML5 standard itself is in error?
"The HTML5 standard"? No such thing. Not yet at least. So far only drafts exist.
After all, the proposed HTML5 doctype is simply <!DOCTYPE html>.
Yes, which is not what tepples posted. The doctype tepples posted included PUBLIC, indicating that a public identifier was coming up, and then failed to include it.
And in the context of the discussion at hand, the HTML 5 doctype makes Internet Explorer 8 use its newest rendering engine, not quirks mode, so again, are you actually looking for an explanation for the problem, or are you just trying to moan about Microsoft?
Given the absolute embarrassment that is HTML tutorials in general (though they're not quite as bad as Javascript tutorials, I'll give them that), I have to wonder what kind of answer that is to a question about whether something is invalid or should reasonably trigger quirks mode in a standards-based browser.
Please read the thread for context. Cruciform was complaining that their code doesn't work in Internet Explorer 8 and wondered if they were reading the right tutorials. I responded that the symptoms he reports indicate that he's doing something wrong himself. Then tipples responded with edge cases that cause Internet Explorer to go into quirks mode even when a doctype is supplied. I responded that those cases either a) don't apply to Internet Explorer 8, b) are incorrect code, or c) aren't taught by tutorials, meaning none of them are at all likely to be causing Cruciform's problem and that the reasonable conclusion is in fact my original one, that he's doing something wrong himself.
As you can see, the majority of the Acid3 test is comprised of behaviour described in specifications published years ago, with a substantial portion of them over five years old and some over a decade old.
CSS3 intoduces many changes,
Actually, CSS 3 is not a single specification, but a group of
Validity is a property of documents; a doctype declaration alone cannot be valid or invalid. But that code is incorrect, you've forgotten the public identifier. That code also puts other browsers into quirks mode.
Is the ISO HTML 2000 version doctype invalid?
There's more than one ISO HTML 2000 doctype declaration available. As for correctness, that depends on whether or not you screw the syntax up. But next to nobody uses that doctype anyway. Can you name a single HTML tutorial that mentions it? The OP wondered if he was reading the wrong tutorials, in my experience, it's common for tutorials to miss out doctypes altogether and unheard of for them to mention ISO-HTML at all. So we can reasonably eliminate that from consideration as well.
Is it considered invalid to put the XML prolog before the doctype of an XHTML document?
It is not invalid, but you shouldn't do so when serving it as text/html as it goes against the compatibility guidelines in the XHTML 1.0 specification, which RFC 2854 requires you to follow. Further, Internet Explorer hasn't chosen quirks mode for documents with XML prologues since version 6, so that's not the issue here either.
Is it considered invalid to put an SGML comment before the doctype?
There's nothing wrong with that, although again, it's not something tutorials teach. You can divide HTML tutorials into two different groups: one doesn't mention doctypes and the other says that the doctype must come first (or straight after the XML prologue).
Wikipedia says all of those situations will put some IE versions into quirks mode despite the presence of a doctype.
But "some IE versions" isn't relevant here, we are talking about version 8 in particular. Are you actually looking for an explanation for the problem, or are you just trying to find a way of blaming Microsoft? Doctype switching has been around for many years, all major browsers do it, and it's silly to blame Microsoft for auto margin centring not working when Internet Explorer has supported it for seven years.
Making it a relative URL means they can't guarantee that the <object> element fails to render. They needed it to be an absolute URL so that they could be certain it returned a 404.
Auto margins failing to centre block elements is a hallmark of quirks mode, which means that you aren't using a doctype, which means that you are writing invalid code, which means that you aren't in any position to criticise others for not following the specifications.
Acid3 was recently released so that people have new standards to meet.
Acid3 isn't a standard, it's a set of tests for specifications that have already existed for years. Acid3 didn't make Firefox less compliant, it merely pointed out ways in which Firefox was already non-compliant.
No, really, there's no new security problem here. Different hosts? How is that different to <script> elements pointing to different hosts today? Compromised hosts? What's different to today?
Browsers have been able to download code from disparate, potentially untrustworthy remote hosts since they first started executing JavaScript. You have not discovered a new problem.
I was just hoping someone more knowledgeable on the subject would provide some thoughts on the issues.
Somebody already did, but you didn't like the answer.
KDE is a tree stump. You must whittle it down in order to make it resemble something attractive or functional.
Now you're bordering on trolling. You need to "whittle KDE down" to make it even resemble something functional? Nonsense.
So, those who are still using KDE are possibly:
Okay, final strike, my troll alarm is going off. You need to find stupid excuses to explain why people use KDE to avoid the fact that many people choose it over GNOME? You don't think it's at all possible that it might just be better at some things than GNOME?
Using Linspire or Xandros or PC-BSD or some other "easy" distro
You just finished explaining how the people who want "easy" should use GNOME because it's "intrinsically" easy. Surely this is evidence that KDE is easy too, by your own admission.
I am sure the state of New Jersey can tell Sequoia to accept this investigation or say good-bye to any certification.
Tell them to accept the investigation? As far as I'm concerned, the fact that they are threatening to sue to avoid having their software examined for flaws automatically disqualifies them from consideration. Why bother with the investigation now? They are practically admitting that their software isn't good enough and that they will do anything possible to avoid fixing it.
Yes, British cuisine. The UK is a bit like a culinary Borg, it assimilates other cultures' distinctiveness and adds them to its own. It's a side-effect of the empire. The Fat Duck is as British as a balti house.
In 2005 British cuisine reached new heights when 600 food critics writing for (British) Restaurant magazine named 14 British restaurants among the 50 best restaurants in the world with the number one spot going to The Fat Duck in Bray, Berkshire and its chef Heston Blumenthal.
That stereotype is unwarranted. The UK has some of the best restaurants in the world. The Fat Duck, for instance, was named best restaurant in the world and was runner up three times. There's another restaurant in the same village that's in the top 20 as well, I believe.
Now, I'm not saying that tea is ingrained into the British psyche so to speak, but when struggling for a way to describe just how wrecked the vehicle was, his commanding officer had this to say:
I was astonished at the state of his vehicle. There were so many holes in it, it was like a teabag.
So yes, they might be in the thick of battle, but tea is never far from the mind.
In cases like this, I really don't see the difference between opt-in and opt-out. All the ISPs have to do to make it "opt-in" is include a clause saying that you agree to share your data in amongst the dozens of existing clauses in the terms and conditions when you sign up.
Sounds like you might have changed the doctype so Firefox isn't being kicked into quirks mode. Unless you are vertically aligning the images to the bottom or changing them to block display, they are supposed to produce gaps in table layouts, because they are base-aligned by default, meaning the "gap" is the space reserved for descenders that is between the baseline and the bottom of the table cell.
As far as I know, the doctype switching hasn't changed in Firefox 3, so you should be seeing this problem in earlier versions as well. Take a look at Tools | Page Info | Render Mode to see if it's in quirks mode.
And absolute positioning is not the only option for CSS layouts, so if your reason for avoiding CSS really is "absolute positioning is still no match for a well-done table", then perhaps you should take another look at CSS.
Slashdot Mirror
It's not the outrageous hack you think it is. Ahem is a dummy font that needs to have specific sizing in order for Acid3 to give accurate results. If Ahem doesn't have the specific size assumed by the Acid3 test, that means Acid3 can't give accurate results, not that Acid3 failed. So the Webkit developers disabled font smoothing for that specific font so that Acid3 could give accurate results, not to cheat. This isn't cheating because Acid3 isn't testing the font size, it's assuming the font size. It doesn't make sense to test the font size because that's volatile in real world conditions anyway.
Firstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the websites drops that ~100MB to ~80MB. So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there.
Secondly, I didn't say that Safari is "not all that large". I said that browsers are not all that large. Download, for example, KDE, and see how small a part of it Konqueror is. You were characterising developing a browser as this monumental effort that required a special, painstakingly slow development approach. In reality, there are far larger codebases that are worked on at a much faster rate by many more people, with way less communication. Browsers really aren't anything special in this regard.
Thirdly, it's not just my claim about the relative sizes of the codebases. Check out the announcements (1 and 2) explaining the reasons for going with KHTML:
Do you think Webkit is ten times the size it was then? Or do you think Gecko is ten times smaller than it was then?
Ahem isn't a real font. It's a dummy font that only has four glyphs and weird sizing. Its glyphs need to have very specific dimensions in order for the test to be accurate. Turning off font smoothing for this font in particular is enforcing those very specific font metrics. Yes, it looks like a hack, but that's far from the whole truth. In the real world, users that change their font sizes would also cause "failures" like this; the specific font metrics of the Ahem font are assumed by the test for accurate results. At worst, you could say it's a hack to set up the necessary conditions for the Acid3 test to run. These font metrics aren't part of the Acid3 test, they are a prerequisite for accurate results.
Bug 17086 is the bug you should be looking at for background. The question is whether or not antialiasing/font smoothing should have an effect on font metrics or if it should be clipped. It may turn out that the Acid3 test is updated to make this a non-issue.
Here you go misrepresenting your guesses as actual fact again. If you don't know the details, don't make accusations like that. Should antialiasing/font smoothing increase the size of text slightly or is that a bug? That's a difficult question to ans
That hasn't been my experience.
That in itself isn't necessarily a bug. Examples? And make your mind up — "wildly different everywhere" and "don't look or act quite the same" are two very different things.
I'm not sure what you mean by authoritative, but there have been CSS test suites available at the W3C for years and Microsoft have just submitted over 700 more tests for inclusion.
Do you have any evidence for this?
No, browsers aren't actually all that large (the rendering engines for the Opera desktop browser and the mobile browser are the same), and you don't have to painstakingly discuss absolutely everything. Nothing would ever get done.
It's true that rushing to meet one goal can cause regressions elsewhere; that is what regression tests are for. And I don't know about Opera, but Safari/Webkit has plenty of them.
So this is actually just wild-ass speculation and not something you have solid reasons to believe?
Yes, Safari and Opera are both moving fast. Extremely fast compared with Firefox and Internet Explorer. But that is because they are much smaller codebases. Gecko is huge and crufty. Changing one thing can have knock-on effects all over the place. Internet Explorer has three very different rendering engines attempting to remain compatible with years-old intranet applications.
One of the reasons Apple chose KHTML instead of Gecko for Safari was that it was much smaller and had a cleaner design. And that choice has paid off in spades, the turnaround on new features and functionality is extremely quick.
Opera have been focusing on the mobile market for a long time now, it's a core part of their business and a substantial portion of their revenue, so they've always kept the code small and manageable.
What you are seeing here are not crazy hacks, but the consequences of years of savvy architectural and management decisions. When you invest in clean design up-front, the cost of efforts like this is vastly reduced.
I'm sorry, that's not true either. I count eleven Recommendations, one ECMA standard, five Candidate Recommendations and two RFCs.
Candidate Recommendation is the stage when browsers are supposed to implement them. They don't reach final Recommendation status ("Web Standard") until after there are two interoperable implementations.
So of the nineteen specifications listed, over half have final Recommendation status and all have reached the stage where they should be implemented. So again, the Acid3 test is primarily a test of things browsers should have had years ago.
How is this any different to what they have done all along, where custom installations allow you to pick and choose components? I remember doing that all the way back in the mid-90s.
I guess what I'm saying is: what separates a "module" from an application or a library? There appears to be no meaningful difference.
"The HTML5 standard"? No such thing. Not yet at least. So far only drafts exist.
Yes, which is not what tepples posted. The doctype tepples posted included PUBLIC, indicating that a public identifier was coming up, and then failed to include it.
And in the context of the discussion at hand, the HTML 5 doctype makes Internet Explorer 8 use its newest rendering engine, not quirks mode, so again, are you actually looking for an explanation for the problem, or are you just trying to moan about Microsoft?
Please read the thread for context. Cruciform was complaining that their code doesn't work in Internet Explorer 8 and wondered if they were reading the right tutorials. I responded that the symptoms he reports indicate that he's doing something wrong himself. Then tipples responded with edge cases that cause Internet Explorer to go into quirks mode even when a doctype is supplied. I responded that those cases either a) don't apply to Internet Explorer 8, b) are incorrect code, or c) aren't taught by tutorials, meaning none of them are at all likely to be causing Cruciform's problem and that the reasonable conclusion is in fact my original one, that he's doing something wrong himself.
Why do you say that?
Now you have math problems.
Let's do exactly what you suggest, and "RTFM". From the Acid3 page at webstandards.org, with links to the specifications and dates added by me:
As you can see, the majority of the Acid3 test is comprised of behaviour described in specifications published years ago, with a substantial portion of them over five years old and some over a decade old.
Actually, CSS 3 is not a single specification, but a group of
Validity is a property of documents; a doctype declaration alone cannot be valid or invalid. But that code is incorrect, you've forgotten the public identifier. That code also puts other browsers into quirks mode.
There's more than one ISO HTML 2000 doctype declaration available. As for correctness, that depends on whether or not you screw the syntax up. But next to nobody uses that doctype anyway. Can you name a single HTML tutorial that mentions it? The OP wondered if he was reading the wrong tutorials, in my experience, it's common for tutorials to miss out doctypes altogether and unheard of for them to mention ISO-HTML at all. So we can reasonably eliminate that from consideration as well.
It is not invalid, but you shouldn't do so when serving it as text/html as it goes against the compatibility guidelines in the XHTML 1.0 specification, which RFC 2854 requires you to follow. Further, Internet Explorer hasn't chosen quirks mode for documents with XML prologues since version 6, so that's not the issue here either.
There's nothing wrong with that, although again, it's not something tutorials teach. You can divide HTML tutorials into two different groups: one doesn't mention doctypes and the other says that the doctype must come first (or straight after the XML prologue).
But "some IE versions" isn't relevant here, we are talking about version 8 in particular. Are you actually looking for an explanation for the problem, or are you just trying to find a way of blaming Microsoft? Doctype switching has been around for many years, all major browsers do it, and it's silly to blame Microsoft for auto margin centring not working when Internet Explorer has supported it for seven years.
Making it a relative URL means they can't guarantee that the <object> element fails to render. They needed it to be an absolute URL so that they could be certain it returned a 404.
No, that's exactly wrong. If an <object> element can't be rendered, its content should be rendered instead.
Auto margins failing to centre block elements is a hallmark of quirks mode, which means that you aren't using a doctype, which means that you are writing invalid code, which means that you aren't in any position to criticise others for not following the specifications.
Acid3 isn't a standard, it's a set of tests for specifications that have already existed for years. Acid3 didn't make Firefox less compliant, it merely pointed out ways in which Firefox was already non-compliant.
Correct me if I'm wrong, but I believe iTMS is built around Webkit, so a large part of Safari is needed and is already installed.
Not that there isn't an important distinction between Safari and Webkit, but they aren't as unrelated as you make them out to be.
No, really, there's no new security problem here. Different hosts? How is that different to <script> elements pointing to different hosts today? Compromised hosts? What's different to today?
Browsers have been able to download code from disparate, potentially untrustworthy remote hosts since they first started executing JavaScript. You have not discovered a new problem.
Somebody already did, but you didn't like the answer.
What? When was this? I've been using KDE since the 1.0 betas back in the 90s and don't remember this ever being the case.
That is simply not true.
Now you're bordering on trolling. You need to "whittle KDE down" to make it even resemble something functional? Nonsense.
Okay, final strike, my troll alarm is going off. You need to find stupid excuses to explain why people use KDE to avoid the fact that many people choose it over GNOME? You don't think it's at all possible that it might just be better at some things than GNOME?
You just finished explaining how the people who want "easy" should use GNOME because it's "intrinsically" easy. Surely this is evidence that KDE is easy too, by your own admission.
Tell them to accept the investigation? As far as I'm concerned, the fact that they are threatening to sue to avoid having their software examined for flaws automatically disqualifies them from consideration. Why bother with the investigation now? They are practically admitting that their software isn't good enough and that they will do anything possible to avoid fixing it.
Yes, British cuisine. The UK is a bit like a culinary Borg, it assimilates other cultures' distinctiveness and adds them to its own. It's a side-effect of the empire. The Fat Duck is as British as a balti house.
It's a bit more than just the one:
That stereotype is unwarranted. The UK has some of the best restaurants in the world. The Fat Duck, for instance, was named best restaurant in the world and was runner up three times. There's another restaurant in the same village that's in the top 20 as well, I believe.
You may have heard about the recent recipient of the Military Cross, Fusilier Damien Hields. He fought off 150 Taliban fighters with a grenade machinegun. Unsurprisingly, his vehicle got a bit shot up in the process.
Now, I'm not saying that tea is ingrained into the British psyche so to speak, but when struggling for a way to describe just how wrecked the vehicle was, his commanding officer had this to say:
So yes, they might be in the thick of battle, but tea is never far from the mind.
In cases like this, I really don't see the difference between opt-in and opt-out. All the ISPs have to do to make it "opt-in" is include a clause saying that you agree to share your data in amongst the dozens of existing clauses in the terms and conditions when you sign up.
Sounds like you might have changed the doctype so Firefox isn't being kicked into quirks mode. Unless you are vertically aligning the images to the bottom or changing them to block display, they are supposed to produce gaps in table layouts, because they are base-aligned by default, meaning the "gap" is the space reserved for descenders that is between the baseline and the bottom of the table cell.
As far as I know, the doctype switching hasn't changed in Firefox 3, so you should be seeing this problem in earlier versions as well. Take a look at Tools | Page Info | Render Mode to see if it's in quirks mode.
And absolute positioning is not the only option for CSS layouts, so if your reason for avoiding CSS really is "absolute positioning is still no match for a well-done table", then perhaps you should take another look at CSS.