hixie.ch · Domains · Slashdot Mirror

Re:One space by Tacvek · 2010-08-06 08:59 · Score: 1 · on Sentence Spacing — 1 Space or 2?

That depends entirely on the grammatical rules of the dialect you use. I use a dialect that is very similar to en-US-x-Hixie, although with some slight differences. Logical placement of punctuation is one of the unchanged rules.

A few of my difference: such as using "belief" and "faith" in a more general sense, similar to his definition of "trust". The word "Y'all" is never permitted. Both "gray" and "grey" are acceptable spellings, but "grey" has a slightly darker connotation in my mind, but not particularly significant.

Re:That's simply not an adequate response by mcbutterbuns · 2010-02-16 17:30 · Score: 1 · on Next Flash Version Will Support Private Browsing

Maybe when Adobe stops blocking the HTML5 spec.

Why XHTML? by Kozz · 2010-02-01 08:00 · Score: 2 · on Sams Teach Yourself HTML and CSS In 24 Hours

A case against XHTML

Not only is it possibly harmful to send XHTML (xml) as text/html, all your style and script blocks need to be wrapped in all kinds of comment / (P)CDATA silliness to truly validate correctly, etc. Read the article and you may decide that HTML 4 (strict) is the way to go.

On the other hand, if someone would like to refute the points in the link above, I'd welcome an alternate perspective.

Smoothness is relaxed on lesser hardware by tepples · 2009-09-01 04:53 · Score: 1 · on Opera 10.0 Released

A 100/100 however does *not* indicate a pass, browsers need to pass all the tests at over 30fps to pass the whole test.

Only when running on a MacBook Pro, according to Hixie. Phones and netbooks with lesser CPUs need not run at 30 fps to pass, according to WaSP.

Google paid him to do it by tepples · 2009-08-15 06:17 · Score: 1 · on Netscape Founder Backs New Browser

And guess what, Hickson didn't make a single dime from that page.

Hickson's CV would beg to differ. Opera and Google paid Hickson to write test cases for CSS and JavaScript, including the Acid series, in order to shame another browser maker into improving its product.

Re:Sounds like a few people are confused... by Homburg · 2009-07-03 08:10 · Score: 1 · on XHTML 2 Cancelled

I have been told that making page uses XML compatible HTML makes for a more predictable browsing experience and also lowers memory requirements.

You've been told wrong. Making your HTML or XHTML valid does make for a more predictable browsing experience, and may even lower memory requirements. Writing HTML that looks a bit like XML (e.g., using self-closing tags) and then serving it as HTML is completely pointless.

Re:Death to IE6! by Wraithlyn · 2009-05-01 07:10 · Score: 2, Insightful · on IE8 Update Forces IE As Default Browser

Does any browser on the market today fail on invalid XHTML? (by "fail" I mean refusing to parse the page and render it)

Yes. But it actually has to be served as XHTML, and the vast majority is not.

There is a popular misconception that an XHTML DOCTYPE means the page is interpreted as XHTML, this is incorrect. All the DOCTYPE really does is turn off quirks mode in IE, the actual content-type of the page (which is sent in the HTTP response header from the server) is virtually always served as text/html.

In order to have a page truly interpreted as XHTML, it needs a content-type header of application/xhtml+xml, and this will indeed break rendering and display an XML parsing error for the most trivial of errors. And of course IE6 doesn't support application/xhtml+xml, so this is not a viable option unless you want to start serving different versions of your page based on the browser.

Thus the situation we have today, is that everyone writes "XHTML style" HTML (ie, self-closing tags, everything lowercase, quoted attributes, etc), but it's actually interpreted as poorly formed HTML by the browser. (ie, <br /> is technically not valid HTML) Luckily browsers are extremely forgiving of poorly formed HTML.

A couple links on the subject:

http://www.autisticcuckoo.net/archive.php?id=2005/04/08/doctype-declaration-and-content-type-headers

