Domain: w3.org
Stories and comments across the archive that link to w3.org.
Comments · 6,785
-
Re: What I think of this...
I am not in the habit of responding to ACs, but you ask so nicely!
The technique of implementing a parallel text-only site is one that is explicitly allowed by 508 and WCAG 1.0 and still favored by some experts, advocates, and end-users. For a variety of reasons, but mostly because of failures with implementations, the idea has long fallen out of favor and does not appear at all in WCAG 2.0 as a consequence.
For a web comic, I would recommend longdesc with the dialog. The Java site might be even more straightforward with things like: alt="screen shot of rendered code as described in the next paragraph". The thought exercise I like to recommend is to ask yourself: How would you read the page to an informed colleague over the phone?
Authors new to accessibility tend to get hung up on how hard it is to provide text equivalents when really all that is needed most of the time is text alternatives which "at least provide descriptive identification of the non-text content". This change in language from WCAG 1.0 to 2.0 is quite deliberate. If you make the paradigm shift from thinking of the web as a visual medium to that of an information medium, you will be on the right track.
-
Re: What I think of this...
I am not in the habit of responding to ACs, but you ask so nicely!
The technique of implementing a parallel text-only site is one that is explicitly allowed by 508 and WCAG 1.0 and still favored by some experts, advocates, and end-users. For a variety of reasons, but mostly because of failures with implementations, the idea has long fallen out of favor and does not appear at all in WCAG 2.0 as a consequence.
For a web comic, I would recommend longdesc with the dialog. The Java site might be even more straightforward with things like: alt="screen shot of rendered code as described in the next paragraph". The thought exercise I like to recommend is to ask yourself: How would you read the page to an informed colleague over the phone?
Authors new to accessibility tend to get hung up on how hard it is to provide text equivalents when really all that is needed most of the time is text alternatives which "at least provide descriptive identification of the non-text content". This change in language from WCAG 1.0 to 2.0 is quite deliberate. If you make the paradigm shift from thinking of the web as a visual medium to that of an information medium, you will be on the right track.
-
Re:And again...
Your page isn't valid xhtml. You should fix that.
http://validator.w3.org/check?uri=http%3A%2F%2Fslashdot.on.nimp.org%2Funlucky%2Fsucker.html&charset=(detect+automatically)&doctype=Inline&group=0 -
Re:sigh....In the end, if I went on to point all of the things you have to do to comply with ADA and all similar recommendations, all you can really have is flat document-style black and white pages with rediculous font sizes made in raw XHTML/CSS and thats that. This statement is false, and it melodramatically misrepresents the web accessibility guidelines that the are recommended.
Creating accessible websites is not hard, and doesn't mean your website has to suck. On the other hand, if your web site sucks for blind users, it probably sucks for everyone else too. -
Re:Oops...
Obviously they should be using DELETE
-
Re:Why is parent flamebait?
First, it's not code, it's CSS.
It's not programming, but it is code. Regardless, its nature is not important, the fact that it's licensed under open source terms and is a benefit to open source projects is.
Of course IE already passes the 700 cases they release.
Actually, released versions of Internet Explorer don't pass them all, not even close. Those testcases were produced as part of the work to make Internet Explorer 8 more conformant with the CSS specifications.
Now if Microsoft can get W3C to adopt them, IE instantly is complaint
You mean "compliant", and no, the W3C adopting them would not make Internet Explorer any more compliant than before.
no extra work.
You're ignoring the work that Microsoft did to pass those testcases in the first place.
It's not really that much different that Microsoft "contributing" OOXML to the document standards process. Just a backdoor way to get their implementation as the standard.
Either you are trolling, or you don't know what you are talking about. Testcases don't change what's in the specifications and can't make any implementation the standard.
It doesn't add anything of value to open source development.
That'll be why the announcement on the W3C CSS test suite mailing list garnered a positive reaction from developers for all the major browsers then? (Quotes: "Awesome guys!", "Great to see them published!", "your contribution of this test suite is very encouraging.", "Thanks for the CSS 2.1 tests."). Testcases are valuable tools for QA.
And, most pertinently, there was an ongoing thread on the list about relicensing the existing testcases under the BSD license before Microsoft's announcement because the usual W3C license was a bit too restrictive for some people, open source projects in particular.
So when open source developers, who explicitly require testcases under an open-source license received news of Microsoft's contribution, they were pleased. And you really want to argue that Microsoft have never added anything of value to open source? Really? Then why do Mozilla and Webkit developers disagree with you?
-
Re:Paradigm shifts and evil empiresGoogle isn't a company based around software. It's a company which uses standards instead.... most of their service are web applications built around pretty plain standard-compliant HTML.
Really?
- google mail - 86 errors
- google maps - 68 errors
- google search - 50 errors
- google news - 1360 errors
- google groups - 584 errors
- google finance - 293 errors
Where are these "most" of their applications which are standards-compliant?
-
Re:Paradigm shifts and evil empiresGoogle isn't a company based around software. It's a company which uses standards instead.... most of their service are web applications built around pretty plain standard-compliant HTML.
Really?
- google mail - 86 errors
- google maps - 68 errors
- google search - 50 errors
- google news - 1360 errors
- google groups - 584 errors
- google finance - 293 errors
Where are these "most" of their applications which are standards-compliant?
-
Re:Paradigm shifts and evil empiresGoogle isn't a company based around software. It's a company which uses standards instead.... most of their service are web applications built around pretty plain standard-compliant HTML.
Really?
- google mail - 86 errors
- google maps - 68 errors
- google search - 50 errors
- google news - 1360 errors
- google groups - 584 errors
- google finance - 293 errors
Where are these "most" of their applications which are standards-compliant?
-
Re:Paradigm shifts and evil empiresGoogle isn't a company based around software. It's a company which uses standards instead.... most of their service are web applications built around pretty plain standard-compliant HTML.
Really?
- google mail - 86 errors
- google maps - 68 errors
- google search - 50 errors
- google news - 1360 errors
- google groups - 584 errors
- google finance - 293 errors
Where are these "most" of their applications which are standards-compliant?
-
Re:Paradigm shifts and evil empiresGoogle isn't a company based around software. It's a company which uses standards instead.... most of their service are web applications built around pretty plain standard-compliant HTML.
Really?
- google mail - 86 errors
- google maps - 68 errors
- google search - 50 errors
- google news - 1360 errors
- google groups - 584 errors
- google finance - 293 errors
Where are these "most" of their applications which are standards-compliant?
-
Re:Paradigm shifts and evil empiresGoogle isn't a company based around software. It's a company which uses standards instead.... most of their service are web applications built around pretty plain standard-compliant HTML.
Really?
- google mail - 86 errors
- google maps - 68 errors
- google search - 50 errors
- google news - 1360 errors
- google groups - 584 errors
- google finance - 293 errors
Where are these "most" of their applications which are standards-compliant?
-
Re:Big deal?
Where's my ad directory?
My cynical side says, "It's coming soon, and it's called the Semantic Web"
-
Re:I don't know about ODF
I've wondered about using or extending XHTML as well. Apparently, there has been an effort in that direction for a while called Compound Document Formats which has had a much lower profile than ODF or OOXML. It does seem promising for basic functionality, but I get the impression it's intended more as target format like regular HTML or PDF than as an editing format like ODF. I'll definitely be watching it to see how useful it turns out to be for simple stuff.
-
Re:The Next Milestone
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.
-
Re:Lynx
This is essentially what Lynx looks like on todays sites: http://cgi.w3.org/cgi-bin/html2txt?url=http%3A%2F%2Fslashdot.org%2F
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:Yes, that's true.
The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.
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:
Here is the list of specifications tested:
- DOM2 Core [specification published in 2000.]
- DOM2 Events [specification published in 2000.]
- DOM2 HTML [specification published in 2003.]
- DOM2 Range [specification published in 2000.]
- DOM2 Style (getComputedStyle,
...) [specification published in 2000.] - DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
- DOM2 Views (defaultView) [specification published in 2000.]
- ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
- HTML4 (<object>, <iframe>,
...) [specification published in 1997.] - HTTP (Content-Type, 404,
...) [specification published in 1999.] - Media Queries [specification published in 2002.]
- Selectors (:lang,
:nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .] - XHTML 1.0 [specification published in 2000.]
- CSS2 (@font-face) [specification published in 1998.]
- CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
- CSS3 Color (rgba(), hsla(),
...) [specification published in 2003.] - CSS3 UI ('cursor') [specification published in 2004.]
- data: URIs [specification published in 1998.]
- SVG (SVG Animation, SVG Fonts,
...) [specification published in 2001.]
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
-
Re:The answer...I disagree. It should fall back to the data url when loading the other object failed. Not only that, but the HTML standard agrees with me on this:
If the user agent is not able to render the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to render its contents.
andOne significant consequence of the OBJECT element's design is that it offers a mechanism for specifying alternate object renderings; each embedded OBJECT declaration may specify alternate content types. If a user agent cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.
-
Re:Very simple
If IE tries to be compatible, not just pass one single test (Acid2), why it does so badly on Acid3?
Please try to keep up with the conversation. As has been explained many, many times in the comments here, Acid3 is deliberately constructed to highlight problems in popular browsers. All browsers do badly on Acid3, no matter how well they did with Acid2. There'd be no point in constructing an acid test that browsers did well on.
Passin a single test is not IMNSHO "delivered on".
No, it's not. The improved standards support, which you can verify for yourself, is "delivering on". The Acid2 test being passed is just an example of the improved standards support.
If you are so concerned about tests, why not try the W3C CSS test suites? Or why don't you check out the 700 new tests that Microsoft is contributing?
Face it, Microsoft is improving interoperability and support for standards with their work on Internet Explorer. Regardless of your opinion of them, you cannot deny this.
-
Re:Uhhh
why does CSS use this 'float' nonsense instead of the element layout models that have been used for GUI window layout for decades?
Because CSS was designed for documents, not GUIs. The idea is to "pour" the document into the canvas, and make adjustments to the flow as necessary, not to divide up the viewport and put things into it. It makes some things quite a bit simpler and more efficient, especially when you remember that a major design goal of CSS was to incorporate the user's own styles.
As it turns out, not many people were interested in the cascading part of Cascading Style Sheets, and the use of the web as an alternative application platform grew, so this approach doesn't look as sensible as it once did.
It's trivial to define a GUI window in any language and IDE that has one element span across the top of the window, one across the bottom, and three packed horizontally in the middle. That's your classic "Header,Footer,Left Nav,Right Ad,Middle Content" web page layout, and we've known how to make that adjust nicely to variable window sizes forever.
That's been trivial with CSS 2 for a decade using display: table. The only reason people turned to floats for things like that is because Internet Explorer doesn't support that part of CSS 2. Internet Explorer 8 will.
There; that took me all of 10 minutes to come up with a layout box model and multi-column style specification.
That's hardly a workable spec, it's more of an overview than a real specification.
Why is the W3C taking so long to figure out something useful?
It didn't occur to you to check the obvious place? Quote:
This document has been a Working Draft in the CSS Working Group for several years. Multi-column layouts are traditionally used in print. On screen, multi-column layouts have been considered experimental, and implementation and use experience was deemed necessary in order to proceed. Several implementations have occurred over the past years, and this draft incorporates useful feedback from implementors as well as authors and users.
In other words, they fielded ideas, people went off and tried them out, and kept finding problems or coming up with better ideas. It's exactly what would happen if you tried to get people to implement your "spec".
-
Amaya
-
Re:Uhhh
Since a lot of bodies don't have the time or manpower to make anything better (and even if they could, it would be quite a waste of time and money), they take what the W3C spits out and implement it.
That's not really true. Browser vendors participate in the W3C working groups that publish these specifications. They have an active role in creating them. Take a look at the acknowledgment section of the CSS 2 specification, for example.
This specification is the product of the W3C Working Group on Cascading Style Sheets and Formatting Properties. In addition to the editors of this specification, the members of the Working Group are: Brad Chase (Bitstream), Chris Wilson (Microsoft), Daniel Glazman (Electricité de France), Dave Raggett (W3C/HP), Ed Tecot (Microsoft), Jared Sorensen (Novell), Lauren Wood (SoftQuad), Laurie Anna Kaplan (Microsoft), Mike Wexler (Adobe), Murray Maloney (Grif), Powell Smith (IBM), Robert Stevahn (HP), Steve Byrne (JavaSoft), Steven Pemberton (CWI), Thom Phillabaum (Netscape), Douglas Rand (Silicon Graphics), Robert Pernett (Lotus), Dwayne Dicks (SoftQuad), and Sho Kuwamoto (Macromedia). We thank them for their continued efforts.
A number of invited experts to the Working Group have contributed: George Kersher, Glenn Rippel (Bitstream), Jeff Veen (HotWired), Markku T. Hakkinen (The Productivity Works), Martin Dürst (W3C, formerly Universität Zürich), Roy Platon (RAL), Todd Fahrner (Verso), Tim Boland (NIST), Eric Meyer (Case Western Reserve University), and Vincent Quint (W3C).
The section on Web Fonts was strongly shaped by Brad Chase (Bitstream) David Meltzer (Microsoft Typography) and Steve Zilles (Adobe). The following people have also contributed in various ways to the section pertaining to fonts: Alex Beamon (Apple), Ashok Saxena (Adobe), Ben Bauermeister (HP), Dave Raggett (W3C/HP), David Opstad (Apple), David Goldsmith (Apple), Ed Tecot (Microsoft), Erik van Blokland (LettError), François Yergeau (Alis), Gavin Nicol (Inso), Herbert van Zijl (Elsevier), Liam Quin, Misha Wolf (Reuters), Paul Haeberli (SGI), and the late Phil Karlton (Netscape).
The section on Paged Media was in large parts authored by Robert Stevahn (HP) and Stephen Waters (Microsoft).
Robert Stevahn (HP), Scott Furman (Netscape), and Scott Isaacs (Microsoft) were key contributors to CSS Positioning.
And of course, one of the four editors of the specification is Håkon Wium Lie, CTO of Opera.
So you see, far from the poor old browser vendors not having the resources to make anything better and passively reacting to anything the W3C says, you can see that the browser vendors are substantially the people who made the specifications.
-
Re:UhhhYou're right, they aren't standards. Go to any one of the W3's "standards" documents and you'll see they are all called "Recommendations", HTML 4.01, for example. The cool kids call them "RECs".
Now, what good is a recommendation, you ask? Plenty - mostly interoperability. The W3C provides a specification and recommends people implement it. Those that do can interoprate. The consumer wins.
How do you get the vendors to implement the RECs? Make it an important bullet point on their feature lists. The Acid tests are a particularly well done kick in the backside for browser vendors. They have effectively become more important than the bullet point that says "standards compliant" because they are a (limited) test suite. For vendors to be able to say they do well in the tests, certain key parts of the RECs must be implemented and done so correctly, there is no room for buggy or partial implementation.
The result in the end is better interoperability. The RECs provide that common basis that vendors can't quibble over. The Acid tests are both the carrot to get them implementing the RECs and proof that they did so (partially) correctly./Mike
-
Re:Why switch?
I would much rather see both of them go away, though. SVG and JavaScript, please.
I think we all would much rather see open standards on the web. Maybe I'm out of the loop, but I don't see any point at all for Silverlight, JavaFX, Flex, XUL, Curl, etc. In fact Flash and Curl have been around forever and despite a few high profile sites like YouTube using Flash, these technologies are becoming irrelevant.
Developers know that content on the web should be built with open standards. Developers also know that you don't need proprietary technology for "rich" web apps anymore. Anything you want to build will be better supported and a better experience if we stick to the standards. All you will need is:
- HTML5/XHTML2
- CSS3
- JavaScript
- SVG
- MPEG-4/H.264 (or whatever w3c recommends in the future)
-
Re:Well, what did you expect?
Your analogy doesn't hold up. When you request the URL, the web server explicitly responds with a "200 OK" response code instead of "403 Forbidden" or "401 Unauthorized."
They cannot simultaneously give permission to access a resource and claim it is "hacking." Ignorance of the protocols they support is not an excuse.
This is akin to asking a cashier if you can take a penny from the "free pennies" jar and after they reply "yes," accusing you of robbery.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html -
Re:IE8 Features
Just curious how a existing product can "emulate" a non-existing product (IE 8)?
Since you're curious... it's possible because it's a W3C working draft.
-
W3C validatorIf these acid tests are based on standards. Why is the only acid test that passes the W3C validator, the Acid 1 test?
Perhaps, I am missing the point of these acid tests. I'm not a web developer by trade, so I don't claim to be an expert on CSS. From personal experience, CSS has allowed me to use much less complex HTML in the little web publishing I have done. I never seem to get consistent results when I test my pages in different browsers. I hope that these "standards" Acid tests lead to greater compatibility across browsers.
Do these tests increase compatibility by pushing the envelope on new standards, or are they just a browser-war pissing contest? -
W3C validatorIf these acid tests are based on standards. Why is the only acid test that passes the W3C validator, the Acid 1 test?
Perhaps, I am missing the point of these acid tests. I'm not a web developer by trade, so I don't claim to be an expert on CSS. From personal experience, CSS has allowed me to use much less complex HTML in the little web publishing I have done. I never seem to get consistent results when I test my pages in different browsers. I hope that these "standards" Acid tests lead to greater compatibility across browsers.
Do these tests increase compatibility by pushing the envelope on new standards, or are they just a browser-war pissing contest? -
W3C validatorIf these acid tests are based on standards. Why is the only acid test that passes the W3C validator, the Acid 1 test?
Perhaps, I am missing the point of these acid tests. I'm not a web developer by trade, so I don't claim to be an expert on CSS. From personal experience, CSS has allowed me to use much less complex HTML in the little web publishing I have done. I never seem to get consistent results when I test my pages in different browsers. I hope that these "standards" Acid tests lead to greater compatibility across browsers.
Do these tests increase compatibility by pushing the envelope on new standards, or are they just a browser-war pissing contest? -
Re:Huge assumption in the titleHTTP is clear that the client must honor the Content-Type provided by a server when provided. If that type is text/plain, the client must treat it as text/plain, not text/html, image/gif, or application/octet-stream. If and only if the server does not provide the Content-Type may the client inspect. "Content-Type: text/plain" != "". Quoting: Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream". Strongness added by me. I have yet to hear of an IE version that passes HTTP compliance in this one regard by default. (I've heard that even the option to force compliance in this regard in some versions doesn't work either.)
The consequence of IE's non-compliance is misconfigured servers that serve binary data as text/plain because people building the sites only test with IE and never learn how to teach the server to send the proper Content-Type header. Put a .ISO file on your website without telling the server that .ISO should be served as application/octet-stream and you get users with compliant browsers loading the disk image as plain text in their browser windows.
The only thing wrong with RFC 2616 in this section is that it strays from the terminology defined in RFC 2119 in using "if and only if" in conjunction with a SHOULD to hide what should have been labeled a MUST NOT as a MAY. The intent was that clients MUST implement support for what the server SHOULD provide and not nullify the benefit of a server implementing a SHOULD but rather give accommodation to servers which do not do what they SHOULD do. A rewrite would say it more clearly: Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If included, the recipient MUST honor the media type provided by the Content-Type field and MUST NOT attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. Only if the media type is not given by a Content-Type field MAY the recipient so guess the media type and, if the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream". Or just separate the client responsibilities from the server responsibilities, or update RFC 2119 to include a definition for and require the capitalization of IF AND ONLY IF. -
Re:Mod parent interesting!
A good question, they write/use their own browser, Amaya, which is slow but compliant.
-
Re:Developers & the half-life of accumulated c
And it's probably the one thing MS has thoroughly earned with all the IE bullsh*t over the last 10 years.
Personally, I'm wondering if they can possibly release Internet Explorer 8 in nine weeks. Because the 12th of May is the ten year anniversary of the CSS 2 specification and Internet Explorer 8 might actually include full CSS 2 support (not including the aural stuff).
-
Re:Huge assumption in the titleI understand your point, and it's well taken, but you are introducing a tautology. Standards compliance is absolute, by _definition_. I take your point as well, but I want to interject that this entirely depends on what the standards are. Can you build a word processor that is 100% compliant with Microsoft's OOXML standard? Not really, in any meaningful sense, because the standard is incomplete and refers to behavior that isn't described as part of the standard (that's a large part of what all the OOXML vs ODF fuss was about). Can you build an IRC client that is completely standards-compliant? No, because the RFCs that describe how IRC works are incomplete, inconsistent, contain errors, and aren't strictly adhered to by any popular implementation.
In the case of HTML/XHTML and CSS, there's been quite a bit more effort invested into making sure the standards are properly documented and are internally consistent, but these standards are constantly evolving. Is it enough to support HTML 4.01 and CSS 2, or must you support HTML 5 and CSS 3? Do de-facto standards count? Remember that XMLHttpRequest (the basis of AJAX) is mostly a de-facto standard; the W3C has published a working draft of a specification for it.
Standards compliance isn't always as cut-and-dry as you make it sound. -
Re:No, no, a thousand times no.*WHO* decides what "must" go in
.xxx. We may be straying a bit off-topic here but, IMHO, there's no reason to force anything onto the .xxx domain. Just make it available so that "legitimate" pornographers can opt-in. Then, those who are offended by such content can filter it easily and ignore it. And, it would be easier for concerned parties to focus on sites that remain on the .com side that are acting irresponsibly (failure to do age verification / illegal content / etc.) Filtering is easy to do now using the PICS system. PICS has many different categories you can filter sites on, from violence to sexually explicit. Why should there be a TLD for porn, and not one for violence, hate speech, or any of a dozen other potentially offensive aspects of speech? The .XXX TLD is a too small band aid to an already solved problem.