http://hixie.ch/advocacy/xhtml

Re:Standards by Bogtha · 2009-01-26 12:48 · Score: 1 · on Microsoft Releases Internet Explorer 8 RC1

Acid3 covers some standards which aren't even final yet, such as CSS3.

This is highly misleading.

The criteria for the Acid3 tests included the requirement that they be justifiable using only specifications that were in the Candidate Recommendation stage or better in 2004. Weblog article from the author of the test here. Candidate Recommendation stage is the point at which browsers should be implementing the specifications. You can't get to full Recommendation status until two or more browsers have implemented them.

So yes, they weren't "final", but only in the sense that browser implementations were lacking. The specifications were as ready as they could be years before the Acid3 test was announced.

Meanwhile, IE8 does pass Acid2, which indicates correct implementation of HTML4 & CSS2

It indicates no such thing. It's a collection of test-cases for functionality that would be very useful in day-to-day web development if only they were widely implemented correctly. The Acid2 tests do not indicate that a browser has correctly implemented HTML 4 and CSS, only that it has fixed many bugs that it had previously suffered from.

Re:Acid3 Slashdotted? by bdash · 2008-06-03 14:37 · Score: 1 · on Next-Gen JavaScript Interpreter Speeds Up WebKit

There's not supposed to be a custom favicon.

Ian Hickson says:

If a browser passes all 100/100 subtests and gets the rendering pixel-for-pixel correct (including the favicon!), then it has passed the standards-compliance parts of the Acid3 test. The rest is just a competition for who can be the fastest.

Firefox 3rc1 displays a red cat favicon when viewing the Acid3 test page, but no favicon when viewing the reference rendering. A quick inspection of the source of the reference rendering shows that the lack of favicon is intentional:

<link rel="icon" href="http://example.invalid/">

WebKit correctly displays no favicon for both pages. The 100/100 score and pixel-perfect rendering leaves only the performance of test 26 to beat.

Re:Acid3 Slashdotted? by bunratty · 2008-06-03 09:28 · Score: 1 · on Next-Gen JavaScript Interpreter Speeds Up WebKit

I can access the Acid3 test without problem. I also wonder if this will cause Safari to pass the performance aspect of Acid3. If it doesn't now, it looks like it soon will.

Re:Acid 3 Test by TJamieson · 2008-04-03 02:34 · Score: 1 · on Firefox 3 Beta 5 Released

Sorry, that 'special case' was valid, but Hixie got angry about it and confronted Hyatt.

See also http://ln.hixie.ch/?start=1206756775&count=1

Re:Acid 3 Test by Anonymous Coward · 2008-04-02 11:07 · Score: 0 · on Firefox 3 Beta 5 Released

Read the code man..

http://ln.hixie.ch/?start=1206756775&count=1 for a full explanation and what's going on

Re:Acid 3 Test by coobert · 2008-04-02 11:06 · Score: 1 · on Firefox 3 Beta 5 Released

The specific test for Ahem has been removed, as the test has been changed (it was ridiculous for it to specify how a system should antialias fonts in the first place).

http://ln.hixie.ch/?start=1206756775&count=1

Re:Acid 3 Test by Bogtha · 2008-04-02 08:52 · Score: 5, Informative · on Firefox 3 Beta 5 Released

And the fact that at least WebKit has introduced a special case for the Acid3 font

That's not the whole story. The Acid3 test assumes specific font-smoothing behaviour (that it doesn't increase the dimensions of the text). This is not always true on OS X and isn't required by any specification. The workaround in Webkit was to guarantee the font-smoothing behaviour that the Acid3 test expected. That font is not a normal font, it's designed specifically for testcases, so both the "bug" and the workaround would not affect normal situations. And the Acid3 test has since been changed to avoid this problem.

Please include this information when mentioning this "ugly thing", because without the pertinent facts, people assume a number of things that simply aren't true.

WebKit at 100%, Opera's score not actually valid by Durandal64 · 2008-03-26 17:20 · Score: 1 · on Acid3 Race In Full Swing, Opera Overtakes Safari

The WebKit folks have scored 100/100 on the test. But in the process of making WebKit conform, they found a bug in the test itself that would have forced a violation of the SVG standard to pass, so it wasn't possible to get a valid 100/100 on the test. That renders Opera's score invalid, and they're back to 99/100.

According to the WebKit people, though, this doesn't actually mean they've passed because the animation may not be as smooth as it's supposed to be. But the rendering itself matches the reference rendering perfectly.

Re:Yes, that's true. by Bogtha · 2008-03-26 17:13 · Score: 1 · on Does IE8 Really Pass Acid2? [Updated]

You know, I needn't have gone to the bother of checking the dates. Here it is, straight from Ian Hickson's weblog:

The behaviour expected by the test must be justifiable using only standards that were in the Candidate Recommendation stage or better in 2004.

Here's another quote to confirm it after the Acid3 test was finished:

the Acid3 test only tests stuff that was in finished specs in 2004 or earlier.

Acid3 was designed to only test behaviour that browser vendors have had at least three years to implement, straight from the horse's mouth. It's not new stuff.

Re:too late by complete+loony · 2008-03-26 16:39 · Score: 1 · on Acid3 Race In Full Swing, Opera Overtakes Safari

The plot coagulates; Webkit claims 100% support while the ACID test has been modified to conform to the SVG 1.1 standard. So Opera may not have a 100% result anymore.

Re:too late by Anonymous Coward · 2008-03-26 15:41 · Score: 0 · on Acid3 Race In Full Swing, Opera Overtakes Safari

Opera FTL!!!!!

They blew their wad too soon trying to steal WebKit's spotlight.

Download the latest nightly and see everything, in real living color on your computer now:

http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/

Oh and the test was updated like 3 hours ago which more than likely knocks Opera back to 99/100, but well no one knows for sure since all they have is a screenshot...

http://ln.hixie.ch/?start=1206578003&count=1

Re:Does public release matter? by somethinghollow · 2008-03-26 13:35 · Score: 2, Informative · on Acid3 Race In Full Swing, Opera Overtakes Safari

Seriously. They found a bug. Opera is now 99/100. Game's still on.

Re:Is anyone else concerned about the 'hacks' ? by Bogtha · 2008-03-26 12:47 · Score: 5, Interesting · on Acid3 Race In Full Swing, Opera Overtakes Safari

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

Re:Does public release matter? by somethinghollow · 2008-03-26 09:59 · Score: 2, Informative · on Acid3 Race In Full Swing, Opera Overtakes Safari

But when the test still has bugs that are being fixed, I don't know if getting it out of the labs the fastest is a great idea for consumers.

Re:Safari 3.1 fails Acid2 by Val314 · 2008-03-24 21:13 · Score: 1 · on Does IE8 Really Pass Acid2? [Updated]

or try the Acid2 (no Data) Test from http://hixie.ch/tests/evil/acid/002-no-data/ that will fail as well.

(the Bug is http://bugs.webkit.org/show_bug.cgi?id=4911 )

Re:I don't care about IE at all by BZ · 2008-03-11 11:14 · Score: 1 · on IE8 Will Be Standards-Compliant By Default

> Yet, Firefox won't let me do that even with CSS.
> Neither will Opera. That's a cryin' shame in my opinion,
> since it wouldn't be *that* much extra work.

Actually, it's a lot more work with CSS. More to the point, it's fundamentally incompatible with the current processing model required by the CSS specification. See http://ln.hixie.ch/?count=1&start=1070385285 for a pretty good description of the problem.

Re:Firefox by Anonymous Coward · 2008-03-05 20:51 · Score: -1 · on Acid3 Test Released

Thanks for the 'shift + click' tip, I'm laughing my ass of at some of the returned errors in IE6 (don't mock me, I'm at work, and the nasty proxy server is denying my portable version of Firefox access to the outside world):

Test 27: 'kungFuDeathGrip.0' is null or not an object
Test 99: expected: www.example.com, got: http://hixie.ch/ - sanity did not prevail

Classy stuff :)

Re:Firefox 2.0.0.12 by Anonymous Coward · 2008-03-05 18:41 · Score: 1, Informative · on Acid3 Test Released

Err... wha?

Acid 3 is mostly Hixie, who's currently at... Google, I think. Previously Opera/Netscape.

Aside: yes, he did ask for browser developer feedback (in particular, to look for things that will fail in under-development versions of Mozilla and Safari; presumably, Opera too.) Apparently new things that only failed in IE wasn't interesting. Reference: his blog.

Re:How do the acid-test creators test the acid tes by bunratty · 2008-03-05 13:52 · Score: 1 · on Acid3 Test Released

Ian Hickson actually did ask for additional tests that fail in Webkit or Firefox, so they did partly write the test against at least two particular browsers.

Re:You can't compete by hkmwbz · 2008-01-31 19:53 · Score: 1 · on Firefox's Market Share Hits 28% in Europe

Did you actually read the article at Opera Watch? If you had, you would have noticed that it lists quotes from many different sources, and they explain the problem. It's sad to see that someone as emotionally involved as yourself refuse to educate yourself, and instead insist on being willfully ignorant.

And did you read the actual comments to that A List Apart article? Almost every single one of them rejected the proposal. In fact, both Opera, Mozilla, Apple and Google have rejected it. As well as most web developers who have spoken up.

If you would only educate yourself instead of spouting uneducated nonsense...

Re:HTML5 is the wrong path by tepples · 2008-01-23 15:13 · Score: 1 · on W3C Publishes First Public Working Draft of HTML 5

Sending with the XHTML mime type is allowed in HTML4 in the compatibility section But look at all the gyrations you have to use to properly hide script and style if you're sending the tag soup that is "compatible" XHTML.

The value of XHTML 1.0 Strict? by tepples · 2008-01-23 14:51 · Score: 1 · on W3C Publishes First Public Working Draft of HTML 5

I wonder, are these the same moron authors who can't do XHTML What's the point of sending XHTML over the wire if the 80 percent web browser still can't render XHTML except as a broken version of HTML 4? I don't see a point, and hixie agrees with me.

or provide fallback content for users without script? I make a real-time video game in JavaScript. What fallback do you recommend for users without script?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> The HTML 4.01 and XHTML 1.0 strict doctypes have one major flaw: a list item <li> can no longer carry a value attribute. This means that an ordered list can't start at any number other than 1 or with any difference between items other than 1. Such a list can't easily represent, say, the track listing for Follow the Leader by Korn, which starts at 13, or a top ten list, which is conventionally printed in 10 to 1 reading order. (The workaround involves a <dl> element, placing numbers in floated <dt> elements and text in <dd> elements.) HTML 5, on the other hand, restores the value attribute.

Re:Page specific tuning by ozamosi · 2008-01-23 06:15 · Score: 5, Interesting · on IE8 May Not Pass the Acid2 Test After All

The author of Acid2/3 is not amused by this meta tag. From the tone of that blog post, to me it sounds like he wouldn't shy away from actively try to break a mechanism like that by changing the URI to make sure that the browser that passes the Acid test actually does so for real.

Note, though, that he doesn't say that explicitly, and you shouldn't assume that he will. It's my own conclusion, and you should draw your own, etc...

Re:Not again by hixie · 2008-01-22 08:37 · Score: 5, Informative · on W3C Publishes First Public Working Draft of HTML 5

Most of HTML5 was actually done outside of the W3C.

However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.

I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.

http://ln.hixie.ch/
http://www.webstandards.org/action/acid3

So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:

http://blog.whatwg.org/w3c-restarts-html-effort